У корпоративному світі AI‑агенти вже не футуристична обіцянка, а повсякденна реальність — і дедалі частіше проблема. Компанії запускають десятки й сотні агентів у різних бізнес‑підрозділах, але втрачають контроль над тим, де вони працюють, які дані бачать і скільки це коштує. На подкасті IBM Mixture of Experts про це говорили Мігай Кріветі, головний архітектор watsonx Orchestrate, Олівія Бужек, Staff AI Engineer, та Акаш Срівастава, директор і техлід з AgentOps в IBM Core AI. На цьому тлі IBM формує власну відповідь: AgentOps як продовження класичного життєвого циклу розробки ПЗ (SDLC), але для ймовірнісних агентних систем.
Цей підхід не намагається знести існуючу інженерію до фундаменту. Навпаки, він пропонує, як інтегрувати агентів у вже знайомі DevOps та MLOps‑процеси, додавши до них новий, статистично обґрунтований шар спостереження, оцінювання та оптимізації. У центрі — watsonx Orchestrate та агентний контрольний план IBM, що має перетворити «випадкові акти AI» в керовану інфраструктуру.
Від детермінізму до ймовірності: чому SDLC більше не вистачає
Класичний SDLC будувався навколо детермінізму. Код, що пройшов юніт‑тести, інтеграційні тести й CI‑пайплайн, мав поводитися однаково при кожному запуску. Якщо щось ламається, інженер відтворює баг, фіксить його, додає тест — і система знову передбачувана.
З агентами на базі LLM усе інакше. IBM прямо формулює це як перехід до «ймовірнісного програмного забезпечення». Частина системи — це більше не жорстко прописана логіка, а вибірка з моделі. Один і той самий запит може дати трохи різні відповіді, а в складних сценаріях — і суттєво різну поведінку.
Це не означає повний хаос. Ймовірнісне не дорівнює випадковому. Але означає, що звичні практики тестування «запустив один раз — перевірив результат» більше не дають повної картини. Якщо поведінка змінюється від запуску до запуску, інженер має мислити як статистик: дивитися не на одиничний прогін, а на розподіл результатів, частоту помилок, очікувану поведінку в різних умовах.
IBM формулює це як розширення SDLC, а не його заміну. Юніт‑тести, CI/CD, рев’ю коду залишаються необхідними, але «недостатніми». До них додається новий шар: систематичні оцінки агентів, які враховують їхню ймовірнісну природу. Саме тут народжується дисципліна AgentOps.
Три стовпи AgentOps: спостереження, оцінка, оптимізація
У центрі IBM‑івського бачення AgentOps — замкнута петля з трьох стовпів: спостережуваність, оцінювання та оптимізація. Це не абстрактна методологія, а спроба зробити з агентів системи, які можна вимірювати, порівнювати й цілеспрямовано покращувати.
Перший стовп — спостережуваність. Агентні системи мають генерувати «вихлоп» — телеметрію, логи, трасування, проміжні стани, виклики інструментів. У традиційному ПЗ це вже норма, і IBM не винаходить велосипед: компанія спирається на OpenTelemetry як базовий стандарт. Той самий фреймворк, який давно збирає метрики й трасування з мікросервісів, тепер використовується, щоб фіксувати все, що роблять агенти: LLM‑запити, відповіді, виклики інструментів, маршрутизацію даних.
Другий стовп — оцінювання. Зібрана телеметрія не має лежати мертвим вантажем у логах. Вона перетворюється на «evaluation harness» — набори тестів, метрик і сценаріїв, які запускаються не один раз, а багаторазово, щоб виміряти очікувану поведінку агентів. Замість бінарного «пройшов/не пройшов» з’являються показники на кшталт частки успішних виконань, типових помилок, чутливості до змін у вхідних даних. Ці оцінки вбудовуються в CI‑пайплайни, стаючи таким самим обов’язковим етапом, як юніт‑тести для класичного коду.
Третій стовп — оптимізація. У традиційному SDLC після виявлення проблеми хтось заводить баг у трекері, інженер змінює код, додає тест — і цикл повторюється. З агентами IBM пропонує піти далі: використовувати самих агентів та їхні інструменти для автоматизованого «самоналаштування» й виправлення. Дані з оцінок і телеметрії стають паливом для оптимізаційних процедур, які можуть змінювати промпти, конфігурації, маршрутизацію, а в перспективі — й більш складні аспекти поведінки.
У результаті виникає «чеснотава петля»: агенти працюють, їхня поведінка спостерігається, статистично оцінюється, на основі цього вони оптимізуються — і цикл повторюється. Для IBM це й є сутність AgentOps: не разово «запустити агента», а постійно керувати його еволюцією.
OpenTelemetry як нервова система агентних систем
Вибір OpenTelemetry як основи для спостережуваності — важливий сигнал: IBM не намагається замкнути екосистему агентів у власних пропрієтарних форматах. Навпаки, компанія спирається на відкритий стандарт, який уже де‑факто став універсальною мовою телеметрії для хмарних застосунків.
У контексті агентів OpenTelemetry перетворюється на нервову систему, що збирає «вихлоп» з усіх рівнів: від LLM‑запитів і відповідей до викликів інструментів, внутрішніх станів агентів і маршрутів даних. Цей потік даних не просто зберігається для ретроспективного аналізу інцидентів. Він безпосередньо живить оцінювальні й оптимізаційні контури AgentOps.
Такий підхід має кілька наслідків для підприємств. По‑перше, команди, які вже будували спостережуваність на OpenTelemetry, можуть розширити існуючу інфраструктуру на агентів, а не створювати паралельні системи. По‑друге, з’являється можливість порівнювати поведінку різних агентів, фреймворків і моделей у єдиному форматі. По‑третє, телеметрія стає мостом між DevOps, MLOps і новим шаром AgentOps: усі дивляться на одні й ті самі дані, але з різними фокусами.
Водночас IBM підкреслює, що спостережуваність у світі агентів не може бути «прозорою до безкінечності». Те, що зручно для інженера, може бути неприйнятним для служби безпеки чи комплаєнсу, якщо в логах опиняються персональні або медичні дані. Тому телеметрія має бути не лише повною, а й безпечною.
PII та PHI під мікроскопом: спостерігати, не зливаючи дані
Один із найменш помітних, але критично важливих аспектів AgentOps у виконанні IBM — це фільтрація PII (персонально ідентифікованої інформації) та PHI (медичних даних) у контурах спостережуваності. У традиційних системах моніторингу вже давно відомо, що «сирі логи» можуть містити чутливу інформацію. З агентами ризики зростають: вони працюють із природною мовою, документами, внутрішніми базами, і все це може опинитися в телеметрії.
IBM прямо наголошує: спостережуваність не повинна перетворюватися на канал витоку даних до всіх, хто має доступ до моніторингових інструментів. Тому в контурах AgentOps PII/PHI‑фільтрація — не опція, а базова вимога. Дані, що потрапляють у OpenTelemetry‑потік, мають проходити через фільтри, які видаляють або маскують чутливу інформацію до того, як вона стане доступною широкому колу інженерів, аналітиків чи сторонніх сервісів.
Це особливо важливо на тлі регуляторного тиску, зокрема з боку ЄС через AI Act. Якщо агенти працюють із персональними даними громадян, компанія має не лише контролювати їхню поведінку, а й довести, що канали спостереження не створюють нових векторів ризику. AgentOps у трактуванні IBM — це не лише про якість і надійність, а й про відповідність нормам захисту даних.
watsonx Orchestrate, як платформа, тут відіграє роль «конструктора політик». Клієнти можуть приносити власні правила, метрики й фільтри, включно з кастомними PII‑фільтрами, які відповідають їхнім внутрішнім стандартам ризик‑менеджменту та комплаєнсу. Це дозволяє не покладатися на універсальні «чорні скриньки», а вбудовувати AgentOps у вже існуючі політики безпеки.
AgentOps без нових армій інженерів: інструменти, а не окремі відділи
Коли з’являється нова дисципліна з власною назвою, перша інтуїція — що компаніям доведеться створювати окремі команди під неї. IBM пропонує інший сценарій. AgentOps, у їхньому баченні, має доповнювати існуючі DevOps і MLOps‑процеси, а не вимагати окремих «агентних» відділів.
Причина проста: ядро AgentOps — це спеціалізовані інструменти й методи, а не принципово нова організаційна структура. Оцінювання агентів — це не класичне тестування, але воно може бути вбудоване в ті самі CI/CD‑пайплайни. Оптимізація агентів використовує нові підходи, але працює поверх уже знайомих систем розгортання й моніторингу. Спостережуваність базується на OpenTelemetry, який DevOps‑команди й так використовують.
IBM очікує, що на ринку з’явиться ціла хвиля спеціалізованих AgentOps‑інструментів — і це вже відбувається, насамперед у стартап‑середовищі. Але ці інструменти мають «піднімати» існуючих інженерів, а не замінювати їх. Завдання — дати розробникам, SRE й MLOps‑фахівцям засоби, які дозволять їм керувати агентами в рамках знайомих робочих процесів, а не змушувати компанії будувати паралельні організаційні структури.
Це прагматичний підхід: більшість підприємств уже відчувають дефіцит кадрів у DevOps і MLOps. Створення ще однієї «опс‑армії» під AgentOps виглядає нереалістично. Натомість IBM робить ставку на інструментальну інтеграцію: AgentOps як шар над існуючими практиками, а не як окремий світ.
watsonx Orchestrate: власні метрики, власні запобіжники
watsonx Orchestrate — це не лише платформа для запуску агентів, а й середовище, де реалізується філософія AgentOps. Один із ключових принципів — можливість «принести свої» оцінки, метрики, запобіжники й фільтри.
Організації відрізняються не лише доменами, а й толерантністю до ризику, внутрішніми стандартами якості, регуляторними зобов’язаннями. Для одних критичною буде точність відповіді, для інших — час реакції, для третіх — суворе дотримання політик доступу до даних. IBM визнає цю різноманітність і дозволяє клієнтам налаштовувати власні evaluation‑набори, метрики успіху й guardrails.
Це стосується й PII‑фільтрації. Замість універсальної схеми «один розмір для всіх» watsonx Orchestrate дає змогу визначати власні правила виявлення й маскування чутливих даних у спостережуваності. Для медичних організацій це можуть бути одні атрибути, для фінансових — інші, для держсектору — треті. AgentOps у такій конфігурації стає не просто технічною практикою, а інструментом реалізації конкретних політик ризик‑менеджменту.
Фактично IBM перетворює AgentOps на мову, якою бізнес, безпека, комплаєнс і інженерія можуть домовлятися про те, «що вважається прийнятною поведінкою агента» — і формалізувати це в метриках, фільтрах і політиках, які платформа потім технічно забезпечує.
Агентний контрольний план: Kubernetes‑логіка для світу LLM
Щоб ця вся інженерія працювала в масштабі, потрібна архітектурна опора. IBM описує свій агентний контрольний план як концептуального родича Kubernetes‑контрольного плану. Аналогія не випадкова: так само, як Kubernetes свого часу навів лад у хаосі Docker‑контейнерів, новий контрольний план має впорядкувати «випадкові акти AI» у великих організаціях.
Архітектура розділяє контрольну площину й площину даних. У контрольній площині живуть ідентичність агентів, політики, inline‑застосування правил, спостережуваність і життєвий цикл. У площині даних — власне виконання: LLM‑виклики, інструментальні виклики, протоколи на кшталт MCP, структуровані результати. Усе це «обгорнуте» в контури спостереження, оцінювання й оптимізації, які становлять AgentOps‑петлю.
Важливий момент: IBM планує зробити значну частину користувацького інтерфейсу контрольного плану агентною. Тобто агенти допомагатимуть операторам керувати іншими агентами: аналізувати телеметрію, пропонувати оптимізації, виявляти аномалії. Це логічний крок у світі, де обсяг даних і складність систем перевищують можливості людини «вручну» відстежувати все.
Водночас критичні рішення залишаються під контролем явних людських політик. Kill‑switch’і, фільтрація PII/PHI, ліміти витрат, правила доступу до даних — усе це має бути детермінованим, прозорим і підзвітним. Агент може порадити, але не має права самостійно змінювати фундаментальні обмеження. Такий баланс — «агенти допомагають, люди визначають рамки» — виглядає центральним для IBM‑івського бачення безпечних агентних систем.
Чому навіть із MCP агенти потребують контрольного шару
У дискусії навколо агентів дедалі частіше звучить MCP‑протокол як майбутній стандарт для підключення інструментів і сервісів. На перший погляд може здатися, що достатньо такого протоколу — і багато проблем управління агентами зникнуть. IBM дивиться на це стриманіше.
Очікування такі: MCP справді стандартизуватиме важливі аспекти — автентифікацію, передачу даних, форми даних. Це зменшить фрагментацію й спростить інтеграцію. Але на рівні організації ключова проблема залишається: агенти за своєю природою ймовірнісні й недостатньо надійні, щоб їм беззастережно довіряти доступ до критичних даних.
Корпорації роками будували моделі загроз навколо «людських» зловмисників. Тепер до цього додається новий клас суб’єктів — машинні системи, які можуть поводитися непередбачувано не через злий умисел, а через статистичну природу моделей. Незалежно від того, чи вірить хтось у перспективи AGI, факт залишається: сьогоднішні агенти не настільки контрольовані й надійні, щоб їх можна було пустити «у вільне плавання» по найчутливіших даних.
Звідси й наполягання IBM: контрольований, аудиторований доступ до даних і маршрутизація запитів — це не тимчасова перехідна міра, а постійна вимога. MCP може стандартизувати «дроти», але не замінить політики, спостережуваність і AgentOps‑петлі, які визначають, хто, коли й як може використовувати ці дроти.
Хто стежить за наглядачами: агенти, що допомагають керувати агентами
Коли агенти стають частиною контрольного плану, неминуче виникає питання: хто стежить за наглядачами? Якщо одні агенти моніторять інших, чи не створює це новий рівень непрозорості?
IBM відповідає на це двома шарами. Перший — це вже згаданий поділ: агентні інтерфейси можуть допомагати людям працювати з системою, але критичні рішення закріплені в явних політиках і детермінованих механізмах. Другий — це сама AgentOps‑петля: спостережуваність і оцінювання поширюються й на «агентів‑операторів». Вони так само генерують телеметрію, їхню поведінку можна вимірювати, порівнювати й оптимізувати.
У підсумку виходить багаторівнева система, де агенти допомагають масштабувати управління, але не підміняють собою відповідальність. Люди визначають рамки, політики й метрики; агенти збирають сигнали, пропонують дії, автоматизують рутину; AgentOps‑інструменти забезпечують прозорість і можливість втручання на будь‑якому рівні.
Для підприємств, які вже сьогодні мають десятки чи сотні «випадкових» агентів у різних бізнес‑підрозділах, це може стати єдиним реалістичним шляхом до порядку: не забороняти експерименти, а обгорнути їх у контрольний план і AgentOps‑практики, які роблять поведінку агентів вимірюваною, керованою й сумісною з вимогами безпеки та регуляторів.
Висновок: AgentOps як нова грамотність для епохи агентів
IBM формує чітке послання: епоха «агентів‑іграшок» закінчилася. У міру того, як компанії запускають десятки й сотні агентів у продакшн, питання вже не в тому, як швидко зібрати чергового бота, а в тому, як жити з ним далі. AgentOps у трактуванні IBM — це спроба дати відповідь, не руйнуючи напрацьовані за десятиліття практики розробки й експлуатації ПЗ.
Розширений SDLC для ймовірнісних компонентів, тристовпова петля спостережуваності, оцінювання й оптимізації, OpenTelemetry як нервова система, жорстка PII/PHI‑гігієна в спостережуваності, можливість приносити власні метрики й запобіжники, агентний, але політично керований контрольний план — усе це складається в цілісну картину.
У цій картині агенти — не магічні істоти, які «самі про все подбають», а ще один клас програмних систем, що потребують дисципліни, статистичного мислення й чітких рамок. AgentOps стає новою грамотністю для інженерів, які хочуть не просто запускати агентів, а відповідально керувати ними в масштабі підприємства.
Джерело
Agent control planes & OpenAI model solves Erdős — IBM Technology