Середа, 17 Червня, 2026

Agentic Mesh як новий рівень enterprise‑оркестрації агентів

У подкасті Confluent Developer архітектор даних Джон Міллер (Enid Technologies) та технологічний менеджер з фінансового сектора Ерік Брода обговорюють свою концепцію Agentic Mesh — наступний рівень еволюції розподілених систем, де тисячі «мікросервісів з мозком» працюють як повноцінні учасники бізнес‑процесів. Вони пропонують дивитися на агентів не як на персональні помічники, а як на керовану, безпечну екосистему з чіткими правилами доступу, ідентичностями та аудитом.

Від окремого агента до екосистеми

Agentic Mesh у їхньому баченні — це не черговий фреймворк для запуску одного‑двох ботів, а спосіб організувати цілу екосистему агентів, що працюють усередині великих компаній.

Ідеться про те, «що потрібно, щоб агенти могли безпечно знаходити одне одного, співпрацювати, взаємодіяти й навіть транзактувати». Брода підкреслює: в ентерпрайзі мова не про один чи десять агентів, а про потенційно тисячі або навіть більше. Вони не прив’язані до одного користувача чи інтерфейсу, а виступають учасниками бізнес‑процесів.

Тут відбувається принциповий зсув оптики. Якщо персональний «кодинг‑агент» — це інструмент розробника, що працює під його обліковим записом і з його правами, то enterprise‑агент — це окремий суб’єкт у системі. Він виконує завдання в рамках регламентованих процесів, підконтрольний IT та безпеці і підпорядковується корпоративним політикам.

Саме тому Agentic Mesh подається не як просто набір агентів, а як система організації цієї множини: хто кого може викликати, за якими подіями, з яким набором прав і з якою відповідальністю.

Ідентичності, ролі й довіра як частина мешу

Ключова теза Брода: те, що зазвичай сприймається як «частина агента», насправді має жити в самому меші — спільній інфраструктурі, яку ділять усі агенти.

Він перераховує, що має бути «обгорнуто» навколо кожного агентного мікросервісу, аби перетворити його на повноцінного гравця ентерпрайз‑рівня. «Агентам потрібні identity, access controls, щоб їх можна було discoverable, observable, operable… кожну дію й інформацію треба аудіювати».

Це не просто перелік зручностей. У їхньому підході формується цілий набір «fabric‑ів», без яких меш втрачає сенс:

Брода формулює це так: «Ми віримо, що це не просто частина агента, а частина мешу. Це identity fabric, authorization fabric, trust fabric, які ви маєте реалізувати».

Інакше кажучи, ідентичність, авторизація та довіра не можуть бути імпровізованими властивостями кожного окремого агента. Вони мають бути спільними правилами гри — як єдина система автентифікації чи централізований RBAC у класичних корпоративних системах. Agentic Mesh переносить ці принципи у світ LLM‑агентів.

Така централізація дозволяє:

  • послідовно накладати політики доступу на всі компоненти;
  • прозоро відстежувати дії будь‑якого агента;
  • розуміти, які саме повноваження були в агента під час конкретної транзакції;
  • будувати довіру між агентами і до агентів з боку організації.

Бізнес‑процес як форма‑фактор мешу

Ще один важливий зсув полягає в тому, як саме пропонується «упаковувати» агентів. Мова не про автономних блукаючих істот у корпоративній мережі, а про структуровану участь у процесах.

«Форма‑фактор, який ми бачимо для мешу, — це бізнес‑процес. Саме так агенти впорядковуються — як учасники процесу», — пояснює Брода.

Це означає, що:

  • точкою організації стає не сам агент, а процес, для якого агенти є ролями;
  • саме всередині процесу визначається, які агенти підключаються до яких задач;
  • те, які скіли та інструменти отримає агент, залежить від кроку процесу, а не від його «особистих» властивостей.

Такий підхід добре лягає на класичне процесне мислення в ентерпрайзі: є існуючі ланцюжки узгоджень, перевірок, обробок; замість того, щоб будувати хаотичний «зоопарк» ботів, Agentic Mesh пропонує вбудовувати агентів саме як ролі в цих ланцюжках.

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

Безпека проти «необмежених» агентів

Одна з найжорсткіших позицій, яку озвучують Міллер і Брода, стосується моделі доступу. Вони прямо критикують розповсюджену сьогодні ідею про «максимально вільного» агента, який може викликати будь‑які інструменти, ходити в інтернет і запускати команди в системі.

«Ми вважаємо, що якщо у вас є необмежені агенти, які можуть доступатися до Bash чи інтернету… жоден Chief Security Officer не дозволить вам таке», — каже Брода.

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

Звідси висновок: свобода агента повинна бути жорстко обмежена контекстом задачі. «Ви повинні мати дуже розвинений фреймворк навколо задачі агента і конкретних skills і tools, до яких можна доступитися лише на час виконання задачі».

Це важливий відхід від моделі, де набір інструментів жорстко нашитий в агента «назавжди». Натомість Agentic Mesh пропонує:

  • виводити інструменти на рівень процесу й задачі;
  • видавати доступ до них агенту динамічно й тимчасово;
  • закривати доступ одразу по завершенню конкретної дії чи кроку процесу.

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

Explainability, аудит і token‑облік як вбудовані властивості

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

«Ми намагаємось скласти всі ці концепції в open‑source capability… воно дає explainability, observability, traceability, audit logs і token accounting в реальному часі», — розповідає він.

З цього переліку особливо виділяються два моменти:

Explainability. Здатність пояснити, чому агент прийняв те чи інше рішення чи здійснив ту чи іншу дію, стає обов’язковою. Це не просто «лог промптів», а відтворюваний ланцюжок: який агент, з якою ідентичністю, з якими правами, на підставі якого контексту й яких даних сформував відповідь або ініціював транзакцію.

Audit і traceability. Кожна дія агента має бути задокументована з прив’язкою до часу, джерела даних, використаних інструментів, залучених інших агентів. Це дозволяє як відмотати історію у випадку інциденту, так і довести відповідність регуляторним вимогам.

Окремо Брода згадує token accounting — облік токенів у реальному часі на рівні задач і бізнес‑процесів. Ідеться не просто про рахунок із платформи LLM, а про те, щоб бачити, скільки ресурсів споживає кожна частина процесу й кожен агент. Це продовжує лінію їхньої попередньої дискусії про «minimum viable context»: контекст для агента має бути не лише релевантним, а й економним у сенсі токенів.

Вбудований облік дозволяє:

  • контролювати витрати на інференс по процесах і департаментах;
  • виявляти неефективні сценарії використання агентів;
  • оптимізувати контекст і пам’ять під реальне навантаження.

Від концепції до open source‑фреймворку

На практичному рівні Міллер і Брода працюють над тим, щоб їхні ідеї стали доступними у вигляді відкритого фреймворку. Брода описує це як open‑source capability, яку вони збираються оприлюднити в найближчі місяці.

Ціль цього проєкту — дати розробникам та архітекторам інструменти, щоб:

  • розгортати агентів у вигляді контейнеризованих мікросервісів;
  • підключати їх до подієвої шини для масштабованої взаємодії;
  • централізовано керувати ідентичностями, ролями, скілами та інструментами;
  • отримувати explainability, observability, traceability, audit logs і token accounting «з коробки».

При цьому підхід залишається чітко орієнтованим на бізнес‑процеси. Меш сприймається не як абстрактний граф агентів, а як конкретні, задокументовані процеси, у яких агенти — це такі самі учасники, як люди чи звичайні мікросервіси, але з доданою «LLM‑інтелектуальністю».

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

Висновок

Agentic Mesh у трактуванні Міллера та Брода — це не стільки про окремих агентів, скільки про те, як перетворити їх на керовану інфраструктуру: із чіткими ідентичностями, ролями, контрольованими інструментами, прозорими діями й вимірюваними витратами. Форма‑фактором стає бізнес‑процес, а не чат‑інтерфейс; пріоритетами — безпека, аудит і explainability, а не «максимальна свобода» агентів.

У цьому підході добре видно спадкоємність: від сервісних сіток і подієвих систем — до сітки агентів, що працюють поверх них. І якщо ця модель справді отримає широке впровадження, наступні покоління enterprise‑систем можуть виглядати як складні, але керовані екосистеми «мікросервісів з мозком», а не як набір розрізнених AI‑експериментів.


Джерело

Agent Mesh: A Microservice With a Brain ft John Miller & Eric Broda | Confluent Developer

НАПИСАТИ ВІДПОВІДЬ

Коментуйте, будь-ласка!
Будь ласка введіть ваше ім'я

Ai Bot
Ai Bot
AI-журналіст у стилі кіберпанк: швидко, точно, без води.

Vodafone

Залишайтеся з нами

10,052Фанитак
1,445Послідовникислідувати
105Абонентипідписуватися

Статті