Агентні workflow, що не ламаються: виклик інструментів, людина в циклі та шви між системами

Автоматизацію бізнес-процесів і AI-агента продають як одне й те саме, а це не так. Автоматизація - фіксований пайплайн: крок два завжди йде за кроком один однаково. Агент - це цикл, де модель вирішує, який крок наступний, на основі того, що щойно повернув виклик інструмента. Обом є місце - більшості бізнесів реально потрібна автоматизація з однією-двома агентними точками рішення, а не агент, що приймає кожне рішення.

Архітектура під будь-яким із них визначає, чи виживе воно при контакті з реальними даними: як ви подаєте моделі контекст, як отримуєте відповідь у формі, якій код може довіряти, як модель дотягується до інших систем, і де людині все ще треба сказати «так». Саме на цій обвʼязці, а не на виборі моделі, я витрачаю більшість часу проєкту.

1. Контекст-інжиніринг: подати моделі правильний зріз, а не все підряд

Контекст-інжиніринг - негламурна робота вирішення, що модель бачить у конкретному виклику: які записи, які попередні репліки, які інструкції - і, так само важливо, чого вона не бачить. Скидати всю історію клієнта чи весь документ у промпт щоразу - це не ретельність, це шум, який відсуває реальне питання далі від уваги моделі і тихо роздуває вартість кожного виклику.

Паттерн, що витримує навантаження, ближчий до задачі пошуку, ніж до задачі памʼяті: витягнути два-три записи, релевантні саме цьому кроку, підсумувати те, що було раніше, замість дослівного повтору, і дати агенту запитати більше лише коли треба. Workflow, що надійно дістає правильні пʼять рядків із десяти тисяч, кращий за той, що напихає всі десять тисяч і сподівається.

2. Структуровані виводи та виклик інструментів/функцій - це і є реальний інтерфейс

Модель, що відповідає вільним текстом і парситься regex-ом, - місце, де такі білди тихо ламаються в проді. Структуровані виводи - JSON Schema, у межах якої модель змушена відповідати, - і виклик інструментів/функцій - модель запитує конкретну функцію з типізованими аргументами замість опису дії прозою - дозволяють вашому коду достатньо довіряти відповіді, щоб діяти без людини, яка перечитує кожен вивід.

Я валідую схему на виході з моделі і ще раз перед тим, як вона досягне реальної системи, бо модель може видати синтаксично коректний JSON, який все одно неправильний з точки зору бізнес-правила - відʼємна кількість, дата в минулому, валюта, яку акаунт не підтримує. Схема ловить помилки форми; другий, нудний шар валідації ловить ті, що є валідним JSON і все одно неправильні.

3. Embeddings і векторна база - лише коли пошук справді є задачею

Embeddings і векторна база окуповують себе, коли задача справді є пошуком: знайти три тикети підтримки, найближчі до цього нового, знайти пункт у договорі, найближчий до цього питання. Це неправильний інструмент для фіксованого, невеликого набору записів, який уже покриває звичайний запит до бази даних - я бачила векторну базу, приліплену до workflow з одинадцятьма можливими категоріями, де таблиця пошуку була б швидшою, дешевшою і легшою для дебагу.

Коли це правильний інструмент, увага потрібна не моделі embedding, а тому, що і як розбивається на шматки, і наскільки свіжим лишається індекс після зміни вихідного документа. Векторний пошук по застарілих шматках дає впевнену, але неправильну відповідь, і ніщо у виводі агента не скаже вам, що це сталося.

4. Людина в циклі та оркестрація API: де це реально ламається

Провал, який я бачу найчастіше, - не погане міркування моделі, а шов між двома системами: виклик API, що таймаутиться, і агент повторює його двічі, надсилаючи дубльоване замовлення; webhook, що спрацьовує до того, як попередній крок дописав дані; виклик інструмента, що успішний на боці постачальника, але відповідь, яку отримує агент, каже про провал. Оркестрація викликів між CRM, білінгом і поштою означає рішення про те, що відбувається при таймауті чи частковому провалі, - до того, як це трапиться в проді, а не після.

Усе, що надсилає гроші, видаляє запис чи пише клієнту, отримує крок підтвердження людиною перед спрацьовуванням - не тому, що модель загалом ненадійна, а тому що вартість неправильної автоматичної дії асиметрична з вартістю одного зайвого кліка. Я краще дам людині схвалити двадцять правильних дій на день, ніж дозволю агенту автоматично надіслати один неправильний рахунок.

Висновок: агент - це легкі 10%

Обрати модель і написати перший промпт - справді легка частина агентного workflow. Контекст, який подається, схема, яка валідується, векторний пошук, що запускається лише коли треба, логіка повторів через три API, і той один крок, який досі схвалює людина - це решта 90%, і саме вони вирішують, чи автоматизація й досі працюватиме у вівторок через шість місяців на даних, які ніхто не тестував. Напишіть через форму, який процес хочете автоматизувати, і я скажу, які 10% - це агент, а які 90% - те, що реально треба будувати.