Команди агентів: можливості й обмеження

1. Спокуса команди агентів і де вона обманює

Якщо чесно, agent team звучить дуже спокусливо. Один агент читає код, другий — тести, третій — UI, четвертий готує review, і все одразу. Мінівідділ розробки без відпусток, кавових пауз і дейлі — надто добре, щоб бути правдою. І, як це часто буває в інженерії, саме тут я раджу пригальмувати.

Після fitness check питання таке: якщо паралельність виправдана, це кілька ролей (reviewer, investigator, executor) чи вже важка форма із загальним шаром координації? На цій межі зʼявляється agent team. Проблема в тому, що люди чують team і подумки домальовують те, чого система не обіцяла: колективний розум, синхронізацію «як у живої команди», майже автономну розробку. Насправді це скоординована група ізольованих контекстів — у кожного свій шматок задачі, своє вікно контексту, свої обмеження, своя зона сліпоти. Правило про coordination cost з першої лекції рівня тут працює на повну силу: чим більше агентів, тим дорожча координація, і виправдовувати її треба реальною паралельністю та чіткою перевіркою.

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

2. Що таке agent team у цьому курсі

Щоб не плутатися в термінах, одразу домовимося про строгий зміст. Agent team — це не «відкрито кілька сесій» і не «я двічі викликав subagent». Це організована схема з координуючою роллю, учасниками в окремих контекстах, спільним шаром координації та явними точками повернення результату людині. Назви команд і кнопок у Claude Code змінюються від версії до версії — важливіша модель, ніж інтерфейс. По суті схема складається з кількох частин:

Тут корисно один раз зібрати ієрархію, щоб потім не склеювати різні рівні в одну купу:

• multi-agent — парасолькове поняття для будь-якої скоординованої роботи, де більше одного worker context;
• agent team — важка форма multi-agent з lead, teammates, task list і handoff;
• orchestration pattern — схема ролей і артефактів, яка може існувати і без повноцінної team-схеми;
• конкретну роль може виконувати main session, fresh session, subagent або людина.

Тут особливо важливо не переплутати agent team із просто паралельними вкладками. Три сеанси Claude з трьома запитами — ще не team. Team починається там, де є координація, ролі, спільна точка складання та відповідальність за переходи.

Ще одна важлива деталь: навіть якщо в продукті є сутність team lead, людина все одно стоїть над конструкцією. Lead координує, але власником результату, ризику та merge залишаєтеся ви. AI-тимлід не піде на лікарняний — але й не підпише за вас release note, rollback plan і рішення «чи можна це мержити».

3. Ізольовані контексти: сила й межа

Сильна сторона agent team проста: кожен працює у своєму контекстному вікні. Один копирсається в тестах, другий читає UI-шар, третій розбирає конфіги — основна сесія не перетворюється на звалище гіпотез, а людина отримує компактні handoff-результати.

Але саме тут живе і головне обмеження: ізольовані контексти — не спільна памʼять. Знайшов один учасник критичну деталь у orders/refund — другий про неї дивом не дізнається. Деталь треба передати: через summary, task list, handoff або рішення lead-ролі. Спільна дошка завдань — це дошка, а не колективний розум із наукової фантастики.

Ось проста схема того, як це виглядає на рівні потоків інформації:

flowchart TD
    H[Людина] --> L[Lead / координатор]
    L --> A[Teammate A]
    L --> B[Teammate B]
    L --> C[Teammate C]
    A --> T[Спільний task list / handoff]
    B --> T
    C --> T
    T --> L
    L --> H

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

4. Agent team на прикладі Commerce OS

Щоб усе це не залишилося красивою абстракцією, давайте подивимося на близький нам контекст. Завдання в Commerce OS: у черзі повернень позначати запити понад 100 доларів, щоб оператор не пропускав high-value кейси без ручного підтвердження. Не один файл і не один рядок — тут бізнес-правило, UI inbox, наявні тести та ризик регресії в refund flow. Ось де team може бути корисною — але саме як паралельне дослідження, а не як «чотири агенти одночасно переписують проєкт»:

Lead:
- збирає постановку й обмеження
- утримує правило: без широких edits

Колега A:
- перевіряє backend refund rule і пов’язані конфіги

Колега B:
- дивиться UI inbox і badge/alert path

Колега C:
- аналізує наявні tests і coverage gaps

Людина:
- вирішує, чи потрібен один спільний executor після дослідження

Зверніть увагу на одну тиху, але дуже важливу деталь. У цьому прикладі майже всі ролі можуть залишатися read-only. Це зрілий сценарій. Команда не кидається одразу писати код у три боки. Вона спочатку розпаралелює дослідження: де живе логіка, де буде UI-ефект, де є прогалини в тестах, які ризики ми побачимо раніше, ніж почнемо правити файли.

Такий підхід дає реальну користь. Людина отримує не одну величезну туманну відповідь «я все подивився», а кілька більш вузьких звітів із evidence. Після цього вже легше ухвалити рішення: чи достатньо одного executor-а, чи варто заводити worktree, чи не зачіпаємо ми чутливу зону, чи не пішла задача в більш ризиковану область, ніж здавалося на початку.

І ось це важлива думка: найдоросліша agent team часто спочатку допомагає звузити задачу, а не зробити її «автоматично великою».

5. Де обмеження кусаються серйозно

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

Особливо підступний перший рядок. Coordination cost — це не лише токени. Це ваші очі, ваша увага і ваш час на ухвалення рішень. Три акуратні звіти по 150 рядків кожен — це вже не прискорення саме по собі. Це матеріал, який ще потрібно прочитати, зіставити, перевірити на суперечності й перетворити на подальшу дію. Якщо задача була малою або середньою, ви дуже легко програєте за сумарним зусиллям.

Друга проблема — shared state. Припустімо, один учасник уже зрозумів, що публічний API змінювати не можна, а інший на старій постановці встиг побудувати висновок, який якраз на цю зміну спирається. Технічно обидва працювали чесно. Але загальна картина вже розʼїхалася. Без явного механізму handoff і оновлення спільного task list це спливе пізно — зазвичай у той момент, коли ви вже емоційно готові вірити красивому зведенню.

Ще неприємніше виглядає історія з resumption. Будь-яка складніша схема погано переносить переривання. Один учасник не повернувся, другий завис, третій встиг закінчити, але контекст lead-а вже застарів. У підсумку ви або повторюєте частину дослідження, або ухвалюєте рішення за неповним матеріалом. І ось тут стає ясно: agent team — це не безплатна паралельність, а організаційна конструкція, яку потрібно підтримувати.

6. Human checkpoint не прибирається навіть у «розумної» team

На цьому місці у новачків часто зʼявляється небезпечна думка: «Ну якщо lead уже все зібрав, може, нехай система сама вирішить, що робити далі?» Звучить логічно рівно до першого чутливого кейсу. У реальній інженерній роботі human checkpoint нікуди не зникає, бо саме людина несе відповідальність за trade-offs, ризик і фінальний крок.

Team може прекрасно паралелити дослідження. Може швидко порівняти кілька гіпотез. Може зібрати evidence по різних частинах codebase. Але як тільки справа стосується рішення рівня «тепер пишемо код», «цей diff можна мержити», «це зачіпає refund flow», «ми впевнені, що scope не розповзся» — тут усе одно потрібна людина. Не тому, що ШІ «дурний», а тому, що інженерне рішення — це не лише сума знайдених фактів, а й відповідальність за наслідки.

Можна сформулювати це трохи жорсткіше: agent team без human checkpoint — це не смілива автоматизація, а просто перенесення ризику в туманну зону. Особливо небезпечно це на шляхах, повʼязаних з оплатою, авторизацією, даними користувача та будь-якими shared-contract змінами. У таких місцях красивий зведений звіт ще не дорівнює безпечній дії.

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

7. Небезпечні обіцянки про agent team

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

Особливо небезпечна перша обіцянка. Вона звучить натхненно, але насправді змушує вас проєктувати занадто широкий scope. Замість вузького питання «які частини можна досліджувати паралельно?» зʼявляється фантазія «як би цю штуку зробити без моєї участі». І майже завжди це закінчується не автономією, а дорожчою і крихкішою версією звичайної роботи.

Нормальна зріла установка звучить набагато нудніше — і тому набагато корисніша. Agent team не будує проєкт за вас. Вона допомагає швидше розібрати складну задачу на незалежні шматки аналізу і повернути вам проміжні результати у вигляді, придатному для рішення. Це вже дуже цінно. Просто це не магія, а інженерний інструмент із цінником у вигляді уваги, координації та перевірки.

8. Схема у Workflow Kit рятує team

Будь-яка advanced-можливість швидко перетворюється на міф, якщо її ніде не зафіксувати як робочий артефакт. Тому в Workflow Kit корисно тримати хоча б дуже коротку текстову схему, яка відповідає на три питання: хто координує, хто що дивиться і де людина зупиняє автоматизм. Це не окремий ritual поверх усього іншого, а просто чорновик pipeline під team-сценарій.

Навіть така маленька заготовка вже допомагає:

[людина-власник]
   ↓ затвердити
[lead: координація]
   ├─ [A: API scan, read-only]
   ├─ [B: UI scan, read-only]
   └─ [C: test scan, read-only]

handoff: AGENT_HANDOFF_CONTRACT.md
finish: людина вирішує наступний executor

Корисність цієї схеми в тому, що вона змушує вас відповісти на незручні питання до старту роботи. Хто пише код? А може, поки що ніхто. Хто збирає висновки? Lead. Де лежить handoff-формат? В уже знайомому AGENT_HANDOFF_CONTRACT.md. Де стоп-лінія? Перед наступним рішенням людини щодо executor. Із таким записом agent team перестає бути красивою вивіскою «ми тепер працюємо багатьма агентами» і стає звичайним інженерним інструментом: дорогим, обмеженим, не завжди потрібним, але зрозумілим.