Команди агентів Claude Code: коли використовувати багатоагентну модель та як це зробити

Існує можливість створення організованої команди агентів, які можуть спілкуватися між собою в екосистемі Claude Code, і готова версія може функціонувати добре. Однак змусити їх працювати складніше, ніж здається, і багато хто поспішає створювати команди агентів, не оцінюючи наслідків. Команди агентів здаються очевидним наступним кроком, як тільки підагенти почнуть працювати без проблем. Однак це не відбувається автоматично. Команда — це рівень координації з реальними витратами на токени, відомими способами збою та обмеженим набором проблем, які вона ефективно вирішує.

Найменш привабливий урок, який можна засвоїти після кількох місяців реального використання багатоагентних систем, є водночас найкориснішим: починайте з одного добре налаштованого агента, хороших інструментів та дисциплінованого керування контекстом. Додавайте нові агенти лише тоді, коли маєте конкретну причину. Керівництво Anthropic щодо створення ефективних агентів говорить про те саме, радячи командам шукати найпростіше працездатне рішення та додавати складність лише тоді, коли це необхідно.

Далі наведено спосіб ретельного обмірковування рішення та дії після його прийняття. Цей підхід передбачає, що ви знайомі з підагентами, розрізняєте їх від навичок та розумієте, чому ізоляція контексту є основною причиною використання підагентів. Відкритим залишається питання про те, коли одного підагента, який надсилає звіти, вже буде недостатньо, та що створити замість нього.

У матеріалі розглядаються такі аспекти:

• Чому більшості команд поки що не потрібно кілька агентів, та поширена помилка — обирати більші команди лише через відчуття їхньої більшої потужності.
• Чотири конкретні сигнали, які свідчать про те, що у одного агента закінчилися ресурси.
• Чотири патерни поєднання агентів у таксономії, нейтральній щодо постачальників: оркестратор, конвеєр обробки даних, паралельні спеціалісти та зграя.
• Стек Anthropic для команд агентів, який розділяє стабільні елементи від експериментальних чи доступних лише у прев’ю версіях.
• Що таке команди агентів Claude Code та чим вони відрізняються від субагентів.
• Як агенти взаємодіють: три форми, чотири патерни таймінгу та що передавати між ними.
• Вісім способів збою та практичні заходи їх усунення.
• Шаблон прийняття рішень щодо використання нативної, самостійної чи гібридної оркестрації.

Більшості команд потрібен не більше одного агента

Багато людей, які шукають команди агентів, вирішують неправильну проблему. Зазвичай вважається, що підагенти ефективні, система стає складнішою, тож команди є наступним кроком. Ця логіка плутає можливості з складністю. Команда не робить систему більш здатною; вона робить її більш децентралізованою, а децентралізація є витратою, а не покращенням.

Публікація Anthropic про створення ефективних агентів детально пояснює економіку цього підходу. Робочі процеси, які не є агентними, є більш прогнозованими, дешевшими та легше піддаються дебагуванню, і порада зводиться до наступного: коли звичайна функція може виконати завдання, краще написати саме її, а не збирати комітет із функцій розподілу ймовірностей. Цю ідею легко не помітити тим, хто ще не усвідомив, що ШІ на основі нейромереж є пробаблістичними. Навіть чіткий наказ може бути виконаний правильно, а може — і ні. Кожен доданий агент — це ще один компонент, який може зламатися, створювати халюцинації чи генерувати результати, які наступний агент неправильно інтерпретує, тож додавання агентів посилює ймовірність помилок у масштабі.

Ліміт для одного агента вищий, ніж уявляють багато хто. Один агент, якому надані відповідні інструменти, чіткі вказівки системи, належне делегування складних завдань підагентам та ретельне керування контекстом, може виконати дивовижну кількість роботи. Ліміт досягається, коли спостерігається принаймні одна з чотирьох ситуацій:

1. Завдання занадто велике для одного вікна контексту, навіть при делегуванні підагентам.
2. Різні частини завдання вимагають справді різних спеціалізацій, що означає різний доступ до інструментів та обмеження у поведінці, а не просто різні вказівки.
3. Частина роботи може виконуватися паралельно, і тут має значення час виконання.
4. Якість результату потребує незалежної оцінки, наприклад, від другого агента, який не бачив логіку роботи першого.

Жоден з цих факторів не є описом можливостей. Усі вони стосуються архітектури. Коли застосовується певний механізм, додаткові агенти є доцільними. Коли жоден механізм не застосовується, вони лише створюють перешкоди, і якщо неможливо вказати конкретний варіант, шлях з одним агентом залишається доступним.

Чотири фактори, з прикладами

Ізоляція контексту. Припустимо, що завдання полягає у читанні десятків файлів, проведенні обширних пошуків та зберіганні великих проміжних результатів, жоден з яких не потребує зберігання у основній сесії. Для цього підходить підагент. Але якщо обсяг роботи настільки великий, що навіть контекст підагента заповнюється, або завдання розділяється на незалежні паралельні дослідження, тоді потрібно використовувати кілька агентів. Це найпоширеніший законний фактор для їх застосування.

Спеціалізація. Ця робота вимагає не просто окремих інструкцій; їй потрібен доступ до різних інструментів та інші обмеження у поведінці. Особа, яка переглядає код та не може створювати файли чи виконувати команди шеллу, має абсолютно інший профіль ризиків, ніж генератор коду. Проте ці відмінності часто можна представити у вигляді окремих підагентів, кожен з яких має власний системний запит та обмежений список інструментів, тож сама по собі спеціалізація не повинна бути причиною для переходу до команд. У самій документації про агенти-команди зазначено, що саме підагенти тут проявляють себе найкраще: ізольовані контексти, підсумки, що надсилаються користувачеві, та інструкції, специфічні для завдання.

Паралельна робота. Завдання розділяється на незалежні підзавдання, які не мають спільного змінного стану: три агенти одночасно досліджують різні аспекти помилки в кодовій базі, або чотири агенти кожен переглядає інший розділ документа. Саме в таких ситуаціях багатоагентні системи забезпечують справжню економію часу, оскільки агенти працюють одночасно. Ціною є більша кількість загальних токенів, тому така угода є доцільною лише тоді, коли час, витрачений на виконання завдання, має більше значення, ніж витрати.

Незалежна критика. Результат потребує другої думки, яка не була спотворена логікою першої. Уявіть собі оцінювача, який читає лише кінцевий результат та не бере до уваги обґрунтування, що стоять за ним, або агента з «червоної команди», який шукає недоліки замість того, щоб підтверджувати твердження. Саме ця ідея лежить в основі системи досліджень з багатьма агентами від Anthropic, де паралельні підагенти досліджують різні аспекти, а головний агент самостійно синтезує інформацію.

Коли одне з цих тверджень є явно правдивим, і ви можете визначити, яке саме, додавання агентів виправдовує свою вартість.

Чотири способи поєднання агентів

Припустимо, рішення прийнято. Дослідження швидко виявляють хаос, адже кожна з лабораторій розробила моделі багатьох агентів по-своєму, хоча існують деякі спільні елементи. Нижче наведена синтезована таксономія, створена на основі документації про робочий процес Anthropic та досвіду їхньої інженерної команди. Це не офіційна класифікація Anthropic — це аналітичний огляд, який відповідає тому, що описано в цих джерелах.

Послідовний потік

Агенти або етапи виконуються у фіксованому порядку, причому наступні етапи використовують результати попередніх. З цих чотирьох саме цей варіант найлегше пояснити інженерам, адже він схожий на звичайне програмне забезпечення: спочатку дослідження, потім синтез, потім розробка проєкту, потім критика, а нарешті — вилучення та підтвердження.

Його сила полягає у чітких контрактах між етапами. Його слабкість — ланцюгові помилки, адже помилка під час вилучення даних на першому етапі може призвести до неправильних результатів на наступних етапах з величезними витратами. Блоки перевірки між етапами є обов’язковими, оскільки вони запобігають тому, щоб процес розвивався у неправильному напрямку. Схеми контрактів JSON та інші елементи, які зберігають історію змін протягом виконання, є найкращими засобами контролю.

Центральний оркестратор чи планувальник-виконавець

Основний агент розбиває завдання на частини, делегує їх працівникам та об’єднує отримані результати. Працівники не координують дії між собою; вони звітують організатору. Це найпоширеніша та найкорисніша стандартна конфігурація. Використовуйте її, коли структура підзавдань не відома заздалегідь, але важливо чітке розподілення обов’язків на вищому рівні. Функція Research у Anthropic дотримується саме такої схеми: основний агент аналізує запит, одночасно запускає спеціалізовані підагенти та згодом об’єднує отримані ними дані.

Не використовуйте її, якщо процес роботи вже настільки стабілізований, що можна його скриптувати; у такому випадку конвеєр буде простішим та передбачуванішим.

Його характерною проблемою є порушення роботи оркестратора: керівний агент, чиї вказівки щодо делегування завдань є нечіткими, змушує працівників повторювати один одного у пошуках, переступати межі або отримувати результати, які не узгоджуються між собою. Рішенням є надання кожному працівнику чіткої мети, формату очікуваного результату, вказівок щодо джерел та чітких меж завдання.

Паралельні спеціалісти, дебати та команда критиків

Тут кілька агентів виконують одне й те саме завдання або суміжні підзавдання одночасно, а їхні результати потім голосуються, оцінюються або об’єднуються. Цей підхід підходить у випадках, коли стійкість важливіша за порядок: конкуруючі пояснення проблеми, критичний аналіз рішення щодо політики, перевірка безпеки з кількох точок зору.

Витрати є очевидними. Більше агентів означає значно більшу кількість токенів, більше роботи з агрегацією та ризик хибної впевненості, що виникає через консенсус. За повідомленнями, дослідницька система Anthropic змушена була ввести бюджети на виконання завдань та суворішу систему делегування, щоб запобігти бездисциплінованому розсіюванню працівників. Використовуйте цю модель лише тоді, коли сфера діяльності справді цього вимагає.

Рої, або децентралізований спільний контекст

Координація виникає завдяки спільному стану, спільним потокам повідомлень чи змінам у середовищі, а не завдяки суворому лідеру. Тут багатоагентні системи починають перетворюватися на розподілені системи, що приносить з собою складнощі: нечітке визначення власності, ситуації конкуренції за доступ до спільного стану та складність у виправленні помилок. Цей підхід підходить для справді відкритих проблем, де агенти повинні взаємодіяти один з одним поза межами сеансу чи часу виконання. Уникайте його там, де потрібна проста відповідальність чи суворе дотримання правил.

Для більшості користувачів перші два підходи охоплюють майже все.

Що пропонує Anthropic сьогодні

Перш ніж створювати власну систему, варто перевірити, що вже надає Anthropic та чого можна навчитися з його рішень. Існує кілька способів виконання завдань за допомогою агентів, і вони не є взаємозамінними. Уявіть собі драбину, яка веде від прямого керування до централізованого управління. Наведена нижче інформація є станом на квітень 2026 року, а ці продукти швидко змінюються.

1. Messages API. Ви повністю контролюєте процес. Існують інструменти, але логіку виконання писати вам, і немає вбудованої підтримки кількох агентів. Це найбільш гнучкий рівень, але вимагає найбільше зусиль.

Claude Agent SDK. Цикл агента, інструменти, обробка контексту, підагенти, хуки та відстеження витрат походять від Anthropic, але працюють на інфраструктурі, якою ви керуєте. Підагенти є вбудованими, а все, що стосується багатоагентних сценаріїв, здебільшого є результатом вашого власного проектування. Аутентифікація здійснюється через Bedrock, Vertex AI та Azure Foundry, тому це найбільш портативний рівень.

Claude Managed Agents. Anthropic керує процесом виконання за вас: контейнери, компактування даних, кешування запитів, історія подій, сеанси зі станом та набір вбудованих інструментів. Використання одного агента вже досконале, тоді як багатоагентні сеанси знаходяться у окремому прев’ю-режимі.

Управління багатьма агентами. Дослідницька версія з обмеженим доступом та значною обмеженням: конструкція підтримує лише один рівень координатора. Координатор може викликати інші агенти, але агенти, яких він викликає, не можуть викликати ще інші. Це оркестрація багатьох агентів, проте ще не загальне рекурсивне суспільство агентів.

Підагенти Claude Code. Ізольовані контексти роботи всередині однієї основної сесії, які повідомляють про результати назад. Це офіційна функція, але не команди типу peer-to-peer.

Команди агентів Claude Code. Станом на квітень 2026 року це експериментальна функція, яка за замовчуванням вимкнена та увімкнюється за допомогою спеціальної змінної середовища. Відомі обмеження включають поведінку під час відновлення сесії, крайні випадки у координації завдань та сесії, що відновлюються та посилаються на колег, яких більше немає.

На практиці твердження «Claude підтримує команди агентів» є правдивим, тоді як твердження «Claude пропонує оркестрацію кількох агентів промислового рівня та універсального призначення на будь-якій платформі» — ні.

Команди агентів Claude Code на практиці

Коротке нагадування про різницю:

• Підагенти працюють у межах однієї основної сесії. Основна інстанція Claude Code створює їх; кожен з них працює окремо у власному вікні контексту та надсилає результати назад. Ви здійснюєте оркестрацію, а основна сесія ніколи не бере на себе роботу з отримання результату.

Команди агентів — це окремі сесії Claude Code, які взаємодіють між собою. Кожен учасник команди має власне вікно контексту та стан сесії, а також спільний список завдань та поштову скриньку для прямих повідомлень. Учасники команди можуть передавати один одному завдання та координувати свої дії, не чекаючи, поки керівник передаватиме кожну інструкцію. Керівник визначає напрямок дій, а учасники команди можуть діяти відповідно до цього та спілкуватися між собою.

Налаштування

1. Конфігурація команди знаходиться у файлі ~/.claude/teams/{name}/config.json.
2. Спільний список завдань знаходиться у директорії ~/.claude/tasks/{name}/.
3. Учасники команди визначаються у файлах агентів, які можна повторно використовувати — це фактично визначення підагентів, яким присвоюються ролі учасників команди.
4. Хуки можуть виконувати функцію контролю якості під час переходу між завданнями.

Для проектування важливі два архітектурні аспекти. По-перше, підагенти можуть мати власну автономну пам’ять. Це сприяє спеціалізації, але коли роботу розподіляють між кількома агентами з окремими пам’ятями, доводиться приймати архітектурне рішення щодо того, які знання залишатимуться локальними, які будуть спільними та які потрібно узагальнювати. Це питання проектування системи.

По-друге, у документації чітко зазначено, коли команди працюють гірше за підагентів: при послідовних завданнях, редагуванні одного й того ж файлу та роботі з великою кількістю залежностей між кроками. Якщо агенти змушені передавати один і той самий результат по черзі, не працюючи паралельно, підагенти в послідовному потоці є простішими та більш передбачуваними.

Оскільки команди на той момент ще були експериментальними та за замовчуванням вимкненими, увімкніть їх лише з чіткою причиною з наведеного вище списку та очікуйте певних недоліків.

Як агенти спілкуються між собою

Комунікація між агентами часто розглядається як проблема формулювання запитів. У масштабних системах це є проблемою самої системи. Існує три основні форми такої комунікації.

1. Повідомлення простою мовою. Це найочевидніша форма, але вона є найменш надійною у масштабних системах. Колеги в Claude Code обмінюються повідомленнями безпосередньо через поштову скриньку. Це зручно, але природна мова менш точна, ніж структуровані запити, що створює більше можливостей для неправильного розуміння між агентами.
2. Структуровані запити. Використання визначень інструментів у форматі JSON Schema та суворе дотримання правил їх використання. Визначення інструментів у Anthropic гарантують, що аргументи відповідають заданій схемі. Цей механізм робить комунікацію між агентом та інструментом надійною, а також робить взаємодію між агентами більш точною, коли її моделюють як запити до інструментів замість вільноформатних повідомлень.

Спільний стан або результати роботи. Найбільш недооцінена форма. У дослідженні Anthropic щодо багатоагентних систем рекомендується, щоб підагенти зберігали результати роботи у файловій системі чи зовнішній системі та повертали легкі посилання, замість того щоб все проходити через контекст головного агента. Причина проста: файл можна перевірити, створити версії та оглянути безпосередньо, тоді як повідомлення, що узагальнює вміст файлу, не може бути нічим із цього.

Час так само важливий, як і формат. Існує чотири основні патерни:

• Синхронні виклики. Керівник викликає спеціаліста, чекає, а потім продовжує роботу. Легко зрозуміти механізм, але це може стати вузьким місцем. За даними дослідницької команди Anthropic, синхронна робота головного агента блокувалася через повільну роботу підагентів, тому керування процесом під час виконання було відкинуто.

Послідовні передачі обов’язків. Відповідальність переходить від одного агента до іншого: один створює результат, а інший його приймає. OpenAI чітко розділяє два підходи: при передачі обов’язків спеціаліст бере на себе відповідальність за подальші дії, тоді як агент, використовуваний як інструмент, залишає керівника відповідальним. Те, хто несе відповідальність, залежить від того, який підхід обраний.

Орієнтація на події або потоковий режим. Агенти реагують на події замість синхронних викликів. Цей підхід краще підходить для тривалих завдань, але складніший у дебагуванні та тестуванні; іноді допомагають спеціальні механізми підключення.

Запитування стану спільного зберігання даних. Цей підхід не є найпривабливішим, проте часто залишається найнадійнішим варіантом. Агенти перевіряють спільний файл чи базу даних на наявність прогресу, записують там свої оновлення та продовжують роботу. Програми Anthropic, які працюють вже тривалий час, зберігають списки функцій у форматі JSON, файли з інформацією про прогрес та комітти Git як надійний спільний стан, а людські контрольні точки приєднуються до цієї структури природним чином.

Те, як агенти передають один одному інформацію, визначає надійність всієї системи. Передача повної історії розмови максимізує континуїтет, але лінійно збільшує витрати та затримки. Компресований огляд часто є кращим варіантом, і саме це роблять підагенти Claude Code за своєю конструкцією. Передача об’єктів, специфічних для завдання, таких як структуровані файли вихідних даних, патчі коду, списки функцій у форматі JSON та збережені звіти, зазвичай є оптимальним рішенням. Агент, який отримує інформацію, може безпосередньо перевірити ці об’єкти замість того, щоб покладатися на огляд, що робить систему більш піддається перевірці, на відміну від передачі інформації у форматі розмови.

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

Вісім причин провалу команд агентів

Більшість навчальних матеріалів з багатоагентних систем пропускають цю частину. Інженерні нотатки Anthropic є гарним джерелом інформації. Вони більше схожі на щоденник команди, яка поступово, шляхом усунення кожної помилки окремо, зрозуміла, що додаткові агенти посилюють проблеми управління, ніж на наукову статтю. Із них можна зробити вісім висновків.

• Зсув у координації. Нечітке делегування завдань змушує працівників повторювати один одного, не помічати меж чи повертати результати, які не узгоджуються між собою. У дослідницькій публікації Anthropic це було прямо виявлено, а рішенням стало навчання оркестратора чітко визначати мету, формат результату, критерії оцінки та обсяг завдань для кожного працівника. Там, де не визначено власників обов’язків, агенти імпровізують, і часто роблять це погано, так само, як і люди.

Галюцинація щодо власності. Агент A вважає, що агент B підтвердив щось, чого насправді ніхто не підтверджував. Ліком є чіткі артефакти завершення: точки кріплення завдань, повна верифікація перед тим, як щось буде позначено як завершене, та стійкі файли стану, які фіксують те, що було насправді підтверджено, а не те, що припускалося.

Тиха проміжна несправність. Для дебаггінгу була необхідна повна трасування в умовах реальної роботи, оскільки ніщо не вказувало на те, чи була несправність спричинена поганими запитами до пошуку, слабкими джерелами інформації чи помилкою у інструментах. Верхній рівень потоку сеансу є лише стислим переглядом, а щоб зрозуміти, що насправді зробив агент, потрібно переглянути історію на рівні працівника. Необхідно встановити систему трасування з самого початку, задовго до першої несправності в умовах реальної роботи.

Надмірне навантаження контексту та забруднення пам’яті. Вікно контексту є обмеженим ресурсом, а спільна пам’ять, яка стає застарілою чи забрудненою, погіршує роботу всієї системи. Кожен виклик інструменту, завантаження файлу та частковий аналіз потрапляють у контекст та залишаються там, і це проблема посилюється у командах. Відомі способи її усунення — це узагальнення завершених етапів, ізоляція важких завдань у підагентах та використання невеликих, спрямованих файлів пам’яті замість великих спільних.

Несуворість схем та крихкі умови взаємодії. Агенти, які обмінюються даними мовою природи, є крихкими. Другий агент неправильно інтерпретує узагальнення першого, і помилка поширюється безслідно. Існує суворе правило використання інструментів, оскільки несуворі виклики можуть призвести до несумісних типів даних чи відсутності полів. Вузькі умови взаємодії між агентами та інструментами зменшують можливості виникнення таких проблем, що є іронічною роллю звичайних інженерних угод у середовищі ШІ.

Неправильне використання інструментів та проблеми з безпекою. Чим більше відкритих середовищ, тим більше точок входу для введення команд, а чим більше інструментів, тим більше способів для зловмисника діяти після проникнення. Дослідження Anthropic щодо надійних агентів називає введення команд вектором кібератаки, а не окремим винятком, а перевірки внутрішніх систем моніторингу агентів Anthropic командою METR, за повідомленнями, виявили нові вразливості навіть у добре обладнаній внутрішній системі. Зменшіть ризик за допомогою обмежених прав, інструментів, обмежених потребами завдання, та людського схвалення для критичних дій.

Експлозія витрат та збільшення затримок. Команди використовують значно більше токенів, ніж потрібно для однієї сесії. Паралелізм може скоротити час виконання, але при цьому збільшує загальні витрати на токени, а не зменшує їх, оскільки прискорення досягається завдяки спрямуванню більшої кількості ресурсів на виконання завдання одночасно. Якщо завдання не вимагає таких витрат, більш ефективним та дешевшим варіантом є ретельно створений один агент.

Складність оцінки. Цілком різні внутрішні шляхи можуть призвести до результату, який здається успішним. Якщо єдиним критерієм є те, чи звучить кінцевий текст переконливо, то систему оцінюють не за фактом виконання завдання, а лише за зовнішнім виглядом результату. Рекомендація Anthropic — перевіряти, чи досягнуто правильного кінцевого стану, а не чи дотримувався запланований процес. Процес може відрізнятися, але результат — це те, що можна підтвердити.

Нативний, самостійний чи гібридний

Отже, головне питання: створювати систему оркестрації самостійно чи використовувати готове рішення? Це архітектурний компроміс між трьома варіантами, причому їх, безумовно, більше, тож сприймайте це як одну з точок зору.

1. Нативно кероване означає, що Anthropic контролює середовище виконання та механізми координації: Claude Managed Agents, а точніше — Managed Agents multiagent чи команди агентів Claude Code. Перевагами є менша кількість інженерних зусиль та наявність хостованої інфраструктури, яку не потрібно підтримувати. Недоліками є обмежена портабельність (Managed Agents доступні лише через прямий API Claude), експериментальний рівень функціоналу багатоагентних систем або їх доступ у прев’ю, а також залежність від сторонньої компанії. Вибирайте цей варіант, коли проблемою є інфраструктура, а обмеження, пов’язані з Anthropic, є прийнятними.

DIY означає, що ви контролюєте логіку організації роботи системи, а зазвичай і її функціонування під час виконання, причому Messages API є найкращим прикладом цього підходу. Він забезпечує найбільший контроль, але вимагає значних інженерних зусиль. Оберіть цей варіант, якщо ваша бізнес-логіка є незвичайною, правила відповідності суворими, маршрутизація специфічна для вашої сфери діяльності, або якщо необхідна справжня портативність сервісу.

Гібридний підхід означає, що Anthropic надає цикл обробки та інструменти, поки ви проектуєте систему, причому найяскравішим прикладом є Claude Agent SDK. Ви отримуєте механізм циклу агента, керування контекстом, функції підключення, підагенти та засоби для моніторингу від Anthropic, при цьому зберігаючи контроль над вищорівневим проектуванням. Аутентифікація через Bedrock, Vertex AI та Azure Foundry є значною перевагою з точки зору портативності порівняно з нативними рішеннями. Оберіть цей варіант, якщо хочете скористатися механізмами циклу від Anthropic, не прив’язуючи всю архітектуру до їхнього поточного підходу до функціонування багатоагентних систем.

Коротко кажучи: нативні рішення — коли проблемою є інфраструктура, самостійне проектування — коли проблемою є топологія та політики, а гібридний підхід — коли ви хочете скористатися примітивами від Anthropic, але потребуєте свободи для власних архітектурних рішень.

Питання архітектури

Уявлення, яке більшість людей має щодо команд агентів, — це здатність, ґрунтуючись на теорії, що більше агентів означає більшу здатність. Корисним підходом є архітектура: яку проблему вирішує додатковий агент та яка це коштує?

Підагенти вирішують, хто буде виконувати роботу, у якому контексті та з якими інструментами. Команди агентів додають верхній шар координації з спільним станом завдань, колегами, які можуть спілкуватися один з одним безпосередньо, та паралельними процесами, які організовуються самостійно. Такий шар є ефективним лише для проблем, які справді вимагають його.

Одна добре налаштована команда агентів для реального випадку використання — це обсяг роботи на тиждень. Складність може зростати далі, але не обов’язково починатися саме з цього. Наведений вище каталог помилок та шаблони комунікації слугують довідковим матеріалом, а не планом для створення всього одночасно. Почніть з визначення того, який із чотирьох тригерів насправді діє, а якщо жоден з них не діє, то шлях із одним агентом все ще є правильним.