Claude Agent Teams: координування кількох сесій

Навчальний розділ курсу «AI Development» (Artificial Intelligence — штучний інтелект; тут — розробка програмного забезпечення за допомогою ШІ) · зріз документації та продукту: 10.10.2026

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

Цей розділ розглядає саме Agent Teams у Claude Code: команду окремих сесій Claude Code під координацією провідної сесії. Станом на 10 жовтня 2026 року офіційна документація позначає функцію як експериментальну й вимкнену за замовчуванням. Її можна ввімкнути параметром CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 у налаштуваннях або середовищі Claude Code. Найновіший випуск у журналі змін на дату зрізу — v2.1.296 від 9 жовтня 2026 року. Цей номер описує доступний на дату зрізу клієнт, а не мінімальну вимогу для кожної функції команди. Перевіряйте документацію та встановлену версію перед проєктним використанням. [1][2]

33.1. Команда, субагенти та кілька незалежних сесій — різні моделі

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

Модель роботи	Що відбувається	Коли може підійти	Основна межа
Субагент (subagent)	Окрема дочірня задача всередині поточної сесії. Субагент має свій робочий контекст і повертає результат викликачеві.	Обмежене дослідження, перевірка чи підзадача, яку можна доручити, а потім зібрати в основній сесії.	Це не повноцінний колектив із власною координацією: головна сесія лишається місцем зведення.
Agent Team	Провідна сесія Claude Code організує окремі сесії-учасники (teammates), спільний перелік завдань та обмін повідомленнями. Учасники мають окремі контексти, але працюють над спільним проєктом.	Кілька незалежних областей аналізу або зміни, де корисні пряме спілкування учасників і координація завдань.	Спільний проєкт не стає автоматично ізольованим: файли, робочий стан і зовнішні ресурси можуть конфліктувати.
Вручну скоординовані сесії	Людина або процес запускає окремі сесії незалежно й переносить між ними інструкції та результати.	Коли потрібен ручний контроль, різні середовища або явне розділення етапів.	Немає спільного переліку завдань Agent Teams; узгодження, передача стану та повтори — відповідальність координатора.

Отже, субагент не тотожний учаснику Agent Team. Субагент зазвичай виконує доручення в межах однієї сесії; учасник команди — окрема сесія з власним контекстом та адресними повідомленнями. А кілька вікон Claude Code самі по собі не утворюють Agent Team. Документація також попереджає: у режимі команд Claude Code може перетворити названий субагент на учасника команди, навіть якщо користувач явно не просив цього; сам вигляд командної панелі не доводить, що це сталося. [1][3]

Agent Teams доступні для інтерактивного використання Claude Code. У неінтерактивному режимі, зокрема при запуску з параметром -p, і в програмному наборі засобів розробки (Software Development Kit, SDK) Claude Code не запускає учасників Agent Team і повертається до звичайних субагентів. Тип відображення також має значення: стандартний режим показує кількох учасників у тому самому терміналі; поділ на панелі залежить від tmux (terminal multiplexer — мультиплексор термінала, що розміщує кілька термінальних сеансів у спільному вікні) або iTerm2. Офіційний список обмежень називає Windows Terminal, термінал Visual Studio Code та Ghostty несумісними з поділом на панелі. Це обмеження відображення, а не доказ, що самі Agent Teams доступні тільки в цих двох терміналах. [1]

33.2. Спершу визначте, чи справді потрібна команда

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

Якщо задача послідовна — спершу треба визначити продуктове правило, потім написати код і лише тоді перевірити міграцію — поділ між кількома виконавцями може створити очікування та повторну роботу. Якщо підзадачі незалежні, наприклад окремі читання документації, перевірка способів використання API (Application Programming Interface — програмний інтерфейс застосунку, формалізований спосіб, у який одна програма звертається до функцій іншої) та аналіз тестових сценаріїв, команда може скоротити затримку до першого зведеного висновку. Це лише можливість, а не гарантія: учасники можуть витратити час на однаковий контекст, пропустити залежність або не узгодити результат.

Чіткий контракт підзадачі відповідає на такі питання:

Поле контракту	Що зафіксувати
Мета й межа	Яке питання вирішити; що не входить у задачу.
Вхідний стан	На якому commit або іншій ревізії ґрунтувати висновок; які файли й джерела читати.
Власник	Хто відповідає за результат і кому його передати.
Дозволи	Читати, редагувати, запускати перевірки чи робити зовнішню дію; окремо — що заборонено.
Інваріанти	Які правила спільні для всіх: формат даних, семантика станів, сумісність, межа зовнішніх побічних ефектів.
Вихід і докази	Формат відповіді; конкретні файли, рядки, джерела, результати перевірки та невідомі.
Умова завершення	Які докази потрібні, щоб сказати «готово»; як повідомити блокер або суперечність.

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

Учасникам потрібна достатня інструкція для самостійної роботи, але не вся історія розмови провідної сесії. Вони не успадковують її попередній діалог; водночас отримують спільні для проєкту налаштування, зокрема CLAUDE.md, налаштовані сервери протоколу контексту моделі (Model Context Protocol, MCP) і Skills. Тож контракт має прямо містити потрібний контекст, а спільні правила проєкту слід підтримувати там, де учасники справді зможуть їх прочитати. Не варто пересилати повний чат замість стислого стану, рішення та посилань на перевірні матеріали. [1]

33.3. Координація: власник, повідомлення і докази

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

Корисне повідомлення — не «готово», а короткий доказовий запис:

Перевірив використання POST /reservations на ревізії D7. У web/src/reservations.ts:48 запит передає ключ ідемпотентності; у jobs/import-reservations.ts:112 його немає. Не змінював файли. Не знаю, чи пакетний імпортер має створювати такий ключ: потрібне продуктове рішення. Підсумок і перелік шляхів у відповіді до задачі «API usage».

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

Для обміну зручно розрізняти чотири типи повідомлень:

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

Учасник не повинен позначати підзадачу завершеною лише тому, що закінчив читати. Власник завершує її, коли надав передбачений результат і докази. Провідна сесія незалежно перевіряє, чи доказ актуальний, чи відповідає він контракту й чи потрібна інтеграція. За документацією Claude Code статуси переліку завдань можуть оновлюватися із затримкою; отримане повідомлення чи мітка completed є сигналом для перевірки, а не самою перевіркою. [1]

Це розрізнення важливе й для історичних звітів. У серпні 2026 року користувач описав у GitHub проблему, де фінальна текстова відповідь фонового учасника не доходила до провідної сесії, а натомість надходило лише повідомлення про готовність без змісту. Звіт називав окремі версії та середовище автора, а не всі команди; сам issue закритий як not planned. Журнал змін Anthropic для v2.1.251 від 28 серпня окремо описує виправлення такого самого симптому, але не посилається на цей issue. Тому коректний висновок — це історичний сигнал, чому треба вимагати явного результату й перевіряти його; не доказ чинного дефекту у v2.1.296 і не підтвердження, що саме цей issue був джерелом виправлення. [2][7]

Розбиття та синхронізація

Розгалуження й зведення (fan-out/fan-in) — це схема, де координатор роздає кілька незалежних підзадач, а потім збирає їхні результати в одне рішення. Вона корисна лише тоді, коли залежності видно заздалегідь. Наприклад, дослідження API, міграції та тестів можуть початися паралельно, але створення унікального індексу має чекати на підтверджене правило обробки старих дублікатів.

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

Готовність прив’язана до конкретної ревізії. Якщо перевірки стосувалися D7, а файл змінився в D8, твердження «перевірено» не переноситься на D8. Зведений висновок має сказати, що саме перевірене на якому стані, що змінилося потім і які докази треба оновити. Сам факт, що кілька учасників працювали одночасно, не робить їхні незалежні результати узгодженими.

33.4. Спільне середовище — це спільні ризики

Окремий контекст розмови не означає окремий робочий простір, дані чи зовнішні повноваження. Claude Code описує команду як кілька сесій, що працюють в одному проєкті. Документація окремо радить уникати конфліктів редагування одного файлу: учасники, які одночасно змінюють його, можуть перезаписати один одного. Тому розділяйте файли за власниками або призначте одного власника спільного файлу й інших — читачами/рев’юерами. Не робіть висновок, що Agent Teams автоматично створює ізольовану гілку чи worktree для кожного учасника. [1]

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

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

33.5. Делегування не розширює повноважень

Корисно окремо розглядати три речі: текстове доручення, фактичний доступ інструментів та межу, за якою потрібне погодження людини. Prompt може сказати «не змінюй файли», але сам текст не є системним контролем доступу. І навпаки, наданий інструмент може дозволити зміни, яких автор задачі не мав на увазі. Реальні правила Claude Code застосовуються продуктом, а не створюються однією інструкцією моделі; зовнішня автентифікація та обмеження сервісу є окремими шарами. [4]

У поточній документації учасники команди успадковують від провідної сесії режим дозволів, крім режиму dontAsk; якщо провідна сесія використовує --dangerously-skip-permissions, його успадковують усі учасники. На момент створення не можна задати окремий режим дозволів для кожного учасника, хоча його можна змінити пізніше. Запити на дозвіл від учасника спрямовуються до провідної сесії, де погодження належить людині. Повідомлення учасника не може замінити згоду користувача або обійти відмову. Є важлива тонкість: схвалення плану команди автоматично надається Claude у провідній сесії без попереднього перегляду людиною — тому це не слід подавати як людське погодження. [1]

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

33.6. Збої, повтори та завершення команди

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

Ситуація	Безпечне наступне рішення
Учасник не відповів	Зафіксувати останню відому ревізію та стан; перевірити, чи є часткові зміни; призначити іншого власника лише після перевірки цих змін.
Частковий результат	Попросити назвати готову й незавершену частини, потрібний наступний доказ і блокер; не трактувати проміжний звіт як завершення.
Повторна дія	З’ясувати, чи дія має ідемпотентний ефект (повтор не змінює результат понад перше виконання); якщо ні — перевірити стан зовнішнього ресурсу до повтору.
Різні висновки	Порівняти джерела, час і ревізії; доручити власнику контракту розв’язати саме розбіжність, а не усереднювати суперечливі відповіді.
Зупинка або скасування	Зупинити нові дії; перевірити активні процеси та часткові зовнішні ефекти; призначити їх власника й очистити лише за визначеною процедурою.

Claude Code документує й конкретні поточні обмеження: одна команда на сесію; не можна передати роль провідного учасника; сесію команди з учасниками не можна відновити як завершену команду; статус задач може запізнюватися; запит на завершення учасника може чекати, доки той закінчить поточний виклик інструмента; вкладені фонові субагенти від учасників не підтримуються. Ці факти мають значення для плану відновлення: не покладайтеся на нескінченне очікування або автоматичне відновлення всього стану після переривання. [1]

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

33.7. Чому інтеграційний огляд лишається обов’язковим

Кожен підрезультат може бути локально правильним і водночас несумісним із сусіднім. Один учасник трактує unknown як безпечну відмову, інший — як успішний стан. Дослідження API може спиратися на стару ревізію, а тестовий огляд — уже на змінену. Тому провідна сесія або людина-власник має переглянути набір змін цілком: спільні типи даних, інваріанти, виклики, міграції, тести, помилки, зовнішні ефекти й докази на актуальній ревізії.

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

33.8. Межі як питання для людей, а не «оргструктура агентів»

У Team Topologies, 2-му виданні, Метью Скелтон і Мануель Пейс описують когнітивне навантаження команд, межі та способи взаємодії між ними. Тут ці ідеї можна використати лише як запитання до дизайну задачі: чи має підзадача зрозумілий контекст? Яка команда або роль володіє спільним контрактом? Де потрібна співпраця, а де достатньо сервісної передачі результату? Не призначайте сесіям формальні людські типи команди з цієї книжки й не робіть висновку, що структурна схема доводить ефективність Agent Teams. Доступні публічні матеріали автора й видавця; повний текст книжки не перевірявся. [5]

Фредерік Брукс у The Mythical Man-Month звертав увагу на помилку вважати людські людино-місяці взаємозамінними та плутати зусилля з прогресом. Як обережне питання до роботи агентів це можна сформулювати так: чи скорочує розділення саме критичний шлях, чи створює додаткові витрати на пояснення, узгодження та зведення? Це перенесення запитання на інший контекст, а не емпіричний закон про швидкість агентів. Відкритий уривок і матеріали видавця не дають підстав заявляти, що весь текст книжки прочитано або що він досліджував сучасні моделі. [6]

33.9. Повний вигаданий приклад: дослідження API, міграції й тестів

Ситуація. Умовний сервіс бронювання має підтримати повторне подання однакового запиту. Завдання — з’ясувати, як додати ключ ідемпотентності до POST /reservations, не створивши дублікатів під час повтору після мережевого тайм-ауту. У прикладі команда працює з умовною ревізією D7. API означає програмний інтерфейс застосунку (Application Programming Interface) — формалізований спосіб, яким одна програма надсилає запит іншій.

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

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

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

Власник	Межа	Потрібний результат
Дослідник API	Лише шляхи формування POST /reservations на D7	Файли й рядки кожного клієнта; чи передається ключ; що клієнт робить після тайм-ауту; невідомі.
Дослідник міграцій	Лише схеми та історичні міграції на D7	Умови для унікального ключа; ризики дублікатів і вимоги до зворотної сумісності; без запуску міграцій.
Дослідник тестів	Лише тести й fixtures на D7	Які випадки вже перевіряються; що покриває повторний запит і паралельний запит; відсутній доказ.

Спостережуваний результат. Умовні звіти знаходять, що веб-клієнт передає ключ, а пакетний імпортер — ні; історичні записи містять повтори, які можуть порушити унікальний індекс; тест перевіряє послідовний повтор, але не одночасні однакові запити. Координатор зводить їх не до «можна мігрувати», а до трьох перевірених фактів і одного відкритого питання: чи має імпортер створювати ключ, і що робити з наявними дублікатами? До відповіді продуктового власника міграція та код лишаються заблокованими. Коли правило визначене, один призначений власник схеми оновлює міграцію й код на новій ревізії; інший перевіряє веб- і пакетний сценарії та гонку паралельних запитів. Результат приймають лише після зведення змін і перевірки на цій новій ревізії.

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

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

33.10. Повний вигаданий приклад: два несумісні типи даних

Ситуація. Умовний сервіс доставки хоче додати статуси транзакцій. Два учасники незалежно реалізують цю зміну. Перший вважає канонічними значення captured і failed; другий очікує лише settled і declined.

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

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

Дія. Координатор зупиняє обидві зміни і показує суперечність із посиланнями на конкретні файли та ревізії. Власник продуктового/схемного контракту визначає повний перелік допустимих станів, перехід між ними та обробку невідомого значення; для прикладу вирішує, що невідоме значення не можна вважати успішним. Потім один учасник стає єдиним власником визначення DeliveryState, а інший отримує обмежену задачу: оновити відображення інтерфейсу й додати тест на невідоме значення, не змінюючи спільний тип. Координатор перевіряє всі посилання на тип, зведені зміни та тести на єдиній новій ревізії R4.

Спостережуваний результат. У прикладі конфлікт більше не приховано двома наборами локально успішних тестів. Зафіксований контракт, один авторитетний тип і тест для невідомого значення показують, як споживачі поводяться за межами очікуваних випадків. Стан «готово» надається лише після перевірки всіх викликів і результатів на R4.

Чому таке рішення підходить. Спільний тип є точкою узгодження. Його визначення належить одному власнику; після цього інші учасники можуть працювати в різних областях, не створюючи альтернативних трактувань. Офіційна документація Claude Code прямо радить розподіляти роботу так, щоб зменшити ймовірність одночасних змін того самого файлу. [1]

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

33.11. Повний вигаданий приклад: п’ять агентів виправляють одну друкарську помилку

Ситуація. В одному рядку текстового сповіщення слово «підтвердження» надруковано з пропущеною літерою. Треба виправити написання, не змінюючи поведінку.

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

Альтернативи. Один автор може виправити рядок, а інша людина — прочитати diff. Якщо текст є частиною регуляторно важливого повідомлення або змінюється спільний словник перекладів, ширший огляд може бути обґрунтованим, але тоді треба назвати конкретний ризик, який кожен додатковий учасник перевіряє.

Умовний розрахунок витрат. Усі числа нижче — вигадані припущення для демонстрації, не замір Claude Code, не ціна токенів і не бенчмарк. Для однієї сесії припустімо 8 тисяч токенів контексту та дві хвилини людського огляду. Для п’яти учасників припустімо 5 тисяч токенів на бриф і координацію, 6 тисяч для кожного учасника, який окремо читає файл і правила (ще 30 тисяч), та 7 тисяч на зведення й інтеграційний огляд. Усього умовно 42 тисячі — у 5,25 раза більше від базових 8 тисяч. Якщо кожен із п’яти звітів ще й читає людина, допустімо вісім хвилин огляду замість двох. Результат однаковий: виправлений один символ і перевірений diff.

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

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

Межі. Розрахунок не можна переносити на інші задачі чи версії як вимір продуктивності. Якщо одна друкарська помилка впливає на критичний юридичний текст, п’ять незалежних перевірок можуть зменшити конкретний ризик, але це рішення треба обґрунтувати цим ризиком, а не загальною ідеєю «більше агентів — швидше».

33.12. Коротка схема проєктування Agent Team

Перед запуском команди провідна сесія або людина-координатор може зафіксувати такі пункти:

1. Назвати кінцевий результат, межу роботи й те, що явно не входить у неї.
2. Перевірити, чи підзадачі незалежні, достатньо великі й мають чітких власників.
3. Зафіксувати спільну базову ревізію, контракт даних, інваріанти та власника спільних файлів.
4. Вказати для кожного учасника доступні дії, заборонені побічні ефекти, потрібні джерела і точний формат доказів.
5. Визначити залежності, точки зведення, блокери, безпечні умови повтору та кому належать часткові ресурси.
6. Прив’язати кожне твердження про готовність до актуальної ревізії і перевірити всі результати разом.
7. Оцінити не обсяг паралельної роботи, а прийнятий результат, вартість координації та час людського огляду.

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

Джерела та подальше читання

Стан продукту й поточних онлайн-сторінок перевірено 10 жовтня 2026 року. Документація Claude Code змінюється; її наведений стан не слід вважати обіцянкою функцій у будь-якій майбутній версії.

1. Anthropic, Orchestrate teams of Claude Code sessions, поточна онлайн-документація Claude Code, доступ 2026-10-10. Використано для експериментального статусу, налаштування, інтерфейсів, архітектури команди, завдань і повідомлень, дозволів, спільного робочого простору, обмежень, вартості та рекомендацій щодо координації.
2. Anthropic, Claude Code changelog, журнал змін; випуск v2.1.296 від 2026-10-09 є найновішим на дату доступу 2026-10-10. Agent Teams згадано як research preview у v2.1.32 від 2026-02-05; виправлення проблеми з фінальною відповіддю учасника описано у v2.1.251 від 2026-08-28.
3. Anthropic, Subagents, поточна онлайн-документація Claude Code, доступ 2026-10-10. Використано для відмінності субагентів від команд сесій і їхніх меж.
4. Anthropic, Permissions, поточна онлайн-документація Claude Code, доступ 2026-10-10. Використано для відмінності системно застосовуваних дозволів від текстових інструкцій; фактичні повноваження залежать також від налаштування Claude Code і зовнішньої автентифікації.
5. Метью Скелтон і Мануель Пейс, Team Topologies: Organizing Business and Technology Teams for Fast Flow, 2nd edition, IT Revolution, видання 2025 року; сторінка автора й короткий виклад концепцій Key Concepts, доступ 2026-10-10. Використано лише публічні описи когнітивного навантаження, командних меж і взаємодій; повний текст книжки не перевірявся. Ці ідеї не є моделлю статусів AI-агентів і не доводять швидкість Agent Teams.
6. Фредерік П. Брукс-молодший, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, 2nd edition, Addison-Wesley Professional, видання до 20-ї річниці, 1995/1996; відкритий уривок видавця Chapter 2: The Mythical Man-Month, доступ 2026-10-10. Використано обмежений доступний уривок про плутання зусиль і прогресу; повний текст книжки не перевірявся. Перенесення цього запитання на агентів у розділі явно позначене як обережна аналогія, не доказ чи емпіричне узагальнення.
7. Anthropic, GitHub issue #86090: Named background teammate completes with a final text message that is never delivered to the parent, відкрите користувацьке повідомлення від 2026-08-12, доступ 2026-10-10. Це одиничний історичний звіт про Agent Teams в окремих середовищах і версіях, закритий як not planned; він не доводить наявність дефекту в поточній версії. Журнал змін v2.1.251 окремо описує виправлення симптома, коли фінальна відповідь учасника не доходила до провідної сесії й надходило лише повідомлення про готовність; сам changelog не називає issue #86090, тому прямий зв’язок між записами не стверджується. [2]
8. Anthropic, Claude Code v2.1.296 release notes, випуск від 2026-10-09, доступ 2026-10-10; використано для встановлення найновішого випуску на дату зрізу.