Вибір партнера для розробки AI-агентів: питання, які виходять за межі демонстрації.

Демо-версія може виглядати чудовою аж до моменту зустрічі з реальним бізнесом. У типовому випадку агент знаходить інформацію, складає відповідь та оновлює запис менш ніж за хвилину, і здається, що все готово до використання. Але потім з’являється безліч практичних питань. Що робити, якщо запис неповний? Чи може агент бачити дані, до яких працівник не має доступу? Чи буде він повторювати дію після тайм-ауту API? Хто буде розбиратися, якщо зміна виявиться неправильною?

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

Що змінилося до 2026 року

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

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

• Хто запускає робочий процес?
• Які системи беруть участь?
• Що може змінити агент?
• Де співробітнику потрібно щось схвалити?
• Як відновити завдання, яке не виконано?

Хто буде власником агента після запуску?

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

Почніть з процесу роботи

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

Перш ніж розпочати розробку, команда повинна чітко визначити наступне.

• Тригер, який запускає процес роботи.
• Інформація, необхідна для цього процесу.
• Системи, з якими він підключається.
• Моменти, коли приймаються рішення.
• Дії, які дозволені.
• Схвалення, які є необхідними.

Умови, які вважаються невдачею.

Критерії завершення.

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

Інтеграції важливіші за вікно чату

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

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

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

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

Дозволи показують, як ставляться до ризиків

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

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

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

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

Надійні знання

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

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

Кілька агентів не завжди краще

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

Кілька агентів мають сенс, коли у роботі справді є окремі ролі, наприклад:

• один агент збирає інформацію,
• інший перевіряє вимоги політики,
• третій підготовлює запропоновані дії,
• людина схвалює останній крок.

Важливе питання полягає не в тому, чи може постачальник створити систему з кількома агентами, а в тому, чи покращує додана структура результат. Надійний постачальник може пояснити, чому існує кожен агент, що він отримує, як передається робота між агентами та що відбувається, коли вони не погоджуються.

Обробка помилок

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

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

Метою не є вирішення кожного випадку. Часто правильною поведінкою є зупинка, постановка уточнювального запитання, повторна спроба обмеженої кількості разів або передача справи людині. Надійність також включає здатність розпізнати, коли продовження роботи буде помилкою.

Розгортання — це більше, ніж просто хостинг

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

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

Людський огляд, що відповідає наслідкам

Вимога схвалення для кожної дії агента майже не має сенсу та може перетворити корисну систему на повільну копію старого процесу. Повне відмінення людського контролю створює протилежну проблему. Розумним підходом є розміщувати схвалення там, де виникають наслідки. Агент може самостійно класифікувати запит, організовувати інформацію чи писати проєкт, тоді як оплата, зміна контракту, обмеження рахунку чи повідомлення з юридичною силою, надіслане за межі компанії, все ще може потребувати участі уповноваженого співробітника.

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

Відповідальність після запуску

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

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

Питання, які варто поставити перед вибором

Досконалість презентації має мати менше значення, ніж відповіді на кілька конкретних запитань.

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

Хороший постачальник відповідає простою мовою та пов’язує кожен технічний вибір із запропонованим робочим процесом.

Ключова ідея

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