Не питайте, скільки у вас агентів. Питайте, скільки їхніх відповідей ви пускаєте без перевірки

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

Чому adoption rate вимірює намір, а не результат?

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

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

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

Частка приймання: що саме рахувати?

Частка приймання — це відсоток відповідей агента, які пішли далі без втручання людини. «Далі» означає конкретну дію: лист відправлено, поле в CRM записано, тікет закрито, документ переданий у роботу. Знаменник — усі відповіді, які агент видав у цьому процесі за період, включно з тими, що не дійшли до дії.

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

Які три події не можна складати в одну?

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

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

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

Що показали ті, хто вже це міряв?

Публічний замір частки приймання з розкритою методикою зробив GitHub на власному продукті. У дослідженні Ziegler та колег (2022, 2631 відповідь в опитуванні, з них 2047 зіставлені з телеметрією IDE) перевіряли, яка метрика використання найкраще передбачає відчуття продуктивності розробника. Виграла частка прийнятих підказок: на когорті учасників дослідження вона становила 27%. Сама кореляція слабка (ρ = 0,24) — метрика виявилася найкращою серед перевірених, а не сильною сама по собі.

Друга робота ближча до агентів. Дослідники Sierra AI у 2024 році показали на бенчмарку τ-bench, що агент, який успішно закрив задачу один раз, зовсім не обов'язково закриє її вдруге. Вони запропонували рахувати pass^k — імовірність пройти ту саму задачу k разів поспіль. Найкращий на той момент агент на GPT-4o давав менш ніж 50% успіху в середньому, а на восьми послідовних спробах у роздрібному сценарії опускався приблизно до 25%. Моделі з того заміру давно застаріли, і повторювати ці відсотки як актуальні не варто. Забирати варто конструкцію: одноразовий успіх у демонстрації не є доказом надійності.

Третій орієнтир дає METR — некомерційна дослідницька організація, яка займається оцінюванням моделей. У роботі 2025 року вона міряє спроможність моделі довжиною задачі, яку та здатна довести до кінця самостійно, і публікує цю довжину одразу для двох планок надійності: 50% успіху і 80%. Різниця між ними велика, і чесна розмова про автономію ведеться по вищій планці.

А от чисел про частку ручного контролю за функціями — на кшталт «у юристів 61%, у продажників 8%» — ми в публічному доступі не знайшли. Вони ходять по оглядових статтях із посиланням на великі аналітичні агентства, але первинного звіту, який можна відкрити і перевірити, за ними не видно. Тому в цьому тексті їх немає.

Чому «без правок» — правильна планка для агента і неправильна для копайлота?

Крім частки прийнятих підказок, автори того ж дослідження рахували persistence — чи залишилася прийнята підказка незмінною через 30, 120, 300 і 600 секунд. Ця метрика корелювала з продуктивністю гірше. Розробникам не заважало доопрацьовувати підказку, якщо вона давала придатну відправну точку.

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

Як цю метрику підробити?

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

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

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

Чи існує нормальна частка приймання?

Універсального доброго числа немає, і будь-хто, хто називає вам галузевий стандарт частки приймання, називає вигадку. Орієнтир задає не галузь, а ціна помилки в конкретному процесі.

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

Правильне питання звучить не «як підняти частку приймання», а «чи відповідає вона ціні помилки в цьому процесі». Іноді відповідь на нього — залишити все як є.

Чому це метрика про гроші, а не про технології?

Порахуйте на власних числах. Припустімо, агент обробляє двісті звернень на день, а кожну відповідь, яку не прийняли одразу, людина перечитує по три хвилини. При частці приймання 30% перевіряти доводиться сто сорок відповідей — сім годин щодня, майже повна ставка. При 70% лишається шістдесят відповідей і три години. Ескалації в цьому розрахунку пораховані як витрата часу навмисно: по суті вони правильні, але людину все одно займають.

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

Чого частка приймання не показує?

Метрика має чесні межі, і про них варто знати до того, як ви поставите її в договір.

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

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

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

Сам Intercom, який будував на подібній метриці свій рахунок, у власних матеріалах 2026 року пише, що переходить від бінарного «закрив чи не закрив» до оцінки результату, бо успіх перестав бути двійковим. Там же він наводить середню частку самостійно закритих звернень для агента Fin — 76% у понад семи тисяч команд. Це самозвіт постачальника, не незалежний замір, і читати його треба саме так.

Як зняти базову частку приймання за два тижні?

• Оберіть один процес, а не всі одразу. Метрика, посаджена на весь парк агентів, дає середню температуру і жодного рішення.
• Визначте одиницю виміру: одна відповідь агента — один рядок у журналі. Домовтеся про це письмово до старту.
• Логуйте три поля на кожен рядок: чи змінювала людина зміст, чи була ескалація, чи спрацював guardrail. Форматування і тон рахуйте окремим лічильником.
• Не чіпайте промпт і налаштування два тижні. Правки під час заміру знищують базу, з якою ви потім порівнюватимете наступну версію.
• Порахуйте три частки і подивіться на розподіл по днях, а не тільки на середнє. Провал у конкретні дні зазвичай вказує на тип звернень, а не на модель.
• Додайте вибіркову перевірку: п'ять відсотків прийнятих відповідей перечитує людина. Без цього кроку число вам лестить.

Два тижні — мінімум, за який видно тижневий цикл навантаження. Якщо у процесі є місячна сезонність (закриття періоду, звітність), базу треба знімати довше.

Як сформулювати поріг приймання в договорі?

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

Формулювання, яке має сенс у SOW, виглядає приблизно так: на погодженому наборі з N реальних звернень частка відповідей, прийнятих без змістовних правок, не нижча за X відсотків при нульових порушеннях guardrails, замір проводиться на боці замовника й на його даних.

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

Що Auspex робить на впровадженні?

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

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

З чого почати цього тижня?

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

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