# AI supervisor / router агент — коли (а коли ні)

> Мета-агент, що маршрутизує роботу до інших агентів. Stanford 71% vs 30% — суть. Попередження власнику: це не перший запуск — більшості SMB router не потрібен, поки немає 3+ спеціалізованих агентів.

- Автор: Ярослав Максимович (Founder & CEO, AI Advisory Board)
- Опубліковано: 2026-05-09
- Оновлено: 2026-10-23
- Джерело: https://aiadvisoryboard.me/uk/blog/ai-supervisor-router-agent

Поспостерігавши за 30+ засновниками, які пробували запустити "supervisor agent" як перший AI-rollout, мій висновок прямий: це третій агент, який ви будуєте, не перший. Команди, що ігнорують це правило, втрачають 60-90 днів, маршрутизуючи нічого нікому.

## TL;DR

- Supervisor/router агент — це мета-агент, що вирішує, який спеціалізований агент (або людина) обробить запит. Stanford-дослідження 51 deployment: escalation-routing дає ~71% gain продуктивності проти ~30% для naive approval-routing.
- Більшості SMB не потрібен поки не запущено мінімум 3 спеціалізованих агенти. Будувати раніше — створювати складність без цінності.
- Коли потрібен — патерн: classify intent → перевір confidence → маршрут до спеціаліста або ескалація → лог кожного рішення для retraining.

## Що це за агент

Supervisor (router, orchestrator, мета-агент) — LLM-аналог телефонної комутаторки. Отримує запит, вирішує, що це за робота, диспетчеризує.

Конкретно — відповідає на чотири питання на кожному inbound:

1. Про що цей запит насправді? (intent classification)
2. Який агент (чи людська команда) має обробити?
3. Наскільки я впевнений — і чи цього досить для авторуту, чи спитати людину?
4. Який контекст потрібен downstream-агенту/людині, щоб діяти?

> **Визначення:** Router (supervisor) агент — LLM-шар прийняття рішень, що маршрутизує inbound-роботу до спеціалізованих downstream-агентів або людей на основі intent classification і confidence scoring.

Production-приклади: customer-support router передає billing-питання білінговому агенту, refund — рефанд-агенту, "мій акаунт зламано" — одразу людині. Внутрішній ops-router маршрутизує "де мій expense report?" у policy Q&A бот, "потрібен онбординг" — у HR provisioning, "схоже на security incident" — до on-call людини.

## Stanford-висновок, який ніхто не цитує правильно

Дослідження Stanford 51 deployment (2024-2025) — найцитованіше в дизайні router-агентів і найбільш викривлене. Заголовок: escalation-routing дає ~71% gain продуктивності проти ~30% для naive approval-routing.

Реальний висновок корисніший за заголовок:

- **Escalation-routing** = агент робить роботу автономно і ескалує лише _винятки_. Люди ревʼюють те, що AI прапорнув як невпевнене.
- **Approval-routing** = кожна дія агента чекає схвалення людини до виконання. Люди — у критичному шляху кожного рішення.

71% vs 30% — не про роутери як такі, а про те, де ставити людину в петлю. Роутери, що ескалують винятки, сильно перевершують роутери, що питають дозвіл на кожну дію. Більшість first-build SMB-роутерів за замовчуванням approval (бо здається безпечніше) — і тихо втрачають цінність місяцями.

> **Визначення:** Escalation-routing — дизайн workflow, де AI виконує за замовчуванням і маршрутизує лише невпевнені кейси людині. Протилежність approval-routing.

## Owner-warning: це не перший запуск

Правило, зароблене жорстко: не будуйте supervisor агента, поки не маєте мінімум 3 спеціалізованих агенти в проді.

Чому? Роутер не має куди маршрутизувати, поки немає спеціалістів. "Роутер" з одним спеціалістом за ним — це лише латентність + складність single-agent системи: ви побудували швейцара для одно-кімнатної будівлі.

Правильна послідовність для SMB:

1. **Перший**: один high-value спеціаліст (зазвичай policy Q&A бот або support-triage).
2. **Другий**: другий спеціаліст на іншу задачу (lead qualification, invoice 3-way match).
3. **Третій**: третій спеціаліст, де користувачі починають питати "стоп, який з них обробляє X?".
4. **ТОДІ** supervisor — коли питання маршрутизації реальне, не теоретичне.

Засновники, які пропускають це й починають з "побудуємо master-агента, що тримає все" — повторюють патерн Builder.ai $1.3B collapse у мініатюрі: амбіція випереджає субстрат.

## Як виглядає хороший supervisor-дизайн

Чотири принципи, що відрізняють добрий роутер від поганого:

### Принцип 1: Intent classification з каліброваним confidence

Роутер має не просто вгадувати intent — він має знати, наскільки впевнений. 90%-confident "billing question" → авторут. 55%-confident класифікація → уточнювальне питання юзеру або ескалація.

### Принцип 2: Escalation, не approval, за замовчуванням

За Stanford — роутер виконує за замовчуванням і ескалує винятки. Тригери винятків: low confidence, чутливий intent (security, legal, harassment), повторний фейл downstream-агента, новий intent.

### Принцип 3: Повне логування рішень

Кожне рішення — intent, confidence, обраний агент, результат — логується. Це training data для покращень наступного кварталу. Без логів — ви летите наосліп.

### Принцип 4: Чітка поведінка "не знаю"

Має бути graceful шлях "це не співпадає ні з чим, у чому я впевнений — кличу людину". Наївні роутери дефолтять до worst-fit спеціаліста; добрі — у людину, і вчаться з кейсу.

```
ROUTER DECISION TEMPLATE (скелет system prompt):

Класифікуй inbound в ОДНУ з:
  - billing_question
  - refund_request
  - technical_issue
  - account_security_incident   [ЗАВЖДИ ескалація до людини]
  - policy_question
  - unknown

Output:
  intent: <category>
  confidence: <0-1>
  reasoning: <одне речення>
  routing_decision: <agent_name | human_team | clarify_with_user>
  context_to_pass: <structured fields>

Якщо confidence < 0.75 АБО intent у [account_security_incident, unknown]:
  routing_decision = human_team
```

## Manager scan (2-minute digest example)

Як виглядає router-дашборд, прочитаний через Plan → Fact → Gap у понеділок 9:00:

- **Plan** на тиждень: 80% inbound — авторут, 20% — ескалація, misroute <2%.
- **Fact** за 7 днів: 73% авторут, 27% ескалація, 4.1% misroute.
- **Gap**: misroute вдвічі вище таргету. Drill-in: 70% misroute — billing_question як technical_issue.
- Дія: retrain межу billing-vs-technical; додати 50 прикладів.
- **Plan**: support обробляє 40 ескалацій/день.
- **Fact**: support обробив 67/день (бо роутер ескалював borderline-кейси надто охоче).
- **Gap**: confidence threshold надто консервативний; підняти 0.75 → 0.80.
- Дві gap разом — under-routing І misrouting — вказують на одне виправлення: кращі intent-межі.

> **Tool tip (AIAdvisoryBoard.me):** Більшість SMB-власників ведуть router-операцію по інтуїції, бо ніхто не виробляє щоденний Plan → Fact → Gap. Сенс AI-driven daily-management OS — саме в цьому: кожна крос-функціональна система, включно з routing-шаром, має 2-хвилинний digest о 9:00 автоматично. Як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en

## Micro-case (що змінюється за 7-14 днів)

B2B SaaS на 220 людей мала три production-агенти — support-triage, billing-Q&A, refund-policy — у проді ~6 місяців. Повідомлення клієнтів наївно скидались у support-triage, який далі розбирався, обробити, передати чи ескалувати. Поставили supervisor перед цими трьома. За 7 днів черга ескалацій впала ~40% — більшість раніше-ескальованих були billing або refund, які supervisor тепер маршрутизував напряму. Misroute стартував ~12% у тижні 1 і впав до ~4% до тижня 4 завдяки логам для retraining.

> **Примітка щодо кейсу:** Приклад ілюстративний — типові патерни компаній 30-500 людей, не конкретний клієнт. Числа — округлені діапазони, не гарантії.

> **Tool tip (AIAdvisoryBoard.me):** Роутери — рівно та система, що "виглядає добре в слайдах, дрейфує в дикій природі". Без щоденного Plan → Fact → Gap на misroute rate, довжину черги ескалацій і satisfaction downstream-агента — роутер тихо деградує, і два квартали ніхто не бачить. 7-денна діагностика виносить gap до того, як це стане ticket-fire: https://aiadvisoryboard.me/?lang=en

## FAQ

**Скільки спеціалізованих агентів потрібно перед роутером?**
Мінімум три. Двох можна закрити простим rules-based switch (або UI-кнопкою). На трьох+ intent classification починає окуповуватися.

**Чим router відрізняється від "multi-agent system"?**
Router вирішує, хто обробляє запит; multi-agent system — агенти можуть кликати один одного й координуватися. Router — компонент multi-agent. Більшості SMB треба router; повна multi-agent координація — рідко.

**Чи можна малу модель для роутера?**
Так — і зазвичай треба. Маршрутизація — переважно класифікація; малі дешеві моделі це роблять добре. Premium-модель — для спеціалістів, що роблять реальну роботу.

**Як знати, що роутер деградує?**
Три KPI: misroute rate, escalation rate, downstream satisfaction (чи спеціаліст отримує достатньо контексту?). Тренд щотижня. Якщо drift >20% від baseline — retrain.

**Це те, що будувати першим, якщо хочу "центральний AI компанії"?**
Майже завжди ні. Фантазія центрального AI — рівно те, на чому Builder.ai спалив $1.3B. Побудуйте три корисні спеціалісти, побачте, де реально тертя координації, потім дизайніть роутер під реальний патерн.

## Що зробити цього кварталу

Якщо у вас 0-2 production-агенти — ігноруйте питання supervisor цілковито і запускайте другого спеціаліста. Якщо 3+ і користувачі плутаються, з ким говорити — роутер — ваш наступний build, але дизайн escalation, не approval, і лог кожного рішення з дня 1.

Якщо ви хочете систему, яка автоматично виносить Plan → Fact → Gap — щодня, по компанії, включно з AI-routing шаром — погляньте, як працює 7-денна діагностика: https://aiadvisoryboard.me/?lang=en

---

Цитуючи, посилайтесь на https://aiadvisoryboard.me/uk/blog/ai-supervisor-router-agent. Більше статей: https://aiadvisoryboard.me/uk/blog