Уяви понеділок о 9:12. AI-агент пише: «Лід оброблено, задачу створено, менеджера призначено». Ти відкриваєш CRM. Лід є, але без відповідального. У задачах порожньо. А в пошті лежить чернетка листа, яку ніхто не просив надсилати.
Відповідь агента звучить впевнено. Вона навіть може чемно перелічувати кроки: прочитав, зіставив, створив, перевірив. Але бізнесу важливо не те, як гарно описано роботу. Важливо, що сталося в робочій системі після неї.
Саме тому перші тести агентів часто відчуваються дивно. Ти ніби передав рутину, а потім вручну перевіряєш CRM, задачі, файли й адресатів. Це не делегування. Це стара ручна робота, до якої додали обов’язкове читання оптимістичного звіту. Процес зламався настільки ввічливо, що його навіть незручно сварити.
Вихід не в тому, щоб вимагати від агента ще довшого звіту. Потрібен короткий контракт приймання: який стан має з’явитися, чим він доводиться, чого не має статися, що агенту дозволено записувати і коли він мусить зупинитися.
1. Красивий output, активність і результат - це різні речі
Перш ніж налаштовувати контроль, розділи три речі, які легко сплутати. Вони можуть бути частинами однієї роботи, але не замінюють одна одну.
Output: що агент сказав або показав
Output - це текст, таблиця, список контактів, чернетка листа або повідомлення «все виконано». Він корисний, щоб зрозуміти, що агент побачив і як пояснює свій висновок. Але сам по собі він не доводить, що щось змінилося.
Фраза «створив завдання для менеджера» не відповідає на базові запитання: де саме це завдання, хто виконавець, які поля заповнені, чи не з’явився дублікат. Впевнена мова не перетворюється на запис у системі лише тому, що в кінці є крапка.
Activity: що відбувалося дорогою
Activity - це перелік дій: агент відкрив лист, порівняв поля, знайшов картку, підготував дані, спробував створити задачу. Такий журнал може допомогти, коли треба розібрати виняток або помилку. Проте велика кількість кроків не робить фінальний стан правильним.
Принтер, який старанно друкує сорок сторінок не того документа, теж показує вражаючу активність. Користі від неї, на жаль, не додається.
Outcome: що перевірено змінилося
Outcome - це цільовий стан у робочій системі. Потрібний об’єкт створено або оновлено, ключові поля правильні, потрібна людина бачить його там, де очікує, а забороненої дії не сталося.
Якщо агент мав створити задачу, outcome - не повідомлення «задачу створено». Це одна конкретна задача в потрібному проєкті, з правильним виконавцем, даними для наступного кроку й без дубліката. Якщо агент мав відповісти на звернення, outcome на старті може бути лише збереженою чернеткою. Відправлений лист - це інша, ризиковіша дія.
Діагноз №1: звіт підміняє перевірку
Симптом простий: команда приймає роботу, бо у звіті написано «готово», але не може швидко показати конкретний створений або змінений об’єкт. Через кілька днів знаходяться пропущені задачі, дублікати чи записи в неправильній черзі. І вже складно зрозуміти, де саме почалася проблема.
Ліки теж прості: для кожної виконаної дії вимагай слід, придатний до перевірки. Це може бути ID або посилання на об’єкт, контроль значень обов’язкових полів, збережений файл чи запис у журналі. Людина не мусить щодня переходити за кожним посиланням. Але процес має дозволяти таку перевірку без археологічної експедиції по вкладках.
2. П’ять частин короткого acceptance contract
Acceptance contract - це не юридичний документ і не технічне завдання на п’ятдесят сторінок. Для першого процесу часто вистачає однієї картки. Її роль - прибрати різні тлумачення слова «готово» ще до запуску.
1. Цільовий стан
Опиши, що має бути правдою після роботи агента. Не дію, а саме стан.
Погано: «агент кваліфікує заявки». Краще: «для заявки, яка відповідає правилам, існує один запис у визначеній воронці; у ньому заповнені джерело й тема; менеджер бачить наступний крок». Такий стан можна побачити й перевірити без здогадок.
На старті не намагайся однією фразою охопити весь продаж або весь сапорт. Вузький стан не обмежує цінність тесту. Він робить її вимірюваною.
2. Доказ
Тепер назви, чим підтверджується цільовий стан. Доказ - не переказ агента про те, що він нібито зробив. Це слід у системі або повторювана перевірка.
Наприклад, перевірка може знайти один запис за ключем, підтвердити значення обов’язкових полів, показати місце збереження файлу або звірити адресата з погодженим списком. Audit trail і детерміновані перевірки зменшують ризик тихої помилки, хоча не роблять процес безпомилковим.
3. Заборонені побічні ефекти
Назви не лише бажаний результат, а й те, чого не має статися. Наприклад: не створювати дублікати, не змінювати власника наявної картки, не надсилати листи, не видаляти файли, не редагувати записи поза визначеною чергою.
Ця частина критична, бо побічні ефекти часто болючіші за пропущену дію. Один пропущений запис зазвичай можна створити пізніше. Непогоджене повідомлення або зіпсований наявний запис можуть потребувати значно більше ручного відновлення.
4. Право на запис
Окремо розділи, що агент може читати, що може готувати і що може змінювати сам. Це не недовіра до інструменту, а нормальна межа відповідальності.
Для першого тесту агент може читати вхідні звернення, класифікувати їх, створювати чернетки та додавати дані до окремої черги. Надсилання листа, зміна важливого статусу або видалення запису можуть залишатися за людиною. Саме так будують AI-системи з контрольованими діями: через визначені межі, а не через необмежений доступ у надії на найкраще.
5. Умова зупинки
Остання частина визначає, коли агент не має вгадувати. Він мусить зупинитися, позначити випадок і передати його людині.
Умовою зупинки може бути відсутній обов’язковий реквізит, суперечливі дані, незнайомий тип звернення, схожий наявний запис або дія поза правом на запис. Це не провал агента. Це правильна поведінка там, де ціна помилки вища за користь від автоматичного руху.
3. Діагноз №2: агенту дали задачу, але не дали меж
Запити на кшталт «розбери всі листи», «наведи лад у CRM» або «підготуй відповіді клієнтам» звучать зрозуміло для людини, яка знає контекст. Для агента це надто широкий простір для припущень. Він може намагатися бути корисним, але команда отримає рішення, яких ніхто не погоджував.
Умовний приклад: схожі дані в заявці
Припустімо, агент переносить заявки з пошти в CRM. Надходить лист від компанії, назва якої схожа на вже наявного клієнта, але контактна особа інша. Без умови зупинки агент може створити новий лід, об’єднати несумісні дані або переписати стару картку.
Контракт змінює поведінку. Агент створює запис лише за однозначними правилами. Якщо виявлено схожий запис, він не редагує жоден з них, лишає позначку для менеджера й додає доказ, чому зупинився. Людина вирішує конкретний виняток, а не відновлює дані наприкінці тижня.
Умовний приклад: відповідь готова, але надсилання не погоджене
Інша ситуація: агент аналізує звернення та готує відповідь. Текст може бути доречним, адресат - правильним, але контракт каже: «зовнішнє надсилання лише після approve». Тоді прийнятий outcome - чернетка в потрібній скриньці, прив’язана до звернення. Не відправлений лист.
Такий поділ не означає, що ти відмовляєшся від автоматизації. Ти перевіряєш класифікацію, маршрутизацію й підготовку даних, не додаючи до першого тесту незворотний комунікаційний ризик.
Межа робить помилку видимою
Коли межі описані, легше знайти справжню причину збою. Це проблема вхідних даних, правила маршрутизації, прав доступу чи критерію приймання? Без контракту всі ці причини зливаються у нечітке «агент десь не так спрацював».
Тому людина має задавати намір, межі ризикових дій і критерій приймання навіть тоді, коли агент сам проходить рутинні кроки. Агент виконує маршрут. Відповідальність за те, який маршрут допустимий, лишається у власника процесу.
4. Canary, QA і людський approve: кожен доводить своє
Не тестуй агента одразу на всій операції. Обери вузький маршрут, де зрозумілі вхідні дані, потрібний результат і спосіб зупинити помилку. Такий контрольний запуск називають canary.
Що доводить canary
Успішний canary доводить лише те, що агент пройшов конкретний маршрут у заданих умовах. Наприклад, узяв звернення певного типу, створив чернетку і лишив перевірюваний слід.
Він не доводить готовність до всіх мов, усіх нестандартних листів, будь-яких майбутніх змін у процесі або кожної нової інтеграції. Один вдалий запуск - причина зробити наступний обережний тест, а не причина видати агенту всі ключі від офісу, складу й кавомашини.
Що перевіряє QA
QA перевіряє контракт: чи досягнуто цільового стану, чи є доказ і чи не сталося заборонених побічних дій. Частина перевірок може бути детермінованою: існує один запис, заповнені необхідні поля, статус правильний, чернетка не перетворилася на відправлене повідомлення.
Такі перевірки особливо корисні там, де людина раніше повторювала однакову ручну звірку. Вони не скасовують здоровий глузд у складному випадку, але прибирають потребу щоразу вірити агенту на слово.
Коли approve лишається обов’язковим
Людський approve варто залишати для зовнішніх, чутливих або складно зворотних дій: надсилання повідомлення, передавання даних, зміни важливого статусу, редагування фінансово чи репутаційно важливого запису. Він також потрібен, коли дані суперечливі або не відповідають правилам.
Подивися, як обмежений маршрут може поєднувати машинну обробку й людський контроль, у кейсі Klar про поштові звернення. Його цінність не в обіцянці повної автономності, а в чітко окресленому процесі, який можна перевірити.
5. Діагноз №3: перевіряють успіх, але не відсутність шкоди
Команда бачить створену задачу й ставить галочку. Але водночас агент міг створити другу таку саму, призначити не того виконавця або торкнутися чужої черги. Якщо дивитися лише на позитивну частину outcome, тиха помилка легко проходить повз увагу.
Додай негативну перевірку
Для кожного очікуваного результату назви хоча б одну перевірку «цього не сталося». Для CRM це може бути відсутність дубліката за ключем. Для пошти - відсутність відправленого повідомлення. Для файлів - відсутність перезапису оригіналу. Для задач - відсутність змін у чужому проєкті.
Негативна перевірка не мусить бути складною. Вона просто визнає: успіх одного кроку не виправдовує небажаний наслідок в іншому місці.
Не плутай контроль із недовірою
Контракт не робить агента підозрюваним. Він робить очікування видимими для власника, операційної команди й того, хто налаштовує процес. Коли правила ясні, легше зрозуміти, що виправляти: дані, маршрут, права чи умову приймання.
Контроль також дає чесну відповідь на питання «чи можна розширювати тест». Не тому, що звіт став переконливішим, а тому, що конкретний маршрут лишив перевірений результат без заборонених наслідків.
6. Мінімальна картка результату і твій перший тест
Для першого тесту не потрібна складна панель керування. Візьми один повторюваний процес, де результат видно в конкретній системі, а помилку можна зупинити без шкоди. Наприклад, підготовку чернеток відповідей або створення задач із чітко структурованих звернень.
Картка з п’яти полів
Запиши на одній сторінці: цільовий стан, доказ, заборонені побічні ефекти, право на запис і умову зупинки. Додай один сценарій із нормальними даними та один з неоднозначними. Так ти перевіриш не тільки те, чи вміє агент рухатися вперед, а й те, чи вміє не робити зайвого.
Не чекай, що перша версія охопить усі винятки. Її завдання скромніше й корисніше: показати, чи можеш ти прийняти конкретний результат без ручного полювання по різних системах.
Один перший крок
Обери одну дію, яку агент уже нібито «завершує», і сьогодні запиши для неї один цільовий стан та один доказ у робочій системі. З цього починається перевірка, якій можна довіряти.