Що таке multi-agent система і коли одного агента вже мало

Для 80% бізнесів одного AI-агента достатньо. Для решти 20% — один агент перетворюється на промпт на 2 000 рядків, що ламається щопʼятниці і який ніхто не може дебагнути. Тоді потрібна multi-agent система. Розкладаю, що це таке насправді, коли ви переходите межу, і який стек брати.

Визначення: що таке multi-agent система

Multi-agent система — це двоє і більше LLM-агентів, що передають один одному роботу для виконання задачі, з якою жоден агент сам не справляється. Конкретно:

• Orchestrator-агент — приймає запит користувача, вирішує, до якого спеціаліста маршрутизувати, тримає загальну ціль у памʼяті.
• Спеціалізовані агенти — вузький скоуп, глибока експертиза. Sales-qualifier тільки кваліфікує лідів. Research тільки шукає й сумаризує. Scheduler — тільки букає календарі.
• Memory layer — зазвичай Postgres або vector DB. Дозволяє агентам передавати state без пояснення контексту на кожному передаванні.
• Tool registry — каталог функцій, які агент може викликати. У спеціалістів — короткі, сфокусовані списки.

Це як організація: менеджер (orchestrator) вирішує, що робиться, а спеціалісти (аналітик, sales, support) роблять сфокусовану роботу.

Коли одного агента достатньо

Чесні сигнали, що НЕ треба будувати multi-agent:

• Один сценарій, одна ціль. «Відповідати на FAQ у Telegram». Один агент, готово.
• Менше 8 інструментів. Один агент жонглює 8 інструментами без плутанини. Понад 15 — точність вибору падає.
• Лінійний потік. Кожен турн робить одну річ, ніякого паралелізму, ніякого очікування зовнішніх подій.
• Один домен. Агент говорить про один продукт, один процес, один тип клієнта.

90% моїх клієнтів спочатку запускають single-agent версію, навіть коли в кінці кінців потрібен multi-agent. Швидше, дешевше, доводить бізнес-кейс.

Коли реально потрібна multi-agent

Пʼять сигналів, що одного агента вже мало:

1. Кількість інструментів перетнула 15-20. Один агент з 30 інструментами обирає не той у ~25% випадків. Розбиття на спеціалістів по 5-8 інструментів повертає це до 5%.
2. Потрібна паралельна робота. «Поки research-агент збирає дані по конкурентах, writer пише вступ». Один агент робить це послідовно — multi-agent водночас.
3. Різним агентам потрібні різні моделі. Reasoning на Claude Opus, швидкий tool use на GPT-5 Mini, чутливі дані на self-hosted Hermes. Один процес оркеструє всі три.
4. Домени надто різні. Sales-агенту треба теплий closer-тон. Compliance-агенту — строгий, консервативний. Змішати в один промпт — жоден не працює.
5. Довготривалі workflows. «Моніторити inbox, драфтити відповідь, отримати approval людини, надіслати». Години або дні. Multi-agent з state persistence — природний фіт.

Реальний приклад: B2B sales pipeline

$23 500 / 10 тижнів для SaaS-клієнта з Варшави. Система:

• Inbound-агент — приймає лід з сайту або email, витягує назву компанії, роль, intent.
• Qualifier-агент — тягне дані по компанії з Clearbit + LinkedIn, скорить fit проти ICP, вирішує SQL чи nurture.
• Content-агент — пише персоналізований follow-up з відсилкою на нещодавні пости проспекта і найсильніший кейс SaaS-у в його галузі.
• Calendar-агент — коли проспект відповідає позитивно, дивиться доступність sales-rep, надсилає 3 слоти.
• Orchestrator — вирішує, який агент запускається наступний, ескалює до людини на edge-cases.

Результат: MQL→SQL conversion 3× вище, +$340 000 виручки за квартал. Як одного агента я б це не зрелізив — лише qualifier-промпт — це 900 токенів ICP-специфічних правил.

Реальний приклад: research-бот

Внутрішній інструмент для консалтингової фірми. Вхід: «дай summary європейського ринку X за останні 6 місяців». Вихід: 4-сторінкове briefing з джерелами.

• Planner-агент — розбиває запит на 8-12 підпитань.
• 4× search-агентів — біжать паралельно, кожен бере 2-3 підпитання, бʼє в web + внутрішню БД + платні research-API.
• Synthesizer-агент — мерджить результати, забирає дублікати, ранжує джерела за надійністю.
• Editor-агент — пише briefing у house-style фірми, вставляє цитування.

Single-agent версія такого існує — 25 хвилин на briefing, пропускає 30-40% джерел. Multi-agent: 4 хвилини, майже повне покриття. Пʼять агентів, один orchestrator, один Postgres для shared state.

Реальний приклад: operations-дашборд

Multi-agent звітний пайплайн для берлінського fintech-у. Щоранку о 8:00:

• Collector-агент × 4 — тягне з 4 баз паралельно (транзакції, support-тікети, ops-події, finance-ledger).
• Anomaly-агент — шукає аномалії (refund-сплески, латентність, churn-сигнали).
• Narrator-агент — пише 1-сторінкове Slack-summary з виставленими аномаліями.
• Router-агент — вирішує, кому пінгувати яку аномалію (CFO — finance, CTO — латентність, керівник support — тікети).

Результат: −40 годин роботи аналітика на тиждень, аномалії ловляться на 4 дні раніше в середньому. Окупність 2.5 місяці на $36 800 білда.

Стек: як я це реально будую

Шар оркестрації

• LangGraph — мій default у 2026. Явний state-graph, детермінований transitions, replay-able. Добре під production. Python або TS.
• OpenAI Swarm — легший, більш декларативний. Добре для прототипів і OpenAI-only стеків. Менше контролю state-у.
• Custom (FSM + handoffs у сирому коді) — коли треба жорсткий контроль або уникнути залежності від фреймворку. ~30% моїх production-білдів. Більше коду, менше сюрпризів.

Memory layer

• Postgres — структурований state (поточний крок, хто володіє задачею, проміжні результати).
• pgvector або Pinecone — семантична памʼять (минулі розмови, embedded knowledge).
• Redis — ефемерний state між турнами агентів, rate limits, locking.

Model layer

Майже завжди гетерогенний. Orchestrator на Claude Sonnet 4.5, latency-critical спеціалісти на GPT-5 Mini, compliance-спеціаліст на self-hosted Hermes. Див. матрицю вибору моделі →

Observability layer

• Langfuse — трейсить кожен турн кожного агента. Без цього дебажити multi-agent — пекло.
• Helicone — альтернатива, фокус на cost, менш детальні трейси.
• Sentry — application-level помилки навколо агентів.

Реальна ціна

• Білд — $5 000-50 000+ залежно від кількості агентів та інтеграцій. Див. повний прайс →
• Token cost — у 3-7× вищий, ніж single-agent, бо кожне передавання — це додатковий контекст. Плануйте $200-1 500/міс для середніх обʼємів.
• Maintenance — multi-agent важче дебажити. Бюджет на рік — 20-30% від білда.

Підводні камені, що я набив

1. Не дозволяйте агентам спілкуватися напряму між собою.Завжди через orchestrator. Вільний chat між агентами призводить до нескінченних циклів і руйнівних token-білів.
2. У спеціалістів — вузькі списки інструментів. Кожному агенту лише потрібні йому інструменти. Розшарювання інструментів вбиває приріст точності.
3. State має бути явним. Імпліцитне «агенти самі розберуться» ніколи не працює. Опишіть payload кожного handoff-а.
4. Eval кожного агента окремо. Потім eval усієї системи. Два pass rate: per-agent і end-to-end.
5. Починайте з 2 агентів, не 6. У більшості multi-agent систем, що я бачив у дикій природі, на 3-4 агенти більше, ніж треба. Кожен агент додає латентність і нову точку відмови.

Чи будувати multi-agent?

Чесний тест: якщо один агент з промптом на 1 500 токенів не виконує вашу задачу — може, треба multi-agent. Якщо ще не пробували — спочатку single-agent і поміряйте, де він провалюється.

Я зрелізив і те, і те. Я швидко рекомендую простіший варіант. Букайте дзвінок, за 30 хвилин скажу, з якого боку межі ви.

Написати @tribeofdanel →