Чому складним AI-агентам замало просто чату

У юридичній галузі та інших «вертикалях» штучний інтелект уже вміє виконувати довгі, багатокрокові завдання — від аналізу контрактів до підготовки документів. Але досвід роботи з такими агентами часто розчаровує: вони «думають» пів години, повертають результат, а потім руйнують усе при найменшій правці. CTO стартапу Legora Якоб Лаурітцен на конференції AI Engineer пояснив, чому проблема не в моделях, а в тому, як ми з ними взаємодіємо — і чому чат‑інтерфейсу для цього вже недостатньо.

Нові «економіки виробництва»: робота дешева, планування й рев’ю — ні

За останні 6–12 місяців змінилася сама структура роботи з AI‑системами:

• Виконання роботи стало дешевим. Моделі легко пишуть код, генерують тексти, аналізують документи.
• Вузьким місцем стали планування та перевірка. Потрібно:
• зібрати вимоги й специфікації;
• спланувати кроки;
• ретельно перевірити результат.

У розробці це нагадує рев’ю величезних pull request’ів: технічно можливо, але болісно й неефективно. Ідея «нехай агент перевіряє сам себе» виглядає привабливо, але працює далеко не завжди — особливо там, де немає очевидного критерію правильності.

«Правило верифікатора» і чому не всі задачі піддаються агентам

Корисна рамка для розуміння можливостей агентів — правило верифікатора (verifier’s rule), сформульоване Джейсоном (прізвище в доповіді не уточнюється):

Якщо задачу можна розв’язати і її легко перевірити, її розв’яже AI.

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

Проблема в тому, що в реальних вертикалях задачі розташовані на різних ділянках спектра «легко/важко перевірити».

Приклад: юридична галузь

• Перевірка визначень у контракті
  Легко верифікувати: чи всі терміни визначені, чи всі визначення використовуються. Це добре піддається автоматизації.
• Написання контракту загалом
  Згенерувати текст — нескладно. Але перевірити, чи «правильний» цей контракт, часто можна лише в суді, коли суддя фактично виступає остаточним верифікатором. Це робить задачу дуже складною для повної автоматизації.
• Стратегія судового спору (літигації)
  Якщо п’ять юристів дадуть п’ять різних стратегій, немає об’єктивної «єдино правильної» відповіді. Верифікація тут майже неможлива.

Схожа ситуація й у розробці: написати функцію з тестами — просто, а от створити успішний consumer‑додаток і довести, що він «правильний», — зовсім інший рівень складності.

Звідси ключовий висновок: людей потрібно залучати там, де верифікація складна або суб’єктивна, а агентам віддавати те, що можна чітко перевірити.

Довіра й контроль: як правильно ділити роботу між людьми та агентами

Для ефективної співпраці людини й агента важливі дві осі:

• Довіра (trust) — скільки роботи можна не перевіряти.
• Контроль (control) — наскільки ефективно людина може «вшити» свій досвід і судження в роботу агента.

Як підвищити довіру до агента

1. Зробити задачу більш верифікованою
2. У розробці:
   • дати агенту доступ до браузера;
   • використовувати TDD (спочатку тести, потім реалізація).

   Тоді «реалізувати фічу» перетворюється на задачу «зробити так, щоб усі тести проходили», а це вже легко перевірити.

3. У фінансах чи праві можна шукати проксі‑метрики верифікації.
   Наприклад, для контрактів:
   • взяти «золоті» (еталонні) контракти, які добре працювали в минулому;
   • порівнювати новий контракт із цими зразками;
   • будувати тести на схожість структури, формулювань, ключових положень.

   Це не ідеальна верифікація, але корисний наближення, яке суттєво підвищує якість роботи агента.

4. Декомпозувати задачу

Замість «написати контракт» — розбити роботу на підзадачі:

• людина вирішує:
  • профіль ризику;
  • вибір прецедентних документів;
  • переговорну позицію;
• агент виконує те, що легко перевірити:
  • форматування;
  • уніфікація стилю;
  • «лінтинг» визначень (чи всі терміни визначені й коректно використані).

Так людина зберігає контроль над критичними рішеннями, а агент бере на себе рутинну, але формалізовану роботу.

1. Встановити guardrails (обмеження)

Це спосіб підвищити довіру, обмеживши можливості агента:

• можна редагувати лише конкретні файли;
• читати лише з певних директорій;
• шукати інформацію лише на визначених сайтах.

Чим менше свободи для «дивних дій», тим легше довіряти системі.

Приклад із розробки: у режимі низької довіри агент запитує дозвіл на кожну дію (як це роблять деякі інструменти на кшталт Claude Code), що робить його майже непридатним для реальної роботи. У режимі високої довіри — «YOLO‑режим», коли агент може робити все, включно з ризикованими операціями (на кшталт видалення прод‑бази), і це вже питання організації безпеки.

Як підвищити контроль над агентом

Складну роботу агента можна уявити як дерево або DAG завдань:

• корінь: загальне завдання (наприклад, «підготувати звіт за пакетом трудових контрактів»);
• гілки: дослідження організації, аналіз контрактів, перевірка окремих типів положень;
• листя: конкретні перевірки, витяг фактів, формулювання висновків.

1. Планування: корисно, але недостатньо

На етапі планування агент пропонує кроки: що дослідити, які пункти перевірити, як структурувати роботу. Людина може:

• скоригувати план;
• додати чи прибрати кроки;
• уточнити, на що звернути увагу.

Це дає більше контролю, ніж повна «чорна скринька», але має суттєві мінуси:

• щоб якісно скоригувати план, людині все одно потрібно глибоко зануритися в задачу;
• агент не знає наперед усіх нюансів (наприклад, спеціальної умови в одному з контрактів), тож план неминуче буде неповним;
• після узгодження плану агент часто «зникає» до фінального результату — як колега, який один раз показав план роботи, а потім повернувся лише з готовим документом.

Тому планування — корисний, але не достатній механізм контролю.

2. Skills: «вшивання» людського досвіду в вузли роботи

Більш потужний підхід — skills (навички), тобто формалізовані способи виконання окремих підзадач. Наприклад:

• «як перевіряти пункт про конфіденційність»;
• «як враховувати специфічний пункт законодавства ЄС у розділі про розірвання договору».

Переваги skills:

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

Мінус очевидний: skills не покривають усе. Неможливо заздалегідь описати кожен можливий випадок.

3. Еліцитація: питати людину, але без «інфінітного чату»

Коли навички не вистачає, наступний рівень — elicitation, тобто цілеспрямоване залучення людини:

• агент приходить із конкретним питанням: «Я натрапив на такий випадок, як мені діяти?»;
• бажано, щоб агент не блокувався: якщо не впевнений, він:
• приймає тимчасове рішення;
• записує його в журнал рішень (decision log);
• продовжує роботу.

Потім людина може:

• переглянути журнал;
• скасувати або скоригувати окремі рішення.

Ключова проблема тут — інтерфейс. Якщо всі ці питання та рішення відбуваються в одному довжелезному чаті:

• контекст губиться;
• складно зрозуміти, до якого саме кроку роботи належить питання;
• користувачеві важко відповісти, не бачачи повної картини.

Чат виявляється одновимірним і низькопродуктивним способом керувати складним деревом роботи.

Чому чат — це тупик для складних агентів

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

• одновимірність: довге дерево завдань стискається в лінійну стрічку повідомлень;
• низька пропускна здатність: важко одночасно бачити структуру роботи, стан підзадач і місця, де потрібне втручання;
• погана прив’язка до артефактів: питання агента не завжди очевидно пов’язані з конкретним фрагментом коду, документа чи даних.

Для реальної спільної роботи потрібні «високоширокосмугові» (high‑bandwidth) артефакти, які:

• є стійкими (persistent) — зберігаються й розвиваються з часом;
• природні для конкретної галузі;
• дозволяють одночасно бачити структуру, контекст і зміни.

Приклади таких артефактів

1. Документ як спільний простір роботи

У юридичній практиці це звичний формат співпраці між людьми, і він добре підходить і для агентів:

• можна виділити конкретний пункт (наприклад, третій) і змінити лише його;
• залишати коментарі;
• «тегати» агентів або колег;
• делегувати окремі частини документа спеціалізованим агентам.

Це дає високий контроль і зрозумілий спосіб вносити судження без руйнування всього результату.

1. Табличний огляд (tabular review)

Для масового аналізу контрактів зручно мати табличний інтерфейс, де:

• рядки — окремі документи;
• стовпці — ключові параметри або типи положень;
• агент:
  • проходить усі контракти;
  • автоматично заповнює більшість полів;
  • позначає лише ті місця, де потрібна думка людини.

Людина отримує:

• швидкий огляд того, що зробив агент;
• можливість точково внести правки;
• ефективний спосіб «вшити» свій досвід у роботу системи.

Після такого огляду можна знову запускати агента, уже з урахуванням уточнень.

Мова — універсальний інтерфейс, але не єдиний для агентів

Природна мова — універсальний спосіб комунікації між людьми. Вона дозволяє:

• ставити завдання;
• уточнювати вимоги;
• пояснювати контекст.

Але в людей є обмеження: ми прив’язані до мови. Навіть коли хочемо показати структуру (наприклад, оргструктуру компанії), часто змушені описувати її словами, хоча було б зручніше одразу намалювати схему.

Агенти таких обмежень не мають:

• вони можуть одночасно працювати з текстом, структурованими даними, графами, таблицями, документами;
• їм не потрібно «стискати» складну структуру в лінійний діалог.

Тому обмежувати агентів лише чат‑інтерфейсом — штучне й шкідливе обмеження. Для складних, довготривалих завдань потрібні:

• артефакти, природні для конкретної галузі (документи, таблиці, графи);
• інтерфейси, які відображають структуру роботи;
• механізми локального втручання людини (skills, decision logs, точкові правки).

Висновок

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

• не дає достатнього контролю;
• ускладнює верифікацію;
• погано масштабується на великі дерева роботи.

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

Source

Agents need more than a chat – Jacob Lauritzen, CTO Legora