Supervisor Agent і Agent Registry для корпоративної мультиагентної ШІ-платформи

Написати одного ШІ-агента — найпростіше. Складно побудувати платформу, де багато агентів працюють разом, виконують багатокрокові процеси, змінюються кожен у своєму темпі й при цьому витримують навантаження. У корпоративній мультиагентній платформі це можливо завдяки Supervisor Agent — єдиній точці, через яку робота потрапляє в систему.

Користувачі ніколи не спілкуються з окремими агентами. Запит іде до Supervisor, а той збирає всі можливості, потрібні для задачі.

Від окремих агентів до оркестрації

Візьмімо схему без Supervisor. Сторона, що викликає, напряму бачить кожного агента:

User
 ├── Planning Agent
 ├── Retrieval Agent
 ├── Research Agent
 ├── Analysis Agent
 └── Report Agent

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

Єдина точка входу знімає проблему:

User Request
      │
      ▼
Supervisor Agent
      │
      ▼
Planning Agent
      │
      ▼
Structured Execution Plan

Тут Planning Agent перетворює високорівневий бізнес-запит на структурований план, а Supervisor керує цим процесом. Сам Supervisor не виконує кожен крок. Він у жодному разі не повинен розростися в одного гігантського агента, який робить усе. Його робота — оркестрація, і більше нічого.

Це справжній архітектурний злам. Купа ШІ-скриптів починає перетворюватися на спроєктовану мультиагентну платформу.

Supervisor координує й делегує

Уявіть такий запит:

Проаналізуй квартальні фінансові звіти, порівняй їх із результатами минулого року, виокрем основні ризики й підготуй резюме для керівництва.

Planning Agent може розбити його на менші кроки:

Business Request
       │
       ▼
Planning Agent
       │
       ▼
Execution Plan
       │
       ├── Retrieval Agent
       ├── Research Agent
       ├── Analysis Agent
       ├── Report Agent
       └── Quality Review Agent

Supervisor веде цей процес від початку до кінця. Структурно це виглядає так:

User
 │
 ▼
Supervisor
 │
 ▼
Execution Plan
 │
 ▼
Agent Resolution
 │
 ├── Retrieval Agent
 ├── Research Agent
 ├── Analysis Agent
 ├── Report Agent
 └── Quality Review Agent
 │
 ▼
Final Result

Supervisor відіграє роль control plane. Спеціалізовані агенти — виконавчі можливості, якими він керує.

Спершу архітектура, потім фічі

На цьому етапі напрошується просто додавати агентів. Краще спершу зміцнити фундамент.

Причина проста. Якщо Supervisor сам створює кожного спеціалізованого агента, він поступово намертво зростається з усіма реалізаціями. У псевдокоді це виглядало б так:

Supervisor
 ├── Create PlanningAgent
 ├── Create RetrievalAgent
 ├── Create ResearchAgent
 ├── Create AnalysisAgent
 ├── Create ReportAgent
 └── Create QualityReviewAgent

З п'ятьма агентами це нормально. З 25 стає незручно, а зі 100 — уже справжня проблема:

• Кожна нова можливість потребує правок у Supervisor.
• Заміна реалізації потребує правок у Supervisor.
• Тести дедалі складніше писати й дедалі менше їм віриш.
• Шар оркестрації обростає обов'язками, які ніколи не мали бути його.

Саме такої зв'язаності добрий дизайн і уникає.

Agent Registry

Рішення — Agent Registry. Supervisor більше не створює агентів. Він запитує в реєстру потрібну йому можливість:

Supervisor Agent
                           │
                           ▼
                      Agent Registry
                           │
       ┌───────────────────┼───────────────────┐
       ▼                   ▼                   ▼
 Planning Agent      Retrieval Agent     Research Agent
       │                   │                   │
       ▼                   ▼                   ▼
 Analysis Agent       Report Agent      Quality Review Agent

Тепер Supervisor не мусить знати, як створюється той чи інший агент. Він може просто сказати, що йому потрібно:

"Give me the retrieval-agent."

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

Чому це важливо на практиці

Припустімо, одного агента замінюють на вдалішого:

ResearchAgent

перетворюється на

DeepResearchAgent

Без шару абстракції код оркестрації, найімовірніше, довелося б змінювати. З реєстром ви змінюєте реєстрацію, і більше нічого. Інтерфейс Supervisor лишається точнісінько таким самим.

Supervisor
    │
    ▼
"research-agent"
    │
    ▼
Agent Registry
    │
    ├── Today  → ResearchAgent
    │
    └── Future → DeepResearchAgent

Supervisor і далі запитує ту саму можливість, а те, що стоїть за цим ім'ям, може вільно вдосконалюватися. Правило, якого варто триматися на всій платформі:

Залежте від можливостей і контрактів, а не від конкретних реалізацій.

Фреймворк оркестрації має бути замінним

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

• LangGraph
• OpenAI Agents SDK
• Semantic Kernel
• CrewAI

Грубо кажучи, платформа розташована над цим шаром:

Enterprise AI Platform
                          │
                          ▼
               Orchestration Abstraction
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
    LangGraph      OpenAI Agents SDK   Semantic Kernel
                                             │
                                             ▼
                                           CrewAI

Реалізовувати їх усі заздалегідь не треба. Сенс у тому, щоб провести межі в правильних місцях і щоб фреймворк, обраний сьогодні, не затвердів в обмеження, з яким потім доведеться жити.

Мисліть як інженер платформи

Головна зміна в мисленні — перестати бачити в системі набір агентів. Ставтеся до неї як до середовища виконання ШІ-роботи, до повноцінної платформи. Агенти — це спеціалізовані плагіни поверх великої платформи, а платформа дає спільну механіку, на яку спираються всі:

• оцінювання й спостережуваність
• логування й безпеку
• конфігурацію й пам'ять
• виконання інструментів
• оркестрацію й керування процесами

Це змінює форму системи. Типовий ранній дизайн запихає інфраструктуру в кожного агента:

Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure
Agent + Infrastructure

Цільовий дизайн виносить цю інфраструктуру назовні й робить спільною:

Shared Platform Infrastructure
                           │
      ┌────────────────────┼────────────────────┐
      ▼                    ▼                    ▼
 Configuration         Memory             Observability
      │                    │                    │
      ├────────────── Orchestration ────────────┤
      │                    │                    │
      ▼                    ▼                    ▼
  Security             Evaluation          Tool Layer
                           │
                           ▼
                      Agent Registry
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
       Agent A          Agent B          Agent C

Спільні можливості живуть у платформі. Предметна бізнес-логіка живе в агентах.

Від п'яти агентів до сотні

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

Що відбувається з архітектурою, коли додається агент номер 101?

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

Implement Capability
        ↓
Use Shared Agent Framework
        ↓
Register Agent
        ↓
Expose Through Orchestration
        ↓
Test
        ↓
Deploy

Архітектура має приймати нові можливості без великого редизайну.

Supervisor починає історію, але він не весь мозок

Називати Supervisor мозком платформи зручно як образ, але відповідальність навмисно розподілено між кількома частинами:

• Planning Agent вирішує, яку роботу треба зробити.
• Supervisor координує, як вона виконується.
• Agent Registry визначає, яка можливість її робить.
• Спеціалізовані агенти розв'язують предметні задачі.
• Сервіси платформи дають спільну інфраструктуру.
• Спостережуваність і оцінювання фіксують і оцінюють, що насправді сталося.

Разом ці частини дають платформі і інтелект, і операційну структуру.

User
                          │
                          ▼
                    Supervisor
                          │
                          ▼
                    Planning Agent
                          │
                          ▼
                   Execution Plan
                          │
                          ▼
                    Agent Registry
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
   Retrieval          Research           Analysis
       │                  │                  │
       └──────────────────┼──────────────────┘
                          ▼
                     Reporting
                          │
                          ▼
                   Quality Review
                          │
                          ▼
                     Final Result

             ───── Shared Platform Layer ───── Configuration • Memory • Security • Logging
 Observability • Evaluation • Tools • Workflows

Головний урок

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

Траєкторію легко побачити:

Повторно використовуваний фреймворк → спеціалізовані агенти → Supervisor → Agent Registry → динамічна оркестрація → розподілене виконання

Кожен крок знижує зв'язаність і дає платформі більше простору для зростання. Чи буде в системі 5 агентів, чи 100, мета не змінюється:

Оркестрація відокремлена від реалізації. Спільна інфраструктура відокремлена від предметної бізнес-логіки.

Це і є перехід від створення окремих ШІ-агентів до інженерії мультиагентної платформи. Не просто будуйте більше агентів. Будуйте архітектуру, до якої кожен майбутній агент під'єднується, масштабується й змінюється з мінімумом зусиль.