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

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

Що це за агент

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