Чому AI-агент на Stack AI не виходить із пілоту
Пілот AI-агента починається однаково: десяток заздалегідь відібраних питань, акуратно завантажена база знань, Stack AI впевнено відповідає — і рішення виглядає готовим.
У реальному процесі запит приходить з іншої системи, в іншому вигляді й від іншого користувача, і агент відповідає вже інакше.
Перший розрив контексту проявляється там, де демо обходилося пласким списком документів. У робочому сценарії агенту потрібні дані клієнта, історія звернень і зв'язки між записами з різних систем.
Без них він підставляє схожий за формулюванням, але неправильний факт, і помилка вилазить на першому серйозному запиті.
Друга причина — права доступу. Поки агент у пілоті один і працює на тестових даних, питання ролей не виникає. При підключенні до внутрішніх баз він або бачить зайве, або не знаходить потрібного — для замовника це вже не косметика, а ризик витоку.
Третя — немає власника змін. Регламенти й база знань живуть своїм життям, формулювання застарівають, а відповідального за якість відповідей немає. Агент деградує непомітно: спочатку рідкісні неточності, потім співробітники просто перестають ним користуватися.
Вузьке місце майже завжди не в моделі, а в процесі навколо неї. Тому впровадження AI-агента впирається в те, які дані й доступи він отримує на кожному кроці та хто відповідає за результат. Розбираємо, як це закривається на рівні архітектури.
Що змінюється після керованого впровадження агентів
Кероване впровадження починається не з показового діалогу, а з фіксації метрик, за якими агента прийматимуть.
Перш за все змінюється швидкість обробки звернень: агент сам запитує статус заявки, історію та залишки в облікових системах, збирає відповідь і віддає оператору готову чернетку. Цикл скорочується з десятків хвилин до однієї-двох, а людина займається лише спірними випадками.
Частка автовідповідей зростає не за рахунок «дозволити все», а за рахунок явного порогу впевненості та правил ескалації.
Ми описуємо, які типи запитів агент закриває сам, які віддає з позначкою «перевірити», а які одразу переводить на оператора — з повним контекстом діалогу, щоб той не перепитував заново.
Далі зникає клас відмов, який зазвичай з'їдає підтримку: відповіді за застарілою інструкцією, втрата запиту між системами, «попливла» логіка після правки.
Набір регресійних діалогів із реальних звернень проганяється при кожній зміні, а попередня версія конфігурації відкочується однією дією.
Стабільність агента — наслідок спостережуваності. Кожен крок пишеться в журнал: який інструмент викликано, які дані повернулися, де спрацювала ескалація. За цими записами видно, що справді впливає на якість відповідей, а правка однієї гілки не ламає сусідні.
Контроль якості стає регламентом, а не разовою перевіркою: вибірку оцінюють за рубриками, розбіжності розмічуються й перетворюються на нові перевірки.
Логіка агента описується без коду в Stack AI — нова версія узгоджується й випускається за години, і ефект від впровадження відтворюється, а не тримається на одному інженері.
Варіанти складання агентів на Stack AI: конструктор, код, гібрид
Режим складання визначає не «розумність» агента, а те, хто і як швидко зможе його змінювати після запуску. У Stack AI доступні три підходи: візуальний конструктор агентів, власне складання та гібрид, де каркас діалогу збирається мишкою, а критичні вузли дописуються інженером.
Різниця проявляється на супроводі: сценарій у конструкторі править керівник напряму, логіку в коді — лише розробник.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Візуальний конструктор | Процеси з зрозумілими кроками: прийом заявки, маршрутизація звернень, відповіді за базою знань | Складні розгалуження та нестандартні інтеграції впираються в набір готових блоків |
| Власне складання агента | Нестандартна логіка, власні моделі, жорсткі вимоги до обробки даних | Правки йдуть через цикл випуску версії, на підтримці потрібен інженер |
| Гібрид | Типовий сценарій з одним-двома унікальними ділянками: розрахунки, звірка з обліковою системою | Потрібно заздалегідь домовитися про межу: що правиться в конструкторі, що в коді |
Вибір режиму впровадження йде не від модного слова, а від трьох питань: як часто змінюються правила процесу, скільки зовнішніх систем потрібно зачепити і наскільки жорстко регламентовано доступ до даних. Часті правки формулювань і порогів — конструктор.
Рідкісні, але глибокі зміни — код. Коли процес живе й змінюється, але містить ділянку, яку конструктором не описати, дешевше й надійніше гібрид: межа фіксується в документації, і обидві сторони знають, де шукати причину збою.
Порядок робіт: від аудиту процесів до передачі в підтримку
Впровадження агента починається не з налаштування, а з розбору процесу: які звернення надходять, хто обробляє їх зараз, де втрачається час і на яких кроках потрібна людина. Аудит займає кілька днів і одразу показує, які ділянки віддавати агенту, а які залишити людям.
За його підсумками з'являється схема ролей, межі відповідальності та маршрут передачі в експлуатацію.
- Аудит процесу. Розбираємо потік звернень, рахуємо частку повторюваних дій, відзначаємо кроки, де ціна помилки висока. На виході — перелік операцій під автоматизацію та точки, де людина залишається обов'язковою.
- Схема агента й ролей. Визначаємо, які дані агент читає, до яких систем звертається і що робить при нестачі відомостей. Фіксуємо, де він відповідає сам, а де готує чернетку для оператора.
- Налаштування сценаріїв. Збираємо гілки діалогу та правила передачі людині в Stack AI, підключаємо бази знань і довідники. У кожного сценарію є межі: тема, допустимі дії, умова зупинки.
- Перевірка на реальних даних. Проганяємо агента на історичних зверненнях, а не на вигаданих прикладах. Рахуємо частку діалогів, закритих без оператора, і розбираємо кожну помилкову відповідь.
- Правки за результатами перевірки. Уточнюємо формулювання, додаємо відсутні правила, прибираємо гілки, що ведуть у глухий кут. Двох-трьох ітерацій зазвичай достатньо, щоб агент перестав вигадувати й коректно передавав складне людям.
- Передача в експлуатацію. Віддаємо команді замовника схему агента, описи сценаріїв, правила оновлення бази знань і порядок відкату. Проводимо навчання, щоб правки вносилися без нашої участі.
Маршрут завершується не запуском, а зняттям залежності від підрядника: команда розуміє, як змінювати сценарії та куди дивитися при відхиленнях. Опишіть свій процес — повернемося з оцінкою та планом за цими етапами.
Конфігурації, регламенти й документація на виході
Проєкт закритий не тоді, коли агент відповідає на демо-запитах, а коли ваша команда може сама його змінювати, зупиняти й відновлювати. Тому разом з робочим сценарієм на Stack AI ми передаємо комплект, за яким інженер, який не брав участі в розробці, розбереться без нас.
- Передані конфігурації — вивантаження сценаріїв, інструкцій агента, наборів інструментів і правил маршрутизації. Розгортаються у вашому контурі без правок «за пам'яттю».
- Схема інтеграцій — джерела даних, типи підключень, черги, обмеження на частоту звернень і точки відмови із зазначенням, що робити при обриві.
- Матриця доступу — ролі співробітників і сервісні облікові записи: кому читання, кому запуск, кому правка сценарію та публікація в робочий контур.
- Регламент експлуатації — що і з якою періодичністю перевіряється, які метрики вважаються відхиленням, хто реагує на помилки і в якому порядку.
- Документація агента — логіка обробки запиту, вхідні та вихідні дані, залежності від зовнішніх систем і типові причини відмов.
- Регламент змін і відкат — як правка проходить перевірку, хто погоджує публікацію і за який час виконується повернення до попередньої версії.
- Набір еталонних перевірок — типові запити з очікуваними відповідями: після кожної правки видно, чи не зламалося те, що вже працювало.
Усе передане лежить на ваших облікових записах і у вашому репозиторії — робота агента не зав'язана на нашу команду.
Кейс: розбір заявок у підтримці — метрики до і після
Підтримка сервісу прийшла до нас із потоком 6–8 тисяч звернень на місяць, і вся черга розбиралася вручну. Оператор відкривав лист, визначав тему, шукав замовлення в обліковій системі, звіряв статус і писав відповідь.
Типові питання — де посилка, як повернути товар, як продовжити підписку — з'їдали більше половини робочого часу, хоч вимагали тих самих дій, що й складні розбори.
Як влаштований контур агента
Контур зібрали на Stack AI, без розробки моделей з нуля: звернення з пошти та форми на сайті потрапляють в один вхід, текст нормалізується, агент визначає тему й витягує обов'язкові поля — номер замовлення, категорію, суть запиту.
Далі рішення розходиться трьома гілками: типове закривається відповіддю з бази знань з перевіркою умови, неповне повертається клієнту з уточнювальним питанням, нестандартне йде оператору разом із готовою чернеткою та знайденим замовленням.
Спірні теми, претензії та все, де згадано повернення коштів або юридичні формулювання, передаються людині одразу — без спроби автозакриття. Кожен крок агента логується в системі заявок, тому розбір помилок іде за фактичними ланцюжками, а не за відчуттями.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Звернення, закриті без оператора | 0% | 46% |
| Час першої відповіді | 4–6 годин | 3–7 хвилин |
| Повна обробка типової заявки | близько робочого дня | 10–20 хвилин |
| Помилки маршрутизації | 18% | 4% |
Результат автоматизації тримається не на моделі, а на регламенті: оператори розмічують спірні розбори, ця розмітка раз на два тижні йде в базу знань і правила розгалуження.
Після запуску частка повторних звернень з однієї й тієї ж теми впала приблизно втричі — клієнт отримує відповідь у першому ж повідомленні, а не після листування.
Що робити, якщо агент уже зібраний на іншому конструкторі
Перенести агента між конструкторами «як є» не можна: платформи по-різному описують розгалуження, виклик інструментів і зберігання контексту. Але цінність тут не в прив'язці до платформи, а в змісті — текстах ролей, правилах поведінки, базі знань, переліку інтеграцій. Це переноситься й визначає, як швидко агент вийде на попередній рівень якості.
Майже без змін ідуть системні підказки, структура бази знань за документами, готові формулювання відповідей і перелік зовнішніх систем з правами доступу.
Перескладається те, що описує поведінку: умови переходів між кроками, порядок звернення до інструментів, обробка помилок і повторних спроб, правила передачі діалогу людині. Ці місця збираються заново за описом логіки — копіюванням блоків їх не перенести.
Щоб не розгубити напрацювання, починаємо з інвентаризації: вивантажуємо історію діалогів і список сценаріїв, відокремлюємо робочі від чернеток. З живих запитів збираємо контрольний набір — кілька десятків типових і пограничних звернень з еталонними відповідями.
Це вимірювана планка: після перескладання проганяємо той самий набір і бачимо, де поведінка розійшлася.
Каркас піднімається на Stack AI і перевіряється на контрольному наборі до перемикання трафіку. Потім тіньовий режим: частину звернень обробляють обидва агенти, відповіді порівнюються, розбіжності розбираються вручну.
Переведення трафіку — поступове, з можливістю повернутися на попередню платформу, поки нова не покаже зіставний результат.
Технічні сумніви перед стартом впровадження
Заперечення на технічному розборі зазвичай одні й ті самі: як перевірити якість відповідей до експлуатації, що робити з обліковою системою без готового підключення, як обмежити права агента і хто відповідає за роботу після запуску. Відповідаємо по суті — всі перевірки проходять до промислової експлуатації.
Як переконатися в якості відповідей до експлуатації?
Збираємо перевірочний набір реальних запитів співробітників і розмічуємо еталонні відповіді разом з вашою командою. Прогін показує частку правильних і частку недостовірних відповідей, помилки розбираємо за типами: не те джерело, застарілі дані, неправильне трактування. Поріг приймання фіксуємо письмово — не досягнуто, експлуатація не стартує.
Що робити, якщо для облікової системи немає готового підключення?
Підключаємося через прикладний програмний інтерфейс системи, вебхуки або регламентне вивантаження в проміжне сховище. На Stack AI сценарій збирається поверх цих джерел без доопрацювання самої облікової системи. Режим оновлення обираємо за завданням — за подією або за розкладом, з журналом розбіжностей.
Як обмежити доступ агента до даних?
Агент працює під окремим сервісним обліковим записом з правами лише на читання потрібних реєстрів. Фільтрація відповідей іде за атрибутами користувача: співробітник філії не отримає дані іншої філії, навіть якщо переформулює запит. Усі звернення логуються — хто спитав, що отримав, з якого джерела.
Хто супроводжує рішення після запуску?
Передаємо регламент: як поповнюється база знань, хто затверджує зміни правил відповіді, які метрики дивимося — частку невдалих відповідей, час відгуку, частку передач живому фахівцю.
Планові перевірки запускаємо при кожній зміні облікових систем, інакше агент починає відповідати за застарілими довідниками.
Обговоримо завдання і повернемося з оцінкою та планом робіт
Щоб оцінка обсягу робіт спиралася на факти, а не на припущення, на вході нам достатньо короткого набору відомостей. Опишіть завдання так, як воно виглядає у вас усередині — цього вистачить, щоб повернутися з планом впровадження та зрозумілими межами етапів.
- мета сценарію та метрика приймання: за яким показником ви зрозумієте, що агент працює — частка звернень, закритих без оператора, час відповіді, точність розбору заявок;
- склад вихідних даних: де лежать регламенти, база знань, історія листування, хто власник цих систем і хто видає доступи;
- 10–20 реальних прикладів запитів і еталонних відповідей — на них видно, де рішення помиляється і що доведеться донавчати;
- обмеження щодо даних і контуру: персональні дані, вимоги служби безпеки, де фізично може працювати агент;
- ролі: хто з боку замовника приймає результат і хто бере участь у прийманні етапів;
- що вже пробували і чому не підійшло — це економить один-два кола ітерацій.
Далі на розборі уточнюємо те, що не читається з документів: пікове навантаження, поведінку при відмові зовнішньої системи, формат відповіді користувачу та точки, де обов'язково потрібна людина.
Якщо обираєте між готовим no-code конструктором на кшталт Stack AI і складанням на програмній інтеграції — порівняємо обидва варіанти за вашими сценаріями, а не за загальними описами.
Повертаємося з оцінкою обсягу робіт, планом впровадження за етапами, складом команди, строками та переліком ризиків разом із тим, як кожен знімаємо. Старт проєкту — після узгодження плану й відкриття доступів до даних. Опишіть завдання у вільній формі: цього достатньо, щоб ми повернулися з оцінкою та планом робіт.
