Компанія, яка продає інструменти для контролю витрат на AI-агентів, сама зіткнулася з неконтрольованим зростанням рахунку від власного AI-агента — і не змогла вчасно його зупинити. За даними ZDNet AI, саме цей випадок став показовим прикладом того, наскільки складно приборкати автономні агентні системи навіть тим, хто на цьому спеціалізується.
Іронія тут не в тому, що хтось помилився — а в тому, хто саме помилився. Компанії, які продають AI cost-management, будують продукт саме навколо обіцянки: ми бачимо кожен токен, кожен виклик API, кожен агентний цикл, і зупинимо витрати до того, як вони вийдуть з-під контролю. Якщо цей продукт не впорався з витратами власного ж агента, це питання не до конкретного вендора, а до того, наскільки взагалі керована агентна архітектура за замовчуванням.
Для AI-білдерів це не курйоз для сміху, а безкоштовний стрес-тест чужими руками: те, що сталося у профільної компанії з повним доступом до власних метрик, тим паче може статися в команді, яка тільки-но підключила агента до продакшену.
Що саме сталося з витратами агента?
За словами джерела, компанія, що спеціалізується на контролі AI-видатків, зафіксувала неконтрольоване зростання витрат саме від власного агента — тобто інструменту, який за задумом мав би моніторити й обмежувати подібні сценарії для клієнтів. Це не історія про зовнішню атаку чи зламаний API-ключ, а про те, що агент у штатному режимі роботи наростив рахунок швидше, ніж команда встигла це помітити й відреагувати.
Ключовий урок тут — розрив між «маємо дашборд з витратами» і «маємо працюючий hard stop». Дашборд показує факт постфактум; агент, який виконує цикли викликів у реальному часі, встигає витратити бюджет задовго до того, як людина відкриє звіт.
Чому агентні системи так легко злітають з бюджету?
Агент відрізняється від звичайного API-виклику тим, що сам вирішує, скільки разів звернутися до моделі. За нашою оцінкою, у практиці останніх двох років найчастіше зустрічаються кілька типових причин розгону витрат:
- Цикли самовиправлення — агент бачить помилку, генерує новий запит, знову помилка, знову запит, і так по колу без явного ліміту ітерацій;
- Паралельні підагенти — оркестратор породжує кілька дочірніх агентів на одну задачу, і кожен з них тягне власний контекст і власні виклики моделі;
- Розбухання контексту — з кожним кроком в історію діалогу додається все більше токенів, і навіть проста дія починає коштувати як складна;
- Автономний вибір дорожчої моделі — коли агенту дозволено самому обирати, яку модель викликати для підзадачі, він не завжди оптимізує за ціною.
Жоден з цих механізмів окремо не є катастрофою. Проблема виникає тоді, коли немає жорсткого зовнішнього ліміту, який спрацює незалежно від того, що вирішив сам агент.
Що з цим робити прямо зараз?
Головний практичний висновок — моніторинг і ліміти повинні бути двома різними механізмами, а не одним. Дашборд контролю витрат — це діагностика, а не запобіжник. Запобіжник — це жорсткий hard cap на рівні API-ключа, окремого агента чи сесії, який фізично обриває виконання, коли бюджет вичерпано, без права агента себе «умовити» продовжити.
Практичний чекліст для команд, що вже запустили агентів у продакшен:
- ліміт на кількість ітерацій циклу на одну задачу, а не лише на добовий бюджет;
- окрема бюджетна стеля для кожного підагента в оркестрації, а не спільний пул на весь запуск;
- алерти в реальному часі при перевищенні швидкості витрат (spend rate), а не лише денний звіт;
- ручне підтвердження для дій, що можуть спричинити каскад дорогих викликів — наприклад, породження нових підагентів.
Висновок AiiN
Наша теза проста: якщо навіть компанія, чий бізнес — продавати контроль над AI-витратами, не змогла застосувати власний рецепт до власного агента, це означає, що проблема не в конкретному вендорі чи інструменті, а в самій природі агентних систем. Моніторинг витрат постфактум — це звичка з епохи одиничних API-викликів, яка не встигає за агентом, що приймає рішення десятки разів на хвилину. Компаніям варто перестати запитувати «який у нас дашборд витрат» і почати запитувати «що фізично зупинить агента, якщо він вийде за межі бюджету просто зараз» — і якщо відповіді на це немає, ліміт існує лише на папері.
Чи означає цей випадок, що AI-агентам не можна довіряти бюджет?
Ні, це означає, що бюджет не можна довіряти самому агенту без зовнішнього запобіжника. Агент може ефективно працювати в межах ліміту, якщо цей ліміт технічно неможливо обійти зсередини самої агентної логіки.
Чим hard cap відрізняється від звичайного бюджетного алерта?
Алерт лише повідомляє людину про перевищення, і між сповіщенням та реакцією минає час, за який агент встигає витратити ще більше. Hard cap обриває виконання автоматично, на рівні інфраструктури — без участі людини й без можливості агента його оминути.