IBM продовжує розкривати деталі своєї стратегії навколо керування AI‑агентами в підприємствах. У подкасті Mixture of Experts інженери IBM, зокрема головний архітектор watsonx Orchestrate Міхай Кріветі, обговорюють, як компанія намагається звести докупи розрізнені агентні фреймворки, гібридні інфраструктури та нові відкриті стандарти. У центрі цієї стратегії — платформа watsonx Orchestrate та агентний control plane, які мають зробити з «випадкових актів AI» керовану, інтероперабельну систему.
Від «легко зібрати» до «важко керувати»: чому платформа важливіша за окремих агентів
У команді IBM вже сформулювали внутрішнє правило: створити агента легко, усе складне починається після цього. Сучасні великі організації часто мають десятки або навіть сотні агентів, розгорнутих у різних бізнес‑підрозділах — від експериментальних POC до напівпродуктивних рішень. Ці агенти використовують різні моделі, різні фреймворки, підключені до різних джерел даних і працюють на різних хмарах.
Проблема не в тому, що агенти погано працюють поодинці, а в тому, що вони майже ніяк не керуються як система. Немає єдиного шару ідентичності, політик доступу, спостережуваності, немає розуміння, де саме запущений кожен агент, які дані він бачить і скільки коштує його робота. На це накладається регуляторний тиск — зокрема, вимоги на кшталт Європейського AI Act, які прямо змушують підприємства пояснювати, як саме працюють їхні AI‑системи, хто до чого має доступ і як це контролюється.
У такій ситуації головне завдання зміщується з «як швидко зібрати агента» до «як керувати сотнями агентів, не втрачаючи контроль над безпекою, даними та витратами». Саме тут IBM позиціонує watsonx Orchestrate та агентний control plane як інфраструктурний рівень, що має стати для агентів тим, чим Kubernetes став для контейнерів.
Control plane для агентів: аналог Kubernetes, але для ймовірнісного ПЗ
IBM прямо проводить аналогію: агентний control plane для AI‑агентів — це концептуальний двійник control plane Kubernetes для контейнерів. Як колись Docker породив хаос із контейнерами, розгорнутими «де завгодно», так сьогодні підприємства опинилися в ситуації з «60–200 випадковими актами AI», розкиданими по організації.
Архітектурно IBM розділяє два ключові шари.
Перший — control plane. Тут зосереджені ідентичність агентів, політики доступу та безпеки, інлайнова перевірка політик, спостережуваність, життєвий цикл, а також механізми на кшталт детермінованих «kill‑switches» для зупинки небажаної поведінки. Саме цей шар відповідає за те, щоб агент не виходив за межі дозволеного: не забирався до заборонених джерел даних, не порушував політики щодо PII/PHI, не генерував неконтрольовані витрати.
Другий — data plane. Тут агенти безпосередньо виконують виклики до LLM, звертаються до інструментів, працюють із протоколами на кшталт Model Context Protocol (MCP), формують структуровані відповіді, викликають зовнішні сервіси. Усе, що стосується «роботи» агента, відбувається саме тут, але під постійним наглядом control plane.
IBM послідовно підкреслює: побудувати агента — це вже вирішена задача для багатьох команд. Справжня складність — у керуванні цими агентами на масштабі, коли вони стають частиною критичної бізнес‑інфраструктури. watsonx Orchestrate разом із control plane подається як той самий «шар інтероперабельності», який дозволяє звести в єдину систему різнорідні агентні стеки, не змушуючи компанії відмовлятися від уже зроблених інвестицій.
Гібридність як норма: air‑gapped, on‑prem, multi‑cloud через OpenShift
Одне з ключових рішень IBM — зробити watsonx Orchestrate максимально гнучким щодо місця розгортання. Платформа позиціонується як агентний рушій, який може працювати в кількох режимах, що особливо важливо для великих підприємств із жорсткими вимогами до безпеки та суверенітету даних.
По‑перше, підтримується air‑gapped‑режим. Це означає, що Orchestrate може бути розгорнутий у повністю ізольованому середовищі без виходу в публічний інтернет. Для секторів на кшталт фінансів, оборони, медицини чи критичної інфраструктури це часто є обов’язковою умовою: будь‑які зовнішні виклики мають бути або повністю заборонені, або проходити через суворо контрольовані шлюзи.
По‑друге, платформа може працювати on‑premises — у власних дата‑центрах замовника. Це дозволяє компаніям, які вже інвестували в локальну інфраструктуру, розгортати агентні системи поруч із внутрішніми базами даних і сервісами, не виносячи чутливу інформацію в публічну хмару.
По‑третє, підтримується гібридний режим і multi‑cloud через OpenShift. Завдяки використанню OpenShift як базового шару оркестрації, watsonx Orchestrate може бути розгорнутий поверх різних гіперскейлерів і приватних кластерів, забезпечуючи єдину модель керування агентами незалежно від того, чи працюють вони в AWS, Azure, Google Cloud чи в приватній хмарі. Для багатьох глобальних компаній це критично: різні регіони можуть мати різні вимоги до розміщення даних, а бізнес‑підрозділи — різні хмарні стратегії.
Такий підхід дозволяє не лише задовольнити регуляторні вимоги, а й уникнути «vendor lock‑in» на рівні як інфраструктури, так і моделей. Агенти можуть використовувати різні LLM‑постачальники, але при цьому залишатися під єдиним control plane з однаковими політиками, логуванням і спостережуваністю.
Від LangGraph до власних сервісів: як Orchestrate підтягує зовнішніх агентів
Ще одна принципова ставка IBM — не змушувати клієнтів переписувати вже створених агентів під власний фреймворк. watsonx Orchestrate задуманий як платформа, що вміє працювати з агентами, побудованими в інших екосистемах, і при цьому підпорядковувати їх єдиному control plane.
По‑перше, Orchestrate може імпортувати та запускати агентів, створених у зовнішніх фреймворках, зокрема в популярному LangGraph. Для команд, які вже вклали ресурси в побудову складних графів інструментів, робочих процесів і політик у LangGraph, це означає можливість «підняти» ці агенти в корпоративне середовище IBM без повного рефакторингу. Агент продовжує працювати у звичному для розробників вигляді, але тепер його життєвий цикл, доступ до даних і спостережуваність контролюються через watsonx Orchestrate.
По‑друге, платформа підтримує підключення до зовнішньо розміщених агентів через кілька типів інтерфейсів. Це можуть бути шлюзи (gateway), які виступають проксі‑шаром між внутрішнім середовищем і зовнішнім агентом, Model Context Protocol (MCP) як стандартний спосіб опису інструментів і контексту, а також ендпоінти, сумісні з OpenAI‑API. Останнє особливо важливо, оскільки багато сучасних агентних систем уже орієнтуються на OpenAI‑сумісний протокол як де‑факто стандарт.
Завдяки такій гнучкості watsonx Orchestrate може виступати «диригентом» для гетерогенної екосистеми агентів: частина з них працює всередині самої платформи, частина — у зовнішніх сервісах, частина — у сторонніх фреймворках. Але всі вони підпорядковуються єдиному control plane, де застосовуються політики, збирається телеметрія, контролюються витрати й доступ до даних.
Це особливо актуально для компаній, які вже встигли «розмножити» агентів у різних командах: замість того, щоб усе викидати й будувати заново, вони можуть підключити наявні рішення до Orchestrate і поступово наводити лад.
Відкриті стандарти як стратегія: MCP, OpenAI‑API та OpenTelemetry
IBM окремо виділяє підтримку відкритих стандартів як одну з ключових відмінностей свого control plane. Йдеться не лише про технічну зручність, а й про довгострокову стратегію уникнення закритих, несумісних стеків.
Model Context Protocol (MCP) розглядається як один із центральних елементів майбутньої інтероперабельності. У дискусії навколо проєкту Context Forge, архітектором якого є Міхай Кріветі, постає типове запитання: якщо є MCP, чи не вирішить він «усе» сам по собі? Відповідь обережна, але оптимістична: MCP справді має потенціал стандартизувати низку критичних аспектів — від автентифікації до формату даних.
IBM очікує, що з часом MCP уніфікує:
автентифікацію агентів і інструментів, зменшуючи кількість «самописних» схем доступу;
способи передачі даних між агентами та інструментами;
«форми» даних — тобто структури, в яких інструменти приймають і повертають інформацію.
Однак навіть за такого розвитку подій потреба в окремому control plane не зникає. MCP може зробити інтеграцію простішою, але не вирішує базову проблему: агенти залишаються ймовірнісними системами, яким не можна беззастережно довірити доступ до критичних даних. Потрібен шар, який контролює, хто, коли і до чого звертається, фіксує це в журналах, застосовує політики й забезпечує можливість аудиту.
Паралельно IBM робить ставку на підтримку OpenAI‑сумісних API. Це дозволяє підключати до control plane інструменти й агенти, які вже вміють працювати з цим протоколом, без додаткових «перекладачів». У світі, де багато стартапів і open‑source‑проєктів орієнтуються саме на цей API, така сумісність стає практично обов’язковою.
Для спостережуваності IBM використовує OpenTelemetry — відкритий стандарт збору телеметрії, який уже добре знайомий командам, що займаються традиційним продакшн‑софтвером. Ті самі механізми, які сьогодні збирають метрики, логи й трейси мікросервісів, тепер застосовуються до агентних систем. Це дозволяє не лише бачити, що робить кожен агент, а й будувати поверх цього оцінювальні контури, аналізувати відхилення в поведінці та оптимізувати роботу.
У сукупності підтримка MCP, OpenAI‑сумісних API та OpenTelemetry формує для watsonx Orchestrate роль «відкритого» control plane, який не намагається замкнути екосистему в межах одного вендора, а навпаки — прагне стати точкою зшивання різних стандартів.
Чому контроль залишиться назавжди: ймовірнісні агенти й «хто стежить за наглядачами»
Окрема лінія аргументації IBM стосується фундаментальної природи агентів. На відміну від класичного детермінованого ПЗ, де однаковий вхід завжди дає однаковий вихід, агенти, побудовані на LLM, є ймовірнісними. Вони можуть поводитися по‑різному за однакових умов, і це не тимчасова вада, а властивість самої технології.
Це означає, що навіть якщо протоколи на кшталт MCP стануть дуже зрілими, а моделі — значно «розумнішими», базова вимога до контрольованого, аудиторованого доступу до даних нікуди не зникне. У корпоративних середовищах роками будувалися загрози‑моделі навколо людських «зловмисників» або зламаних сервісів. Тепер до цієї картини додаються ймовірнісні машини, які можуть поводитися непередбачувано не через злий умисел, а через статистичну природу своїх рішень.
IBM підкреслює: незалежно від того, чи вірить хтось у майбутнє загального штучного інтелекту, сьогоднішні агенти вже не є достатньо контрольованими, щоб їм можна було безумовно довірити «найкритичніші біти даних». Тому потрібні механізми, які гарантують, що:
дані подаються агентам у контрольований спосіб;
кожен доступ можна відстежити й пояснити;
можна швидко зупинити або обмежити агента, якщо його поведінка виходить за рамки політик.
Це робить control plane не тимчасовим «костилем» на шляху до повністю автономних систем, а постійним елементом архітектури. Навіть якщо частина взаємодії з control plane стане агентною — наприклад, інтерфейси для операторів, які допомагають формулювати політики чи аналізувати поведінку — критичні рішення залишаться закріпленими в явних, людськи визначених правилах.
На цьому тлі проєкти на кшталт Context Forge, які IBM розглядає як частину ширшої екосистеми агентних інструментів, показують, у якому напрямку рухається індустрія: від окремих «розумних» компонентів до цілісних систем, де інструменти, агенти й control plane взаємодіють через стандартизовані протоколи, але при цьому зберігається чіткий розподіл відповідальності між людьми та машинами.
Висновок: інтероперабельність як умова виживання агентних систем у підприємствах
watsonx Orchestrate у виконанні IBM — це не просто ще одна платформа для запуску AI‑агентів. Це спроба відповісти на одразу кілька викликів: хаотичне розмноження агентів у великих організаціях, жорсткі регуляторні вимоги, фрагментацію фреймворків і протоколів, а також фундаментальну ймовірнісну природу сучасних моделей.
Ключові елементи цієї відповіді — гібридні розгортання від air‑gapped до multi‑cloud через OpenShift, здатність імпортувати агентів із зовнішніх фреймворків на кшталт LangGraph, підключення до зовнішніх агентів через gateway, MCP і OpenAI‑сумісні ендпоінти, а також ставка на відкриті стандарти MCP, OpenAI‑API й OpenTelemetry.
За всім цим стоїть проста, але жорстка теза: створити агента сьогодні може майже кожен, але без єдиного control plane керувати сотнями таких агентів у реальному бізнесі стає практично неможливо. IBM намагається зайняти саме цю нішу — не як монолітний «мегасервіс», а як інтероперабельний шар, який дозволяє підприємствам зберегти контроль, не втрачаючи гнучкості й не відмовляючись від уже зроблених інвестицій у різні агентні стеки.
Джерело
Agent control planes & OpenAI model solves Erdős — IBM Technology