Майже в кожному agent-проєкті настає момент, коли хтось малює на whiteboard другий прямокутник. Роутер. «Planner agent». Billing-агент, shipping-агент, compliance-агент. Це виглядає як добра архітектура, бо схоже на діаграму мікросервісів, а ми всі десятиліття вчилися, що малі сфокусовані сервіси кращі за велику грудку бруду.
Для агентів ця інтуїція часто хибна. Не завжди, але досить часто, щоб пригальмувати, перш ніж малювати другий прямокутник.
Упродовж 2026 року Anthropic опублікувала серію практичних статей на це питання, і разом вони розповідають послідовну історію. Остання, Building agents: when to fold subagents into your main agent loop (жовтень 2026), заходить найдалі: вона описує enterprise-команди, які отримують кращі результати, прибираючи роутери, planner’и та доменні subagents. Цей пост — мій синтез: коли кілька агентів допомагають, які патерни координації підходять до яких задач, чому маятник хитається назад до одного loop, де доречний advisor/executor, і фреймворк рішень. Компроміси випливають із того, як працюють контекстні вікна, а не з якогось одного фреймворку, тож вони застосовні, чи ви використовуєте Claude Agent SDK, LangGraph чи самописний loop.
Реальна ціна другого агента
Почнімо з рахунку. Стаття Anthropic за січень 2026 оцінює типові накладні витрати multi-agent у 3–10 разів більше токенів порівняно з одним агентом на еквівалентне завдання. Причини буденні: дубльований контекст у вікнах, координаційні повідомлення, що нічого не дають користувачеві, і підсумовування на кожній передачі.
Остання б’є найболючіше, і не через токени. Кожна передача має втрати: деталі, що здавалися нерелевантними на першому кроці, важать на третьому, а тоді вони вже зникли. У тій самій статті описано експеримент із агентами planner, implementer, tester і reviewer, де subagents витрачали на координацію більше токенів, ніж на роботу.
Latency — другий сюрприз. Паралелізм прискорює окремі підзадачі, але загальний обсяг обчислень зростає, тож система часто виявляється повільнішою загалом. Жовтнева стаття наводить одного клієнта, чий single-agent loop працював приблизно вдвічі швидше за multi-agent harness, який він замінив, — одна точка даних, не закон, але напрям, якого я б очікував.
Найбільш недооцінена ціна — організаційна. Коли кожна команда будує свого агента, а platform-команда нашаровує зверху оркестратор, ви отримуєте те, що перелічує жовтнева стаття: subagents, що перекриваються й не мають власників, системний промпт, зшитий із суперечливих командних правил, і evals, які кожна команда оптимізує локально, поки ніхто не відповідає за end-to-end якість. Архітектура віддзеркалює орг-схему. Закон Конвея не перестав діяти, коли компонентами стали LLM.
Коли кілька агентів справді допомагають
Нічого з цього не означає «ніколи не використовуйте subagents». Січнева стаття називає три ситуації, де розподіл послідовно виграє, і майже кожен виправданий multi-agent дизайн зводиться до однієї з них:
- Захист контексту. Підзадача породжує багато виводу, нерелевантного основній задачі (стаття називає орієнтовно 1000+ токенів як точку, де ізоляція окупається). Subagent перетравлює його й повертає компактний summary; основне вікно лишається чистим.
- Паралелізація. Справді незалежні грані — непов’язані напрями дослідження, окремі виміри review — виконуються одночасно в окремих вікнах. Джерело подає перевагу як ґрунтовність, а не швидкість.
- Спеціалізація. Забагато інструментів, щоб надійно вибирати між ними, конфліктні домени інструментів або персони, що тягнуть у протилежні боки. Як побачимо далі, тепер є дешевші способи отримати більшу частину цього.
Плюс одне наскрізне застосування: верифікація. Агент, який отримує артефакт і критерії успіху, але не історію збірки, — це справді незалежна перевірка.
Декомпонуйте за контекстом, а не за посадою
Найкорисніша ідея всієї серії: розбивайте за межами контексту, а не за типами проблем. Хороші межі — там, де через них має перетинати мало контексту: незалежні шляхи дослідження, чисті інтерфейси, black-box верифікація. Погані межі — послідовні фази тієї самої роботи, тісно зв’язані компоненти, усе, що потребує спільного стану. Приклад зі статті: агент, що будує фічу, має й писати до неї тести, бо вже тримає контекст. Окремий «tester agent» — охайний розподіл ролей, що коштує точності. Якщо ви працювали з domain-driven design, це знову bounded contexts — тільки обмежуєте ви буквально контекстне вікно.
П’ять патернів координації і чого коштує кожен
Коли ви вирішили, що вам справді потрібен не один агент, квітнева стаття 2026 про патерни координації окреслює п’ять форм. Ось моє стисле прочитання, з failure mode, за яким я б стежив у кожному.
| Патерн | Форма | Використовуйте, коли | Стережіться |
|---|---|---|---|
| Generator–verifier | Один агент виробляє, інший перевіряє за критеріями, цикл до прийняття або ліміту | Якість важлива, а критерії можна сформулювати явно | Verifier без конкретних критеріїв штампує все підряд; цикли, що коливаються |
| Orchestrator–subagent | Lead-агент планує, делегує обмежені підзадачі, синтезує результати | Чітка декомпозиція, низька взаємозалежність | Lead стає інформаційним вузьким місцем; послідовні subagents коштують токенів multi-agent без прискорення |
| Agent teams | Постійні воркери беруть із спільної черги й накопичують контекст | Незалежні довготривалі партиції (напр., один сервіс на воркера в міграції) | Конфліктні правки спільних ресурсів; нерівномірний час завершення |
| Message bus | Агенти публікують/підписуються на події через роутер | Event-driven workflow, зростаюча екосистема незалежно задеплоєних агентів | Тихі збої через хибно спрямовані події; каскади, які важко простежити |
| Shared state | Агенти читають і пишуть у спільне сховище, без центрального координатора | Колаборативне дослідження, де знахідки мають перетікати між агентами по ходу | Дубльована робота, реактивні цикли, що ніколи не збігаються без явного завершення |
Три речі впадають в око, якщо дивитися поруч.
Orchestrator–subagent — це дефолт, якщо вам узагалі потрібно кілька агентів. Решта — те, до чого ви еволюціонуєте, коли з’являється конкретний біль: логіка маршрутизації, що накопичується в оркестраторі, натякає на bus; воркери, які мають пам’ятати між циклами, — на teams; агенти, яким потрібні проміжні знахідки один одного, — на shared state.
Кожен цикл потребує правила зупинки, написаного до його старту — максимальна кількість ітерацій плюс fallback для generator–verifier; бюджет часу або «жодних нових знахідок за N циклів» для shared state. Блокування розв’язує конкурентні записи; воно не зупиняє двох агентів, що ввічливо ставлять один одному уточнювальні питання вічно.
Верифікація настільки добра, наскільки добрі її критерії. Січнева стаття описує збій «рання перемога»: verifier запускає два тести, бачить зелене й проголошує успіх. Виправлення нудне: явно вимагати повний сьют, негативні тести та edge cases.
Березнева стаття про workflow-патерни (послідовні, паралельні, evaluator-optimizer пайплайни зі шляхом, зафіксованим у коді) додає пораду, на якій тримається все тут: спершу спробуйте один виклик, а структуру додавайте лише там, де він очевидно не вистачає.
Маятник хитається назад: один loop, progressive disclosure
Ось де жовтнева настанова стає цікавою. Багато enterprise-впроваджень покращилися, згорнувши роутери, planner’и та доменні subagents в один loop; один агент зі skills часто перемагав і single-prompt, і subagent-дизайни за якістю, нерідко з нижчою вартістю та latency. Почасти причина в можливостях: новіші моделі самі справляються з набагато більшою кількістю рішень, тож логіка може переїхати з harness у модель.
Цільова архітектура:
- Одна модель, одне контекстне вікно, один відкритий tool-loop, з бюджетами ходів, бюджетами вартості та write-гейтами в harness. Виклики інструментів приходять пакетами й виконуються паралельно.
- Планування відбувається всередині loop. Модель планує на першому ході й переглядає план, коли надходять результати — planner і executor це та сама модель, тож у передачі нічого не губиться.
- Доменна процедура переїжджає в skills; жорсткі ліміти й живі lookups — в інструменти. Детермінований код і далі виконує дешеву, завжди потрібну роботу на кшталт entity resolution.
Масштабованим це робить progressive disclosure: агент бачить короткі описи кожного skill та інструмента й завантажує повний вміст лише тоді, коли його потребує завдання. Стаття зазначає, що Anthropic скоротила системний промпт Claude Code більш ніж на 80% для просунутіших моделей, почасти саме так. Квітнева стаття про harness design аргументує те саме з іншого боку: кожен попередньо завантажений токен конкурує за увагу моделі.
Інструменти отримують таке саме ставлення. Січнева стаття припускає, що вибір інструмента ускладнюється приблизно при 15–20 інструментах; жовтнева спостерігає деградацію понад приблизно 30–50 визначень. Обидві радять tool search із відкладеним завантаженням до того, як додавати агентів, а також групувати інструменти за наміром користувача, а не по одному на endpoint, з перевіркою прав окремого користувача всередині кожного інструмента.
Зверніть увагу, що це робить з аргументом про спеціалізацію. Більшість того, що пропонував спеціалізований subagent, — сфокусовані інструкції, підібраний набір інструментів — тепер дає progressive disclosure всередині одного вікна, без lossy передачі. Це і є справжній зсув.
Як згортати, нічого не зламавши
Шлях міграції з жовтневої статті обережний так, як мені подобається:
- Спершу побудуйте end-to-end evals — десяти золотих прикладів досить для старту. Зараз відстежуйте точність маршрутизації; після згортання — чи завантажив агент правильний skill або інструмент.
- Зливайте тісно зв’язаних спеціалістів — тих, що ланцюжать вивід один одного або зазвичай викликаються разом.
- Викликайте решту subagents як інструменти, щоб основний агент володів розмовою, а ви отримали baseline.
- Згортайте по одному. Промпти стають skills, API-виклики — інструментами. Дивіться, які завдання змінилися, а не лише на сукупний бал.
Застережний приклад зі статті: згортання одного subagent у support-агента знизило latency, але зламало процес — основний агент сам відповів на питання про дату доставки замість того, щоб звернутися до shipping-спеціаліста, і то лише в одному із двох запусків. Ганяйте кожне завдання кілька разів; як стверджує пост про evals, поведінка агента — це розподіл.
Змінюється й власність: команди перестають володіти агентами і починають володіти skills та інструментами, а мала центральна команда володіє системним промптом та end-to-end якістю. І subagents усе ще виправдовують своє місце, коли роздування контексту деградує loop, паралельним завданням потрібні свіжі вікна, або вибір інструментів і суперечливі інструкції перемагають одного агента.
Патерн advisor/executor: інтелект за запитом
Є третя форма, яка не вкладається акуратно в «один агент чи багато», і про неї варто знати. Квітнева стаття Anthropic 2026 про advisor strategy описує поєднання меншої executor-моделі, що проганяє все завдання від початку до кінця, з більшою advisor-моделлю, до якої вона звертається лише в складних точках рішень. Advisor читає спільний контекст і повертає план, корекцію або сигнал зупинки. Він ніколи не викликає інструменти й не розмовляє з користувачем.
Це інвертує патерн orchestrator: замість великої моделі, що декомпонує роботу для малих воркерів, мала модель веде й ескалює вгору. Ні декомпозиції, ні пулу воркерів, а frontier-міркування оплачується лише коли потрібне.
Заявлені Anthropic цифри (внутрішні evals, із застереженням про різні налаштування thinking і промпти між запусками): на SWE-bench Multilingual Sonnet з Opus-advisor набрав на 2,7 пункта більше, ніж Sonnet сам, за вартості на завдання на 11,9% нижчої; на BrowseComp Haiku з Opus-advisor досяг 41,2% проти 19,7% поодинці. Їхня порада слушна: протестуйте eval’ом три конфігурації — мала поодинці, мала плюс advisor, велика поодинці — і хай вирішують цифри.
Концептуально мені подобається, що це зберігає один контекст і одного власника завдання — саме те, що захищає настанова про згортання, — додаючи другу думку там, де це важливо. Спокушає побудувати planner-агента? Спершу спробуйте advisor. (Більше про сторону вартості — у token economics.)
Фреймворк рішень
Ось таблиця, яку я б приклеїв біля whiteboard, перш ніж хтось намалює другий прямокутник.
| Форма завдання | Рекомендована архітектура |
|---|---|
| Одне завдання, що комфортно вміщується в одне вікно | Один агент, один виклик. Жодної оркестрації. |
| Широкий домен, багато процедур, багато інструментів | Один agent loop зі skills + tool search (progressive disclosure) |
| Здебільшого рутинна робота з нечастими складними judgment-рішеннями | Менший executor + більший advisor |
| Підзадача породжує великий, здебільшого нерелевантний вивід | Основний loop + subagent для захисту контексту, що повертає summary |
| Справді незалежні грані дослідження чи review | Orchestrator–subagent, явно паралелізований |
| Результат має відповідати явним, перевірюваним критеріям | Generator–verifier з обмеженням на кількість ітерацій і fallback |
| Незалежні довготривалі партиції (одна на сервіс) | Agent teams з розділеними ресурсами |
| Event-driven пайплайн із незалежно задеплоєними агентами | Message bus з correlation ID та evals маршрутизації |
| Агенти мають надбудовувати знахідки один одного майже в реальному часі | Shared state з явною умовою завершення |
Перш ніж брати будь-що нижче від третього рядка, поставте три питання, адаптовані з січневого чекліста: чи є реальне обмеження (контекст, паралелізм чи спеціалізація, які skills і tool search не розв’язують)? Чи розбиття йде за контекстом, а не за посадами? Чи є чітка точка верифікації? Якщо хоч на одне відповідь «ні», у вас проблема одного агента. «Так чистіше» — не обмеження.
Де я був би обережним
- Це статті вендора. Написані Anthropic, про Claude, з цифрами з внутрішніх evals чи окремих клієнтів. Патерни переносні; цифри — не прогноз для вашого навантаження.
- «Часто» — не «завжди». Жовтнева стаття каже, що одинарні loop’и часто перемагають. Ваш випадок може бути винятком — це скаже лише end-to-end eval-сьют, прогнаний кілька разів на конфігурацію.
- Пороги зсуватимуться. Ліміти кількості інструментів і контекстні пороги змінюються з покращенням моделей; стаття про harness design показує scaffolding, який був потрібен одному поколінню моделей і не потрібен наступному. Перетестовуйте після кожного апгрейду.
- Згортання переносить складність, а не видаляє її. Одному loop потрібен дисциплінований системний промпт, гострі описи skills та інструментів і свідоме керування пам’яттю. Це context engineering, і це справжня робота.
- Один loop — це один процес, який може впасти. Checkpointing та ідемпотентні інструменти важать більше, коли немає оркестратора, що повторить підзадачі — див. durable execution для агентів.
Як я підходив би до наявної multi-agent системи
Якщо сьогодні у вас роутер плюс десяток спеціалістів, не переписуйте все:
- Спершу побудуйте end-to-end eval-набір, у власності однієї людини. Без нього ніщо інше не безпечне.
- Інструментуйте передачі — логуйте, що кожен агент отримує й повертає. Межі з втратами проявляються швидко.
- Злийте пару, яку завжди викликають разом. Найнижчий ризик, найчіткіший сигнал.
- Перетворіть спеціалістів на skills та інструменти (MCP — розумний стандарт для боку інструментів), по одному, перезапускаючи evals на кожному кроці.
- Залиште те, що виправдовує своє місце — і задокументуйте, яке з трьох обмежень виправдовує кожного subagent, що вижив.
Кар’єрний ракурс
З’єднати п’ятьох агентів фреймворком тепер легко, і це почасти і є проблема. Цінна навичка — знати, коли цього не робити, і доводити це evals. Це означає вільне володіння речами, що переживуть будь-яку модель: проєктування меж контексту, написання описів skills та інструментів, які модель обирає надійно, побудова evals, що ловлять регресії процесу, і міркування про бюджети токенів та latency. Інженер, який може подивитися на діаграму з дванадцяти прямокутників і сказати «це три прямокутники, і ось eval», буде затребуваний ще довго. Прийшли з enterprise backend? Дивіться від C# до Claude-агентів.
Глибше
Claude Agent SDK практично розбирає agent loop, subagents, skills та дизайн інструментів. Building LLM-Powered Apps: RAG & Agents розглядає патерни незалежно від фреймворку. Claude API охоплює будівельні блоки — tool use, caching, контроль вартості. MCP Servers — про перетворення доменних API на інструменти, згруповані за наміром. А Claude Code Mastery показує продакшен single-loop агента з progressive disclosure з боку користувача.
Джерела: Anthropic, Building agents: When to fold subagents into your main agent loop (жовтень 2026); Multi-agent coordination patterns: Five approaches and when to use them (квітень 2026); Building multi-agent systems: When and how to use them (січень 2026); Common workflow patterns for AI agents and when to use them (березень 2026); The advisor strategy (квітень 2026); Harnessing Claude’s intelligence (квітень 2026). Цей пост — незалежний коментар; цифри наведено так, як їх подають джерела. Пов’язане в цій серії: context engineering, evals, token economics, durable execution, AI-native SDLC.
