3 архітектурні патерни AI-агентів у продакшені
З досвіду Eilo і клієнтських RAG-систем — коли брати single-agent, коли multi-agent, коли — workflow.
Ми будували 12+ AI-агентів у 2025-2026. Ось три архітектури, які реально працюють у прод.
1. Single-agent + tools
Один LLM + набір інструментів (search, DB, API-calls). Найпростіше. Підходить коли:
- Задача повторюваного типу (customer support, code review) - Довжина контексту передбачувана - Латентність не критична (<10 сек)
Стек: Claude Opus + tool_use API. Приклад: наша in-house підтримка.
2. Multi-agent orchestration
Оркестратор + N спеціалізованих агентів. Кожен агент — експерт у своїй ділянці. Підходить коли:
- Задача складна і потребує роздумів різних «експертів» - Юзер очікує глибокий вихід (research paper, план) - Ти готовий заплатити 3-5x токенів
Стек: Claude Sonnet для оркестрації, Opus для складних sub-задач. Приклад: RAG-система для юрфірми (draft → review → risk-check).
3. Workflow з детермінованими steps
Не «агент», а pipeline: LLM викликається у фіксованих точках, детермінований код між ними. Підходить коли:
- Треба гарантована якість - Треба debug-ability і моніторинг - Треба compliance (GDPR, HIPAA)
Стек: TypeScript backend, LLM як «функція» серед інших. Приклад: наша Eilo — календарні пропозиції генеруються LLM, але фіксація у Google Calendar — детермінованим кодом.
Що обираємо ми
По дефолту — workflow. Це наймоніторабельніше і найдешевше на скейлі. Multi-agent — тільки коли клієнт має бюджет $$$$ і задача творчого типу. Single-agent — швидкі MVP.
Головне правило: НЕ пиши multi-agent систему на початку. Стартуй з workflow, вилучай LLM з коду коли треба.