Останній рік навколо AI-агентів сформувався дуже небезпечний тип оптимізму. Демо виглядає переконливо: агент читає лист, знаходить інформацію, генерує відповідь, оновлює CRM, створює задачу і повідомляє менеджера. П’ять хвилин — і здається, що ще трохи, і половину операційної роботи в компанії можна просто віддати моделям.
Проблема в тому, що демо майже нічого не доводить.
Ми багато експериментуємо з агентними workflow у власних бізнесах і проєктах — у продажах, маркетингу, research, підготовці документів, CRM, клієнтському onboarding, контенті та внутрішній координації. І що більше таких сценаріїв доходить до реальної експлуатації, то очевиднішою стає проста річ: модель зазвичай не є головною проблемою.
Найскладніше починається після того, як агент уже “вміє” виконувати задачу.
Ось сім проблем, які я зараз вважаю ключовими.
State: бізнес не може забувати те, що агент забув
У демо ми часто працюємо з короткою сесією. Агент бачить контекст, виконує кілька кроків, і все виглядає прекрасно.
У реальному бізнес-процесі задача може жити три дні, три тижні або три місяці.
Наприклад, потенційний клієнт написав у понеділок. У вівторок йому відправили питання. У четвер він надіслав документи. Через тиждень змінився менеджер. Ще через два тижні клієнт повернувся і послався на домовленість, якої немає в останньому листі.
Для людини це звична робоча історія. Для агента — проблема стану.
Йому потрібно розуміти не лише останнє повідомлення, а й:
- хто клієнт;
- на якому етапі він перебуває;
- що вже було обіцяно;
- які документи отримано;
- чого бракує;
- хто відповідальний;
- які дедлайни;
- що змінилося після попередньої дії.
Якщо state зберігається лише у prompt history, це не production architecture. Це довга розмова з чатботом.
У реальній системі стан має бути структурованим, відновлюваним і незалежним від однієї конкретної моделі.
Permissions: агенту потрібні руки, але руки створюють ризик
Поки агент просто пише текст — усе відносно безпечно.
Справжня цінність з’являється, коли він отримує доступ до інструментів:
- Gmail;
- CRM;
- календаря;
- Google Drive;
- білінгу;
- таск-менеджера;
- внутрішніх баз;
- API клієнтських систем.
І тут починається значно цікавіша частина.
Агент, який може підготувати лист, корисний.
Агент, який може сам відправити лист, значно корисніший.
Агент, який може ще й змінити статус угоди, виставити рахунок і запустити наступний workflow, уже потенційно небезпечний.
Тому permission model стає фундаментом.
Не “чи має агент доступ до Gmail?”, а:
- які саме листи він може читати;
- чи може створювати чернетки або відправляти;
- які дії потребують human approval;
- які дії можна виконати автоматично;
- які дані він не повинен бачити взагалі.
У багатьох AI-проєктах permission layer продумують після основної логіки. На мою думку, це помилка. У production-системі permissions мають проєктуватися одночасно з workflow.
Handoff: “задачу виконано” не означає, що бізнес-результат отримано
Найбільша різниця між автоматизацією окремої задачі та агентною системою — це handoff.
Скажімо, агент підготував комерційну пропозицію. Що далі?
Хтось має:
- перевірити її;
- відправити;
- зафіксувати відправку в CRM;
- поставити follow-up;
- через два дні перевірити відповідь;
- якщо відповіді немає — нагадати;
- якщо відповідь позитивна — перевести ліда на наступний етап;
- якщо є заперечення — передати людині.
У традиційній автоматизації ми рахуємо: “AI зекономив 15 хвилин на написанні proposal”. Але реальна економіка часто лежить не в написанні proposal, а в координаційному контурі навколо нього. Тому я дедалі більше дивлюся не на автоматизацію tasks, а на автоматизацію coordination loops. Окрема задача може займати 10 хвилин. Координація навколо неї — два тижні.
Recovery: що відбувається, коли агент зламався посередині?
Демо майже завжди показує happy path. У продакшені нас цікавить протилежне. Що станеться, якщо агент:
- прочитав лист, але не записав дані в CRM;
- створив документ, але не надав доступ;
- відправив перший лист, але не створив follow-up;
- отримав timeout від зовнішнього API;
- виконав три кроки з п’яти;
- отримав суперечливі дані з двох систем?
Якщо відповідь — “запустимо ще раз”, у вас проблема. Retry може дублювати листи, рахунки, задачі або записи.
Production workflow повинен знати:
- які кроки вже виконано;
- які операції idempotent;
- які можна безпечно повторити;
- які потребують rollback;
- коли треба зупинитися;
- коли ескалювати людині.
У звичайному SaaS ми давно сприймаємо це як нормальну інженерію. У AI-продуктах іноді поводимося так, ніби достатньо хорошого prompt. Не достатньо.
Observability: якщо ви не можете відтворити рішення агента — ви ним не керуєте
Коли співробітник зробив щось дивне, керівник може поставити питання.
Коли агент зробив щось дивне, нам потрібна система, яка дозволяє відновити:
- який контекст він бачив;
- які дані отримав;
- які tools викликав;
- що повернули tools;
- яку дію він обрав;
- яку модель і версію використовував;
- скільки це коштувало;
- де саме виникла помилка.
Без цього “AI automation” швидко перетворюється на дуже дорогий black box. Особливо якщо агент працює не раз на день, а сотні або тисячі разів.
Production agent без logs, tracing, replay і нормальної історії виконання — це не автономний співробітник. Це стажер без керівника, який ще й видаляє переписку після кожної зміни.
Economics: токени — не завжди головна стаття витрат
У розмовах про AI-економіку часто дуже багато уваги приділяють вартості моделей. Скільки коштує один мільйон токенів? Яка модель дешевша? Чи можна замінити frontier model меншою? Це важливо, але в бізнес-процесах я б дивився ширше.
Найдорожчими можуть виявитися:
- людські перевірки;
- обробка exception cases;
- повторна робота після помилки;
- підтримка інтеграцій;
- неправильні дії агента;
- ситуації, коли automation начебто працює, але менеджери все одно перевіряють усе вручну.
Агент може коштувати $0.20 на один run і при цьому бути економічно безглуздим, якщо після кожного run співробітник витрачає 15 хвилин на перевірку.
Тому правильна метрика — не cost per model call. Набагато цікавіше дивитися на cost per completed business outcome.
Human accountability: автономність без відповідальності — погана архітектура
Остання проблема не технічна. Хто відповідальний за результат? У простому workflow це зрозуміло.
Наприклад: AI готує документ → людина затверджує → система відправляє.
Але чим більше автономності, тим легше створити дивну зону, де:
- агент прийняв рішення;
- менеджер не перевірив;
- система автоматично виконала;
- а після помилки ніхто не розуміє, хто мав її зупинити.
Тому я не вважаю “максимальну автономність” правильною метою. Правильна мета — мінімальна кількість людського втручання при збереженні зрозумілої відповідальності.
Іноді це означає 100% automation. Іноді — approval перед платежем. Іноді — approval лише для нетипових кейсів. Іноді — повну передачу людині після певного порога ризику.
Human-in-the-loop — це не ознака того, що AI “не доріс”. У багатьох процесах це просто правильний дизайн системи.
Що з цього випливає
Я думаю, що наступний етап AI у бізнесі буде значно менш видовищним, ніж нинішні демо, але набагато важливішим. Менше “подивіться, агент сам забронював ресторан”.
Більше:
- state management;
- permission architecture;
- orchestration;
- audit trails;
- exception handling;
- approvals;
- business metrics;
- recovery;
- observability.
Саме це визначатиме, чи стане агент красивою презентацією, чи реальною частиною операційної системи компанії.
І тут є ще один висновок. Малі та середні компанії можуть отримати несподівану перевагу. У корпорації зміна одного workflow може потребувати місяців погоджень між IT, security, legal, operations і procurement. У невеликій компанії власник може за день сказати: “цей процес відтепер працює інакше”. Так, у SMB менше даних, менше бюджету і слабша інфраструктура. Але в них є те, чого часто немає у великих компаній: можливість одночасно змінити і software, і сам бізнес-процес.
Можливо, саме тому найцікавіші production-кейси агентного AI найближчими роками з’являтимуться не лише у Big Tech. А в юридичних фірмах, рекрутингових агентствах, будівельних компаніях, HVAC-сервісах, бухгалтеріях, маркетингових агентствах та інших “нудних” бізнесах, де досі величезна частина роботи — це листи, таблиці, дзвінки, CRM і люди, які нагадують іншим людям зробити наступний крок.
І саме там агент може виявитися не ще одним chatbot, а новим операційним шаром компанії.