Дві екосистеми: Claude Code і OpenAI Codex
Claude Subagents: окремий контекст для делегованої задачі
Claude Subagents: окремий контекст для делегованої задачі: Навчальний розділ курсу «AI Development» (Artificial Intelligence, штучний інтелект) · зріз…
Навчальний розділ курсу «AI Development» (Artificial Intelligence, штучний інтелект) · зріз мінливої документації: 10.10.2026
Уявімо, що перед випуском зміни треба прочитати кілька тисяч рядків журналів, перевірити три незалежні модулі або зіставити вимогу з файлами й тестами. Якщо головна розмова отримає весь проміжний матеріал, корисний контекст загубиться серед деталей. Claude Code може передати таку роботу subagent — допоміжному агенту в межах тієї самої сесії. Той отримує окреме контекстне вікно, виконує обмежене завдання та повертає результат головному агенту.
Subagent не бачить автоматично всієї історії головної розмови. Водночас окремий контекст не означає окрему машину: за звичайного запуску він часто працює у тому самому репозиторії, може отримати ті самі інструменти й доступ до зовнішніх систем. Контекстна межа зменшує шум, але не гарантує безпеку, незалежність або правильність. Файли, мережа, дозволи та зовнішні ефекти мають власні межі.
Нижче йдеться саме про Claude Code, не про кожен продукт Anthropic. Документацію та відкриті повідомлення про помилки перевірено 10 жовтня 2026 року; останнім релізом на сторінці Claude Code Releases на цю дату був v2.1.296 від 9 жовтня. Він, зокрема, додав поле <code>autoCompactWindow</code> до конфігурації субагента. Це часовий зріз, а не обіцянка для всіх версій. Поля конфігурації та поведінка клієнта змінюються; перед практичним застосуванням перевіряйте версію Claude Code і відповідну документацію. [9]
32.1. Що делегується і що повертається
У звичайній моделі subagent — це не незалежний виконавець, який сам визначає ціль команди. Головний агент або користувач доручає йому конкретну частину роботи. Subagent отримує власний контекст і доступні йому інструменти, працює, а потім передає результат тому, хто його викликав. Головний агент координує роботу, вирішує, що прийняти, та формує відповідь для користувача.
Наприклад, головний агент може попросити одного subagent дослідити, звідки береться помилка, а іншого — знайти місця, які викликають підозрілу функцію. Кожен має передати не лише висновок, а й докази: файл, точний рядок чи фрагмент, умову, за якої проблема проявляється, та невідомі обставини. Головний агент зіставить результати й сам перевірить важливе перед тим, як назвати зміну готовою.
У Claude Code є вбудовані типи дослідника Explore і планувальника Plan, а також загальний General-purpose та допоміжні типи. Вбудовані Explore і Plan призначені для читання й аналізу: їхні Write та Edit інструменти заборонені. General-purpose може виконувати багатоетапну роботу, включно з дослідженням і змінами, якщо має відповідні інструменти та дозволи. Власний subagent можна налаштувати для повторюваної ролі. Назви вбудованих типів не слід сприймати як універсальний перелік усіх агентів: наявність типу залежить від поточної сесії, версії та налаштувань. [1]
Корисно відокремлювати п’ять подій:
- Призначення задачі. Головний агент вирішив передати роботу та сформував повідомлення для subagent.
- Старт. Середовище знайшло тип агента, застосувало конфігурацію і створило виконавця.
- Виконання. Subagent прочитав доступний контекст, викликав інструменти й отримав їхні фактичні результати.
- Завершення виклику. Інструмент повідомив, що запуск завершився, був зупинений або завершився помилкою.
- Приймання результату. Головний агент перевірив, чи повернені докази достатні для початкової задачі.
Це не одне й те саме. Сам факт, що запит на делегування з’явився в транскрипті, не доводить, що агент стартував. Успішний виклик інструмента створення агента не доводить, що делеговане завдання виконане. А завершення subagent не є автоматичним підтвердженням правильності висновку.
32.2. Межа контексту: що агент знає, а чого не знає
Звичайний, не forked subagent запускається з новим контекстним вікном. Він не бачить попередній діалог головного агента, не знає, які файли той уже читав, і не отримує автоматично кожне проміжне спостереження. Йому передають системну інструкцію конкретного типу, повідомлення з делегованим завданням, дані середовища та ті файли чи інструменти, які він може отримати сам. Виняток — режим fork, який бере попередній діалог як початковий контекст. Його не треба плутати з типовим запуском нового subagent. [1]
У звичайного subagent початкове повідомлення складає Claude Code. Саме тому головний агент має передати достатній контекст: назву й межі задачі, вимогу, важливі висновки, версію чи ревізію коду, джерело істини й критерій завершення. Не варто сподіватися, що новий агент здогадається, на яке речення у минулій розмові посилає «те, що ми щойно обговорили». Якщо критичний контекст не вміщується в prompt, треба назвати конкретний файл, issue або ресурс, який агент має відкрити, і переконатися, що інструмент та доступ є.
У проєктних сесіях subagent зазвичай завантажує ієрархію <code>CLAUDE.md</code> та інші інструкції, які головний діалог завантажив би для цього середовища; вбудовані Explore і Plan мають винятки, а власне поле <code>omitClaudeMd</code> може змінити поведінку. Це інструкції та контекст, а не автоматичне передавання розмови. Повний файл може бути занадто довгим або не містити конкретного факту, відомого тільки з чату. Перевірте, що важливе правило справді застосовне до цієї сесії. [1]
Fork — окрема опція: він починає з копії розмовного контексту головного агента замість нового контексту з повідомленням делегування. Це корисно, коли агенту потрібна широка історія. Але довгий контекст зменшує перевагу ізоляції шуму, може передати зайві дані й не робить fork незалежним спостереженням. У Claude Code команда <code>/subtask</code> створює такий фоновий fork поточної розмови (доступна з v2.1.212); це не назва типу з <code>.claude/agents/</code>. Поле <code>context: fork</code> у Skill — ще один окремий шлях запуску Skill у forked context. Окремі Claude Code-сесії, які обмінюються повідомленнями між сесіями, — теж інший механізм. Fork, subagent, Skill з fork-контекстом і окрема сесія мають різні межі стану та не є синонімами. [1]
Мінімальний контракт делегування
Перш ніж викликати subagent, сформулюйте контракт як коротке технічне завдання:
| Частина | Що варто передати |
|---|---|
| Результат | Відповідь на одне питання, звіт, рекомендацію або зміни у точно названих файлах. |
| Область | Репозиторій і директорії, issue, diff, гілка або компонент, який треба охопити. |
| Виключення | Що не входить у завдання: не редагувати файли, не запускати міграцію, не писати в Jira тощо. |
| Джерело істини | Який критерій, документ чи стан системи має пріоритет; як позначати суперечності. |
| Вхідні дані | Початкова ревізія, точні ключі задач, посилання, доступні журнали, файли та обмеження. |
| Докази | Для кожного висновку: джерело, уривок або координати, умова та рівень невизначеності. |
| Доступ і побічні ефекти | Які інструменти дозволені; чи можна редагувати, запускати shell-команди або торкатися зовнішніх сервісів. |
| Формат відповіді | Наприклад, таблиця «вимога → файл/тест → спостереження → прогалина». |
| Критерій завершення | Які саме питання мають бути закриті, що позначати як невиконане і коли зупинитися. |
Роль на кшталт «ти — експерт із тестування» не замінює контракт. Формулювання «перевір код» не визначає ні межу перевірки, ні вимогу, ні доказ, а «досліди все» заохочує надмірний обсяг. Хороше доручення дозволяє прочитати відповідь і визначити: що перевірено, що ще потрібно і який наслідок має результат.
Для роботи зі змінами корисно розділити два дозволи. Дозвіл досліджувати дає читання визначеної області та запуск безпечних перевірок. Дозвіл змінювати називає конкретні файли й допустимий diff. Записати локальний файл — теж побічний ефект; виконати shell-команду може бути набагато ширшим побічним ефектом. Зміна Jira, надсилання листа, публікація релізу або застосування міграції мають окремі наслідки поза файловою системою. Якщо виконавець не має явно потрібного повноваження, у контракті це треба заборонити.
32.3. Коли subagent корисний, а коли створює зайву роботу
Subagent доречний, коли результат локальний і його можна перевірити окремо: дослідити одну підсистему; просканувати великий каталог і повернути кілька координат; порівняти кілька незалежних джерел; проаналізувати журнали та видати часову шкалу; незалежно перевірити окремі критерії приймання; або виконати роботу з вузько обмеженими інструментами. Він також корисний, коли докладні проміжні результати не потрібні в головному контексті.
Головна розмова зазвичай краща для невеликої зміни, частих уточнень, роботи з одним і тим самим набором контексту, послідовних залежних кроків або ситуації, де важливо бачити загальну картину від початку до кінця. Якщо subagent доведеться постійно перенавчати історії чи передавати по одному новому факту, економія може зникнути. Виклик також має затримку й власні витрати токенів. Anthropic радить використовувати subagents для самодостатньої роботи, великого виводу чи окремих обмежень доступу, а коротку ітераційну задачу лишати в головному діалозі. [1]
Окрема межа: паралельність прискорює лише справді незалежні роботи. Якщо один агент має спершу знайти критерії, а наступний — застосувати їх до конкретного diff, це послідовність. Якщо два агенти змінюють один файл, вони можуть конфліктувати. Задачі краще розбити за файлом, модулем, джерелом або питанням, а не розмножувати виконавців лише заради кількості.
Чим subagent відрізняється від близьких механізмів
| Механізм | Для чого | Як пов’язаний з головним контекстом |
|---|---|---|
| Одноразовий prompt | Одне повідомлення з інструкцією для поточного ходу | Виконується в основній розмові, якщо host не запустить його інакше. |
| Subagent | Делегована, обмежена частина роботи у тій самій сесії Claude Code | Звичайний запуск має нове контекстне вікно та повертає результат тому, хто його викликав. |
| Skill | Перевикористовувані інструкції, довідки чи процедура для типу задач | У Claude Code може завантажитися в головний контекст або запускатися як fork/subagent за відповідною конфігурацією. Сам Skill не є іншим виконавцем за замовчуванням. |
| Окрема сесія / cross-session messaging | Інша самостійна Claude Code-розмова, яка може обмінюватися повідомленнями з іншими сесіями за підтримуваного налаштування | Має власне життя сесії; це не короткий дочірній виклик у поточному дереві. |
| Agent team | Кілька сесій Claude Code, які координуються як команда | Учасники мають власні контексти, можуть писати один одному та використовують спільний список задач. |
| Інструмент або MCP (Model Context Protocol, протокол контексту моделі) | Конкретна машинна дія чи інтеграція із зовнішніми даними | Може бути викликаний головним агентом або subagent, якщо доступний і дозволений. |
Agent team — це не просто назва групи subagents. Команда координує окремі сесії через повідомлення та спільний список задач; subagents у звичайному випадку повертають результати головному агенту, який розподіляє і зводить роботу. Команди мають більше накладних витрат і використовують більше токенів; вони краще підходять для незалежних частин великої роботи, а не для послідовних кроків чи правок одного файла. У документації Claude Code agent teams позначені як експериментальна можливість і вимкнені за замовчуванням; поточний спосіб увімкнення та обмеження треба перевіряти в офіційній довідці. Документація окремо описує agent teams і cross-session messaging. [2]
Skill теж не є «агентом зі знаннями». Наприклад, Skill може зберігати повторюваний чекліст огляду, а subagent — за цим чеклістом дослідити конкретний модуль і повернути стислий звіт. Тіло Skill саме по собі не створює інструмент, доступ чи ізольоване робоче середовище. Claude Code може запускати Skill у власному контексті subagent, але це окремо налаштована можливість, не властивість кожного Skill. [1]
В актуальній документації назва інструмента делегування змінена: Task став Agent у Claude Code v2.1.63; старі посилання <code>Task(...)</code> у налаштуваннях і визначеннях лишилися сумісним псевдонімом. Якщо документація, запис сесії та інтерфейс називають операцію по-різному, перевіряйте версію, а не робіть висновок, що це обов’язково різні можливості. [1]
32.4. Конфігурація Claude Code: що описує файл агента
Власний subagent визначають файлом Markdown із YAML (YAML Ain’t Markup Language — формат серіалізації даних) frontmatter — блоком налаштувань між рядками <code>---</code> — і тілом Markdown, що є системною інструкцією цього subagent. Проєктні визначення зберігаються у <code>.claude/agents/</code>; особисті — у <code>~/.claude/agents/</code>. Є також керовані, плагінні й одноразові визначення через CLI (Command-Line Interface, інтерфейс командного рядка). Розташування визначає сферу дії та пріоритет, а поле <code>name</code> дає ідентифікатор. <code>name</code> і <code>description</code> є обов’язковими для файлового визначення; невідомі поля frontmatter можуть бути проігноровані без помилки, тому друкарська помилка в ключі небезпечна тим, що очікуване обмеження не спрацює. [1]
Виклик може бути автоматичним: Claude орієнтується на формулювання задачі, опис subagent та контекст. Можна назвати тип у природному запиті, написати його як @-mention, попросити головний агент викликати Agent tool із конкретним типом або зробити саму сесію subagent через <code>--agent</code> чи налаштування <code>agent</code>. Природна згадка лише підказує, а явний @-mention призначає тип для одного завдання; вона не визначає весь prompt, який головний агент складе для нього. Сесійний <code>--agent</code> змінює роль головного потоку цієї сесії — це не дочірній виклик. [1]
У назві типу нижче мається на увазі інтерфейс програмування застосунків (Application Programming Interface, API). У спрощеному вигляді файл може виглядати так:
---
name: api-contract-reader
description: Порівнює зміни API з указаним контрактом; не редагує файли.
tools: Read, Grep, Glob
model: sonnet
maxTurns: 12
---
Знайди зміни контракту в заданому модулі. Для кожного відхилення
наведи шлях, рядок, очікуване правило та фактичний код.
Не запускай shell, не редагуй файли й не змінюй зовнішній стан.
Якщо контракт або потрібний шлях відсутній, назви прогалину.
Це приклад конфігурації, а не гарантія того, що у конкретній інсталяції назва моделі, доступні інструменти або обмеження відповідають прикладу. Текст тіла дає інструкції. Рішення, які інструменти чи дії фактично доступні, визначають поля конфігурації та політика Claude Code.
Основні поля, підтримувані актуальною документацією [1]:
| Поле | Що воно задає | Межа |
|---|---|---|
| <code>name</code> | Ідентифікатор типу subagent | Має бути унікальним у доступних конфігураціях; файл може мати іншу назву. |
| <code>description</code> | Коли Claude має обрати цей тип | Допомагає делегуванню, але не гарантує виклику на кожній відповідній задачі. |
| <code>tools</code> | Дозволений перелік доступних інструментів | Якщо поле відсутнє, subagent успадковує інструменти, доступні subagents. Успадкування ширше, ніж мінімальний безпечний доступ. |
| <code>disallowedTools</code> | Інструменти, які треба прибрати зі списку | Не замінює окремі правила команд shell чи зовнішній sandbox. |
| <code>model</code> | Модель або правило вибору моделі | Наприклад, <code>sonnet</code>, <code>opus</code>, <code>haiku</code>, <code>fable</code>, повний ідентифікатор чи <code>inherit</code>; доступність і вибір залежать від середовища та іншої конфігурації. |
| <code>permissionMode</code> | Режим дозволів для subagent | Включає документовані режими <code>default</code>, <code>acceptEdits</code>, <code>auto</code>, <code>dontAsk</code>, <code>bypassPermissions</code>, <code>plan</code>; <code>manual</code> є псевдонімом <code>default</code> у версіях від v2.1.200. Якщо головна сесія в <code>bypassPermissions</code>, <code>acceptEdits</code> або <code>auto</code>, subagent запускається в її режимі й поле ігнорується. Для <code>default</code>, <code>dontAsk</code> чи <code>plan</code> використовується режим з визначення, але subagent не може самостійно перейти у <code>bypassPermissions</code>; його виняток потребує v2.1.267+. [1] |
| <code>maxTurns</code> | Граничну кількість agentic turns | При досягненні ліміту може повернутися частковий результат; це не гарантія, що задача завершена. |
| <code>skills</code> | Skills, повний текст яких передзавантажується | Звичайне перелічення Skill серед інструментів не означає такого самого передзавантаження. |
| <code>mcpServers</code> | MCP-сервери для subagent | Можна послатися на налаштований сервер або описати сервер; це створює або надає можливий шлях до зовнішніх дій. |
| <code>hooks</code> | Подієві правила на час роботи цього subagent | Це виконувані налаштування; треба розуміти, які події вони контролюють. |
| <code>memory</code> | Персональну, проєктну або локальну довготривалу пам’ять | Пам’ять зберігається між розмовами й може оновлювати файли; це окремий стан, а не історія поточного завдання. |
| <code>background</code> | Перевагу запуску у фоні | Фоновий режим впливає на момент повернення результату й показ дозволів, а не означає ізоляцію від файлів. |
| <code>omitClaudeMd</code> | Чи пропускати деякі проєктні інструкції | Специфічна доступність залежить від версії та типу визначення. |
| <code>initialPrompt</code> | Початкову репліку для агента, коли його визначення запускають як головного агента через <code>--agent</code> або налаштування <code>agent</code> | Не є заміною prompt тіла subagent; для plugin subagents ігнорується. |
| <code>effort</code> | Рівень зусиль моделі для відповідного типу | Допустимі значення залежать від моделі та версії. |
| <code>autoCompactWindow</code> | Раніше автоматично стискати контекст цього субагента, ніж контекст основної розмови | Доступно з v2.1.296; зменшує обсяг контексту, але не гарантує збереження всіх проміжних деталей у подальшому зведенні. |
| <code>isolation</code> | Для shell/PowerShell — тимчасовий Git worktree | Не є повною пісочницею чи мережевою ізоляцією. |
| <code>color</code> | Колір позначення у списку задач і транскрипті | Візуальна ознака не впливає на доступи. |
| <code>experimental</code> | Карту експериментальних опцій; у поточній документації її описане застосування — <code>cacheTtl: 5m</code> або <code>1h</code> для строку кешування prompt | Потрібна версія від v2.1.248; <code>1h</code> ігнорується під час використання usage credits у підписці Claude, інші невідомі значення також ігноруються. Це мінлива функція, а не стабільне універсальне поле. [1] |
Прапорець <code>--agents</code> командного рядка може визначити subagents у JSON (JavaScript Object Notation, текстовому форматі обміну структурованими даними) лише для поточної сесії. Там інструкцію передають полем <code>prompt</code>, а не тілом окремого файла; доступні поля можуть дещо відрізнятися. Не переносіть приклад з CLI у файловий frontmatter без перевірки відповідного розділу документації. Визначення в <code>.claude/agents/</code> призначене для проєкту й може зберігатися в Git, щоб його бачили колеги. [1]
Документація описує, що визначення зазвичай оновлюються під час сесії, але є випадки, коли новостворений каталог агентів або доданий через <code>--add-dir</code> шлях треба перечитати після перезапуску. Водночас є GitHub issue від 7 серпня 2026 року про те, що файл <code>.claude/agents/architect.md</code> у Claude Code 2.1.222 на macOS не був одразу видимий Agent tool і з’явився через кілька хвилин. На 10 жовтня 2026 року GitHub показує issue як закритий із причиною «not planned» та позначкою про неактивність; це адміністративне закриття не підтверджує, що описану поведінку виправили. Це одиничне повідомлення, а не підтвердження універсальної поведінки; воно показує, чому треба перевірити, що тип агента справді доступний, перед тим як припускати, що його обмеження вже застосовуються. Автор застерігає: резервне делегування загальному типу з charter у prompt не переносить на нього allowlist інструментів невиявленого агента. Не підставляйте ширший тип і не вважайте, що текст charter обмежує його інструменти. [1, 5]
Команда <code>/agents</code> у Claude Code v2.1.198 і новіших уже не відкриває старий інтерактивний редактор/майстер: вона нагадує попросити Claude створити визначення або відредагувати файл. Це корисне версійне уточнення для інструкцій, які досі обіцяють майстер налаштування. [1]
32.5. Інструменти, дозволи, пам’ять і справжня межа ізоляції
За замовчуванням subagents можуть успадковувати вбудовані та MCP-інструменти головної розмови, після чого деякі інструменти відсіюються залежно від типу чи фонового запуску. Власний список <code>tools</code> є allowlist — переліком того, що лишається доступним; <code>disallowedTools</code> прибирає інструменти. Якщо треба лише прочитати код, перелічіть потрібні інструменти читання (наприклад, Read, Grep і Glob) і не додавайте Bash, Write чи Edit без причини. Не припускайте, що відсутність явного дозволу в тілі prompt позбавляє агента інструмента: якщо <code>tools</code> не зазначено, він може успадкувати широкий набір. [1]
Інструмент <code>Bash</code> означає можливість запускати команди, а не лише «читати результат тесту». Shell може змінювати файли, виконувати програми, читати змінні середовища, спілкуватися з мережею або користуватися доступними credential. Текстове прохання «нічого не змінювати» — корисна інструкція, але не технічна межа. Навіть шаблон дозволу на конкретну команду може мати пропуски для її варіантів. Anthropic прямо застерігає, що WebFetch-дозвіл сам собою не блокує мережу для <code>curl</code> чи інших програм, якщо Bash доступний. Для вимог із безпеки потрібні інструментальні allowlist/denylist, правила дозволів, hooks та відповідне sandboxing, а не лише надія на prompt. [3]
Права інтеграцій — окрема межа. Якщо subagent має MCP-інструмент Jira, GitHub або бази даних, то його можливості визначає інструмент і підключені credentials. «Нехай тільки читає» треба закріпити доступним read-only варіантом інструмента чи політикою авторизації, а не лише описом ролі. Під час перевірки конфігурації враховуйте, що прикріплений сервер може бути доступний тільки на час роботи агента, але видимість даних або виконаний запис можуть залишитися у зовнішньому сервісі після завершення сесії.
Є ще важливий розрив: контекст не є файловою системою. Коли subagent працює у тому самому checkout, зміна файлу стає спільною зі станом головної сесії. Два паралельні агенти можуть перезаписати файл або побачити частково завершену зміну. Для полегшення конкуренції Claude Code має <code>isolation: worktree</code>: shell/PowerShell subagent запускається у тимчасовому Git worktree. Документація вказує, що він за замовчуванням відгалужується від default branch, а не обов’язково від поточного <code>HEAD</code> головної сесії; worktree автоматично видаляється, якщо агент не залишив змін. Перед використанням перевірте базову ревізію та спосіб збирання результату. Такий worktree ізолює робочу копію Git, але не перетворює середовище на повний sandbox і не блокує мережу чи зовнішні системи. [1, 8]
Пам’ять subagent — інший тип стану. Поле <code>memory</code> вмикає папку пам’яті з обсягом <code>user</code>, <code>project</code> або <code>local</code>. Перші 200 рядків або 25 КБ <code>MEMORY.md</code> (що настане раніше) можуть підвантажуватися при наступних запусках агента, а сам subagent отримує змогу читати та редагувати файли пам’яті. Цей стан переживає поточну делегацію; проєктна пам’ять може потрапити до контролю версій. Тому її треба вважати змінними даними, які мають походження й можуть бути застарілими або небажаними, а не істиною системи. Документація відрізняє auto memory від <code>CLAUDE.md</code>: перше накопичує вивчені шаблони, друге містить задані людиною правила. Обидва потрапляють у контекст, але самі собою не забезпечують примусове виконання. [4]
Перш ніж дати subagent доступ до файлів або інструментів, перевірте:
- Межу даних: які частини коду, репозиторіїв, вкладень та пам’яті він може прочитати?
- Межу запису: у який checkout, worktree або зовнішній сервіс він може записати?
- Мережу: чи може він звернутися до довільного сайту, чи лише до явно дозволених сервісів?
- Секрети: чи може інструмент прочитати змінні середовища, токени, ключі для Secure Shell (SSH — захищена оболонка), файли конфігурації або журнали з персональними даними?
- Побічні ефекти: чи може він створити/закрити issue, залишити коментар, push-нути branch, запустити міграцію або надіслати повідомлення?
- Збереження стану: що лишиться після закриття сесії — git diff, пам’ять, shell-процес, повідомлення або запис у сервісі?
У робочій практиці часто безпечніше делегувати прочитати й проаналізувати з явною забороною змін, а потрібний diff виконувати окремо у визначеній області. Якщо ж агенту потрібна правка, назвіть її файли та умови; після неї порівняйте фактичний diff із контрактом. Великі системні дії краще вимагати через окремий дозвіл або контроль поза моделлю.
32.6. Завершення, зведення доказів і невдачі
Коли робота закінчилась, головний агент отримує звіт subagent, а для підтримуваних запусків — ідентифікатор (від англ. identifier, скорочено ID), який дозволяє продовжити роботу. Деякі вбудовані агенти, наприклад Explore і Plan, можуть бути одноразовими й не мати ID для продовження. Якщо досягнуто <code>maxTurns</code>, Claude Code може позначити відповідь як часткову й дозволити продовження через повідомлення агенту. Перевіряйте ознаку partial; не перетворюйте «досягнуто ліміт» на «готово». [1]
Фоновий запуск — це спосіб продовжувати роботу, поки основна розмова займається іншим. За поточним описом документації дозволи фонового subagent можуть показуватися у головній сесії, а інструментарій фону відрізняється від foreground. Ця поведінка залежить від режиму fork, налаштувань сесії та запуску. «Віддав у фон» означає лише, що робота ще може тривати, а не що результат уже готовий. Перевірте рядок задач або фактичне повідомлення завершення у доступному інтерфейсі. [1]
Якщо виклик повернув тайм-аут, мережеву помилку або помилку API (Application Programming Interface, програмного інтерфейсу застосунку), обмеження витрат, переривання або порожній результат, статус треба позначити невідомим або неповним, доки не буде доказу завершення. Порожня відповідь не свідчить, що агент нічого не змінив: зовнішня операція могла завершитися, а відповідь загубитися. Перед повторенням перевірте файловий diff чи стан зовнішньої системи, щоб уникнути дубльованого запису. Якщо субагент має ідентифікатор і його контекст ще доступний, продовження може бути кращим за повторну роботу; якщо повтор неминучий, використовуйте ідемпотентний спосіб там, де система його підтримує.
Для кожного subagent у підсумку зручно вести таблицю:
| Поле | Питання |
|---|---|
| Статус | Виконав, завершив частково, помилився, перерваний чи ще працює? |
| Питання | Яку конкретну частину початкового завдання перевіряв? |
| Докази | Які файли, рядки, логи, посилання, результати тесту чи записи він фактично прочитав? |
| Висновок | Що стверджує; до якого обсягу це твердження стосується? |
| Невідоме | Чого бракувало, де джерела суперечили або що не вдалося перевірити? |
| Побічний ефект | Що було змінено в робочій копії або зовнішній системі? |
| Приймання | Чи перевірив головний агент ключову знахідку та початковий критерій? |
Закритий виклик означає лише, що інструмент перестав виконуватися. Завершене завдання означає, що потрібний обсяг перевірено, докази достатні, результат відповідає контракту, а побічні ефекти відомі. Саме головний агент відповідає за друге.
Якщо два агенти не погоджуються, не варто механічно обирати відповідь більш впевненого. Порівняйте їхні джерела й умови: один міг прочитати стару гілку, інший — неправильний тестовий файл; один висновок може стосуватися тільки конкретного прикладу. Повторно прочитайте джерело істини. Якщо розбіжність лишається, у підсумку наведіть обидві версії, докази й те, що треба уточнити. Відсутність спільного висновку є результатом, який треба зберегти, а не приховати.
Кілька subagents не означають кілька незалежних доказів. Вони можуть отримати однакове завдання, користуватися тим самим документом, тією самою моделлю, тим самим набором інструментів чи успадкованими попередніми припущеннями. Якщо три виконавці переказали одне джерело, це одне джерело з трьома переказами. Незалежність зростає, коли питання справді різні, джерела розділені, а умови перевірки сформульовані окремо. Навіть тоді висновок треба перевірити проти первинного артефакту.
Публічний звіт про проблему як урок надійності
У репозиторії <code>anthropics/claude-code</code> опубліковано issue #84927: автор повідомив, що створене визначення <code>.claude/agents/architect.md</code> не відразу з’явилося в Agent tool у Claude Code 2.1.222 на macOS 26.5.2. Через кілька хвилин агент став доступний; GitHub закрив його як «not planned» 5 жовтня після періоду неактивності; підтвердженого виправлення в issue немає. Це опис одного відтворення, не гарантія, що поточна версія завжди поводиться так. Практичний висновок для делегування: перед використанням вузького типу переконайтеся, що обране саме воно. Автор описує, що як тимчасову заміну спробували загальний агент із charter у prompt; однак обмеження поля <code>tools</code> з невикористаного визначення не переноситься на резервний тип. Prompt із роллю «тільки читання» не замінює фактичний allowlist інструментів. [1, 5]
32.7. Повний приклад: read-only пошук точок виклику API
Випадок повністю вигаданий. У прикладі наведені шляхи, рядки та commit із навчального репозиторію; вони не описують реальний сервіс.
Запит координатора. Умовний сервіс готується до заміни маршруту анулювання рахунка. Координатор просить встановити, де саме код викликає POST /v2/invoices/{invoice_id}/void, чи є виклики через клієнтську обгортку, та що треба перевірити перед рішенням про міграцію. Вихідна ревізія — вигаданий commit 7f3a91c.
Контракт subagent.
Мета: скласти read-only перелік викликів POST /v2/invoices/{invoice_id}/void.
Перевір тільки ревізію 7f3a91c і шляхи src/billing/, src/jobs/ та
src/admin/. Дозволено: читати файли й шукати текст та символи в цих
каталогах. Заборонено: запускати shell або тести, редагувати файли,
перевіряти інші гілки, надсилати запити до сервісу чи змінювати зовнішній
стан. Для кожного збігу наведи шлях, рядок, викликаний метод або обгортку
та короткий фрагмент доказу. Відрізни точний маршрут від схожого.
На завершення назви одну найбезпечнішу наступну перевірку й поясни чому;
не пропонуй зміну коду, доки координатор не підтвердить повноту інвентарю.
Таке обмеження можна частково зафіксувати у frontmatter визначення subagent:
---
name: route-inventory
description: Find API route call sites and report file-level evidence.
tools: Read, Grep, Glob
---
За поточною документацією Claude Code поле tools працює як allowlist: цьому агенту доступні названі інструменти читання й пошуку, але не Bash, Edit, Write чи інструменти MCP, яких немає у списку. Такий список обмежує тип доступних дій, але не закріплює дозволені шляхи src/billing/, src/jobs/ і src/admin/. У прикладі це межа, задана контрактом. Якщо потрібна технічно примусова межа каталогів, її слід забезпечити окремими правилами дозволів або ізоляцією середовища. Сам текст контракту також не був би технічною забороною, якби агент мав доступ до небезпечнішого інструмента. [1]
Докази у вигаданому checkout. Агент повертає три окремі спостереження:
| Місце | Спостереження | Чому воно важливе |
|---|---|---|
src/billing/invoices.ts:44 |
billingClient.post(/v2/invoices/${id}/void, body) — точний маршрут через спільний клієнт. |
Це прямий виклик, але він може не бути єдиним входом. |
src/jobs/retry-void.ts:71 |
voidInvoice(invoiceId, reason) викликає обгортку з src/billing/invoices.ts; job повторює її після тимчасової помилки. |
Треба врахувати повтори та поведінку клієнта під час міграції. |
src/admin/refund.ts:29 |
billingClient.post(/v2/invoices/${id}/refund, body) — інший маршрут. |
Схожа назва не робить повернення коштів анулюванням рахунка. |
Цей інвентар обмежений названими каталогами й ревізією. Він не доводить, що інших викликів немає в тестових fixture-файлах, згенерованому коді, інших сервісах чи конфігурації. Звіт також не підтверджує поведінку віддаленого API і не вважає один текстовий збіг доказом виконання в production.
Рішення про наступну дію. Координатор звіряє, що всі три посилання належать до commit 7f3a91c, відкриває викликану обгортку й перевіряє лише її локальну семантику: чи безпечний повтор запиту та чи не приховує клієнт інший маршрут. Він доручає це як наступну вузьку read-only перевірку, бо retry-void.ts виявився непрямим шляхом, який можна пропустити при перегляді лише прямого виклику. Зміни API або коду ще не пропонуються: спочатку треба визначити всі точки використання й вимоги до повтору.
Підсумок. Координатор повертає короткий список із двох точок, що ведуть до анулювання, одного схожого, але відмінного маршруту, меж перевірки та наступного безпечного кроку. Це завершене рішення для дослідницького етапу, а не дозвіл на зміну контракту.
32.8. Повний приклад: три окремі Jira-вимоги перед релізом
Усі ключі та дані в прикладі вигадані. Вони демонструють формат роботи, а не посилаються на реальні задачі чи критерії курсу.
Ситуація. Команда готує оновлення навчальної платформи. Є три задачі Jira, і перед плануванням потрібна лише перевірка готовності:
- <code>DEMO-COURSE-41</code>: кожна опублікована сторінка уроку має відображати заголовок і текст на вузькому екрані.
- <code>DEMO-COURSE-42</code>: повторне натискання «Надіслати» не має створювати дубльоване повідомлення.
- <code>DEMO-COURSE-43</code>: редактор може відновити чернетку після перезавантаження сторінки.
Умовні acceptance criteria наведено повністю, щоб subagent не мусив вгадувати зміст. У реальній сесії головний агент спершу прочитав би три визначені issue через доступний read-only Jira-конектор, перевірив би їхні ключі та останнє оновлення, а тоді передав би агентам точний текст і посилання на файли. Якщо конектор не повернув задачу або показав суперечність, робота за нею не почалася б.
Проблема. Один великий запит «перевір Jira» може звести в один висновок незалежні вимоги. Також легко переплутати «немає знайденого тесту» з «система точно не підтримує поведінку», або дозволити агенту непомітно змінити статус у Jira.
Альтернативи. Головний агент міг би послідовно прочитати код і всі три критерії в одному контексті. Це доречно, якщо модулі тісно пов’язані. Тут вимоги стосуються різних компонентів, а перший етап лише дослідницький, тому можна доручити три незалежні read-only перевірки. Окремий agent team був би зайвим: координатор має зібрати просту матрицю, а учасникам не треба спілкуватися між собою. Власний постійний subagent теж не обов’язковий для одноразової задачі; достатньо чіткого prompt і правильного типу.
Контракт для кожного з трьох subagents.
Мета: перевірити одну вимогу Jira для релізного планування.
Джерело вимоги: наведений нижче повний текст acceptance criteria та
посилання на DEMO-COURSE-41 / DEMO-COURSE-42 / DEMO-COURSE-43.
Перевіряй лише названу вимогу у поточному commit <ідентифікатор>.
Дозволено: читати вказаний модуль і його тести; запустити явно названий
локальний read-only тест, якщо він уже доступний.
Заборонено: редагувати файли, створювати commit, змінювати Jira,
коментувати чи переходити до задачі іншого агента.
Поверни: (а) виконання: підтверджено / спростовано / невідомо;
(б) точні шляхи, рядки й тестові докази; (в) неперевірені випадки;
(г) причини невизначеності. Не заявляй про тест, якого не запускав.
Якщо знайдеш взаємозалежність або суперечність, познач її, не розв'язуй
за межами своєї задачі.
Один агент аналізує <code>DEMO-COURSE-41</code> у шаблоні сторінки та адаптивних тестах; другий — <code>DEMO-COURSE-42</code> у handler відправлення й тестах повторного запиту; третій — <code>DEMO-COURSE-43</code> у збереженні чернетки та відновленні стану. Кожен отримує однакове правило щодо стану Jira, але свою вимогу й область файлів. Налаштування інструментів лишають лише читання, пошук і названу безпечну перевірку. Доступ до запису Jira не потрібний для дослідницького звіту.
Зіставлення. Умовні результати можуть виглядати так:
| Jira | Результат subagent | Підстави | Що лишається невідомим |
|---|---|---|---|
| <code>DEMO-COURSE-41</code> | Частково підтверджено | Шаблон рендерить заголовок; тест тексту проходить на viewport 360 px. | Тест не перевіряє, що зображення чи довгий код не спричинять горизонтальне прокручування. |
| <code>DEMO-COURSE-42</code> | Є прогалина | Handler перевіряє ідентифікатор запиту; тест покриває послідовний повтор, але не два паралельні запити. | Не досліджено гарантію унікальності в production database. |
| <code>DEMO-COURSE-43</code> | Невідомо | У компоненті знайдено запис чернетки до локального сховища. | Агент не зміг прочитати міграцію сховища, а тестове середовище не має сценарію перезавантаження. |
Зведення головним агентом. Координатор не має перетворити три рядки на «все готове». Він перевіряє, чи посилається кожен звіт на той самий commit і на фактичні файли; чи точна це задача Jira; чи не підмінено доказ здогадом; чи не приховує один агент критичну прогалину. Стан першої вимоги не закриває прогалини другої, а відмова в доступі до тесту третьої не доводить ні наявності, ні відсутності функції.
Результат. Головний агент готує read-only матрицю з трьома різними статусами: одна вимога частково підтверджена, друга має неперевірений конкурентний випадок, третя лишається невідомою через відсутність доказу. Він не змінює Jira і не називає реліз готовим. Власник може окремо вирішити, що саме потрібно доробити чи перевірити.
Чому це рішення підходить. Критерії незалежні настільки, щоб їх можна було читати паралельно; кожна перевірка невелика й має власні джерела. Обмеження інструментів відповідають ризику: завдання вимагає аналізу, не запису. Формат результату полегшує головному агенту зібрати findings, не поглинувши весь проміжний вивід у головну розмову.
Межі. Приклад не показує реальний продукт, справжні ключі Jira, виконаний тест або реальну інтеграцію. Навіть розділення на три виконавці не гарантує незалежних висновків, якщо вони прочитали спільний застарілий код або один і той самий хибний текст вимоги. Перед ухваленням рішення потрібно підтвердити актуальність Jira, commit і test output.
32.9. Повний приклад: причина помилки ще не доведена
Ситуація. Після розгортання умовного сервісу частина запитів завершується помилкою «session expired». Команда має журнали за годину інциденту, карту залежностей і кілька правдоподібних теорій: несправний кеш, різкий перекіс годинників, або зміна перевірки токена. Усі приклади нижче вигадані.
Проблема. Якщо дати одній моделі широкий запит «знайди причину й виправ», вона може зафіксуватися на першій гіпотезі, внести зміну до спільної гілки й оголосити інцидент закритим до перевірки. У цій фазі потрібне порівняння пояснень, а не запис у production.
Альтернативи. Ремонт не треба делегувати кільком авторам одночасно: перш ніж міняти код, потрібне встановлення факту. У головному діалозі можна послідовно перевірити кожну теорію, якщо даних небагато. Якщо журнали та шляхи коду об’ємні, доречні три вузькі read-only субзавдання: кожне перевіряє одну гіпотезу й передає конкретні часові позначки, рядки та альтернативи.
Дія. Головний агент формулює запит однаково для трьох різних питань: «Перевір гіпотезу X на часовій шкалі <час і сервіс>. Прочитай тільки названі журнали та файли. Не змінюй checkout, не запускай мережеві команди та не торкайся середовища розгортання. Укажи події, які підтверджують і послаблюють гіпотезу; наведи timestamp, джерело й точну цитату або координати. Не роби висновку за межами перевірених даних». Інструменти читання обмежують доступ; Bash, пишучі інструменти та MCP інцидентного середовища не надаються.
Дослідник кешу знаходить, що затримки зросли на тому самому інтервалі, але не бачить, що cache miss передує помилці авторизації. Дослідник часу знаходить розбіжність приблизно в одну хвилину на двох вузлах, однак часові позначки журналів з різних систем збережені у різних часових зонах. Дослідник токена знаходить зміну перевірки у поточному commit, але тестовий журнал не повідомляє, який варіант налаштування мав саме проблемний клієнт.
Зведення. Координатор зводить часову лінію лише після нормалізації часових поясів, зберігає посилання на первинні джерела, розрізняє спостереження й гіпотези, відмічає, що підтверджує чи послаблює кожну версію. Умовно він визначає, що токенова перевірка має сильний кореляційний сигнал, але бракує конфігурації клієнта; це не ще доказ причини. Три субагенти не «голосують» за винуватця, бо вони досліджували різні гіпотези, а не незалежно перевіряли той самий експеримент.
Результат. У звіті є найкраще наступне безпечне спостереження — отримати маскований варіант налаштування клієнта й перевірити точний шлях його запиту у відтворюваному середовищі. Не було змінено production, коду, секретів чи доступів. Завдання «пояснити інцидент» лишається частково відкритим, хоча три виклики subagent завершилися.
Чому це рішення підходить. Великі журнали й різні модулі дали б забагато шуму в основному контексті; питання можна було сформулювати ізольовано; ризик масового запису був високим. Паралельні читачі допомогли швидко зіставити незалежні джерела й зберегти обмеження кожного висновку.
Межі. Паралельність не замінює нормалізацію часу або повноту логування. Доступ до прихованих чи видалених логів не виникне від самого делегування. Знайдений commit не доводить причинність. Якщо наступна перевірка включає зміни або взаємодію із production, це новий контракт, інші доступи й окремі правила схвалення.
32.10. Повний приклад: рецензент знаходить втрату даних у міграції
Випадок повністю вигаданий. Він показує, як розділити реалізацію і незалежну перевірку, а не описує реальну базу даних.
Контекст та інваріант. Команда переносить accounts.external_ref у таблицю account_identifiers. За вимогою, кожне посилання облікового запису має зберігатися протягом 90 днів після soft delete, бо протягом цього строку обліковий запис можна відновити. Інваріант міграції: для кожного такого облікового запису після перенесення лишається те саме зовнішнє посилання. Запропонаний запит структурованою мовою запитів (Structured Query Language, SQL) для backfill відбирає лише рядки з deleted_at IS NULL, після чого стара колонка видаляється.
Розподіл ролей. Виконавець змін (implementer) отримує право змінювати тільки файл міграції та її тести у своїй гілці. Рецензент (reviewer) працює read-only з тієї самої базової ревізії; йому передають інваріант, SQL міграції та тестові дані. Він не змінює код і не підключається до production. Обидва звітують із точними доказами, а не лише з висновком.
Розбіжність. Рецензент повідомляє про втрату даних. Виконавець заперечує: «рядки з датою видалення більше не активні, їх не треба переносити». Координатор не обирає між упевненими відповідями: перевіряє вимогу про відновлення та поведінку endpoint відновлення, який читає зовнішній ідентифікатор.
Контрприклад і доказ. У вигаданому тестовому знімку є рядок acct-17, external_ref = partner-004, deleted_at = 2026-09-10. На дату міграції він ще в межах 90 днів. До backfill рядок існує; після виконання запиту в ізольованій копії для acct-17 немає рядка в account_identifiers. Тест відновлення цього запису тоді повертає порожнє зовнішнє посилання. Це конкретно порушує інваріант; слово «видалений» не скасовує задокументованого строку відновлення.
Рішення та людська точка контролю. Виконавець визнає контрприклад і змінює backfill так, щоб перенести всі рядки в межах строку відновлення; додає тест для активного запису та soft-deleted запису. Рецензент повторює перевірку на тому самому знімку, підтверджує обидва перенесені значення й позначає знахідку як усунену. Координатор готує виправлену міграцію до запиту на злиття (pull request, PR), але не запускає її на production. Перед застосуванням відповідальна людина — власник даних або адміністратор бази даних — має окремо підтвердити правило збереження, резервну копію, план відкату й вікно запуску. У цьому навчальному випадку власник даних підтверджує 90-денний інваріант; production-запуск лишається заблокованим до перевірки резервної копії та відкату.
Результат. Рецензентське заперечення розв’язано тестованим контрприкладом і вимогою, а не голосуванням агентів. Код може пройти людське рев’ю для PR; рішення про застосування міграції лишається за відповідальною людиною.
32.11. Повний приклад: конфлікт двох змін одного файла
Випадок повністю вигаданий. Два subagents мають окремі контекстні вікна й окремі worktrees, створені від одного commit C0, але обидва отримали дозвіл редагувати chapters/32-claude-subagents.md.
Що сталося. Перший агент переписує абзац про спільний стан файлів, щоб додати попередження про частково записану зміну. Другий, не бачачи першого агента й його worktree, переписує той самий абзац для прикладу про межі worktree. Кожен бачить лише C0 і вважає свій фрагмент єдиною актуальною версією. Коли координатор застосовує обидві зміни до інтеграційної гілки, Git позначає той самий рядковий фрагмент як конфліктний; окремі контексти не синхронізували файли. Якби один агент натомість зберіг цілий застарілий знімок поверх спільного checkout, його запис міг би стерти правку іншого.
Доказ і зупинка. Координатор не приймає варіант «останній запис перемагає». Він зупиняє злиття, зберігає обидва патчі, перевіряє, що вони походять від C0, і порівнює конфліктний фрагмент з початковими завданнями. Так видно, які твердження кожен агент хотів додати та чи не загубився інший зміст.
Перепланування, контрольна точка та результат. Відтепер один автор відповідає за весь файл; другий стає read-only рецензентом і повертає пропозиції з точними місцями, без паралельного запису. Автор у виділеному worktree інтегрує обидві потрібні думки, перевіряє diff від C0 після зміни абзацу й зберігає окрему контрольну точку перед наступною правкою. Рецензент звіряє фінальний diff з обома задачами; координатор перевіряє, що обидва твердження залишилися, а конфліктних маркерів і випадково втраченого тексту немає. У цьому прикладі diff перевірено й інтеграція готова до людського рев’ю; лише відповідальна людина вирішує, чи зливати її в основну гілку. Для наступної паралельної роботи власник файла призначається наперед, а окремим агентам даються read-only перевірки або файли без перетину.
32.12. Витрати, тайм-аути й ризик неповного результату
Subagent має власну роботу й контекст, але споживає загальні ресурси сесії та моделі. Паралельні запуски можуть зменшити календарний час лише тоді, коли не залежать один від одного. Вони збільшують сумарний обсяг читання, викликів інструментів, повернутих звітів і токенів. Чим більше агентів повертають докладний текст, тим більше головному агенту потрібно прочитати й перевірити. Короткий формат звіту й чіткі межі — спосіб контролювати витрати, а не економічний бонус, автоматично гарантований архітектурою.
Як конкретний приклад, у репозиторії <code>anthropics/claude-code</code> є GitHub issue #78231 від 16 липня 2026 року: автор описав середовище Cowork на Windows і чотири одночасні subagents, які, за його повідомленням, були завершені під час досягнення ліміту витрат; натомість повернули короткі фрагментарні рядки. На сторінці issue вказана версія Claude 1.21459.0, issue позначено закритим як «not planned». Це користувацьке повідомлення, не підтверджений загальний дефект або доказ того, що всі поточні версії втрачають результати таким способом. Воно показує практичний ризик: якщо зовнішній ліміт обриває паралельну роботу, не варто автоматично зараховувати невидимий прогрес. Перевірте фактичний стан і повторіть тільки те, що потрібно. [6]
Під час планування врахуйте:
- Час створення контексту. Новий subagent має перечитати названі джерела; для швидкої відповіді основний контекст може бути оперативнішим.
- Витрати на координатора. Результати потрібно отримати, порівняти, перевірити й оформити.
- Ліміти ходів і глибини. <code>maxTurns</code> може зупинити конкретний агент до завершення; глибина вкладених subagents теж обмежена налаштуванням.
- Конкурентний ліміт. Документація Claude Code вказує типовий ліміт у 20 паралельних subagents для поточного продукту; після досягнення може повернутися помилка. Це межа запуску, а не рекомендація завжди запускати двадцять. [1]
- Мережева чи API-помилка. Агент може отримати частковий текст, помилку або зупинитися з позначкою failed; не витягуйте твердження про успіх із повідомлення про відмову. [1]
- Токенний бюджет і контекст. Коротке завдання й компактний звіт зменшують ризик, що важливі докази потонуть у зайвих проміжних результатах.
- Скасування. Запит зупинити виконання не скасовує вже записану зміну або дію в зовнішньому сервісі; перед повтором перевірте стан.
У документації описано вкладеність до трьох рівнів нижче головної розмови за типовими значеннями, а змінна <code>CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH</code> змінює межу. За вичерпання глибини інструмент Agent може бути недоступний або повертати помилку для fork. Не розраховуйте на необмежене дерево делегування: кожен рівень додає передачу контексту й ускладнює визначення, хто перевірив результат. [1]
32.13. Коротке зіставлення з Codex
У Codex є власна реалізація багатоагентної роботи, але не слід переносити до неї Claude Code конфігурацію <code>.claude/agents/</code>, назви frontmatter або поведінку <code>Agent</code>. В актуальній документації OpenAI для Agents API координатор створює subagents для незалежних завдань, вони мають власний контекст, можуть працювати паралельно, а координатор поєднує результати. У цій конкретній API-конфігурації <code>agent.multi_agent.enabled</code> вмикає оркестрацію, а <code>max_concurrent_subagents</code> задає ліміт; за замовчуванням зазначено шість, не включаючи координатора. Коли агентам потрібні файли чи виконання команд, coordinator та subagents ділять той самий environment filesystem; створення subagent само по собі не створює нове середовище. Наявні інструменти й credentials теж можуть успадковуватися, тому та сама перевірка спільних даних і повноважень потрібна і там. Це порівняння стосується саме документації Agents API (Application Programming Interface, програмного інтерфейсу застосунку) і не описує всі інтерфейси чи конфігурації Codex. Детальні механізми порівнюються в розділі курсу про Codex. [7]
32.14. Евристика для головного агента
Перед делегуванням запитайте себе:
- Чи є у роботи окремий результат, який можна описати та перевірити?
- Який точний контекст треба передати, і як агент знайде його джерело?
- Які дані, файли й сервіси йому справді потрібні?
- Чи безпечно делегувати тільки читання; чи потрібна shell-команда або запис?
- Чи зможуть два агенти конфліктувати у спільному файлі, гілці або зовнішньому стані?
- Які артефакти підтвердять успіх, partial, timeout і відмову?
- Як головний агент зіставить суперечливі результати та перевірить первинні джерела?
- Чи виправдовує економія контексту/часу вартість старту та зведення?
- Яка точка, після якої головний агент не має автоматично продовжувати чи змінювати систему?
Якщо немає чіткої відповіді на ці питання, залиште роботу в головній розмові або спершу уточніть її контракт. Якщо subagent потрібен, делегуйте найменший самодостатній фрагмент роботи. Найсильніша корисна гарантія не в кількості паралельних агентів, а в тому, що кожен отримав потрібний контекст, не більше доступу, ніж потрібно, а головний агент прийняв лише перевірний результат.
Джерела та подальше читання
Мінливі сторінки Claude Code та статус відкритих прикладів перевірено 10 жовтня 2026 року. Це дата доступу до поточного онлайн-вмісту, а не дата публікації чи гарантія, що така поведінка лишатиметься незмінною.
- Anthropic, Create custom subagents — Claude Code Docs, поточна онлайн-документація, доступ 2026-10-10. Використано для типів subagents, конфігурації й frontmatter, межі контексту, інструментів, моделей, пам’яті, hook-ів, робочих копій, виклику, фонового режиму, помилок, лімітів і продовження.
- Anthropic, Orchestrate teams of Claude Code sessions, поточна онлайн-документація, доступ 2026-10-10. Використано лише для різниці між subagents, agent teams та окремими сесіями, повідомленнями, спільним списком задач і накладними витратами.
- Anthropic, Configure permissions — Claude Code Docs, поточна онлайн-документація, доступ 2026-10-10. Використано для дозволів на інструменти й команду, крихкості шаблонів Bash, доступу до файлів і відмінності між текстовою політикою та технічним обмеженням.
- Anthropic, How Claude remembers your project — Claude Code Docs, поточна онлайн-документація, доступ 2026-10-10. Використано для різниці між <code>CLAUDE.md</code> та auto memory, обсягів завантаження і вимоги не вважати текстову пам’ять примусовою політикою.
- <code>anthropics/claude-code</code>, Issue #84927: New subagent definition temporarily unavailable, від 2026-08-07, Claude Code 2.1.222, macOS 26.5.2. GitHub закрив issue як «not planned» 5 жовтня 2026 року через неактивність. Описані затримка доступності визначення та небезпечне розширення доступу при резервному переході на загальний тип лишаються індивідуальним звітом, а не твердженням про всі конфігурації; саме закриття не підтверджує виправлення поведінки.
- <code>anthropics/claude-code</code>, Issue #78231: Subagent output discarded when spend limit terminates fanout, від 2026-07-16, середовище описане як Cowork у Windows; сторінка issue вказує Claude 1.21459.0 і статус «closed as not planned». Це індивідуальний звіт; використовувався тільки як приклад ризику витрат та неповного результату, а не як підтвердження стану поточних інсталяцій.
- OpenAI, Multi-agent — Agents API, поточна документація API, доступ 2026-10-10. Використано для короткого порівняння: координатор, окремі контексти, паралельна робота, максимальна кількість subagents та спільне середовище виконання.
- Anthropic, Configure the sandboxed Bash tool — Claude Code Docs, поточна онлайн-документація, доступ 2026-10-10. Використано для розрізнення Git worktree та sandbox, а також файлових і мережевих меж виконання shell-команд.
- Anthropic, Claude Code releases, перевірено 2026-10-10; найновіший реліз, показаний на сторінці того дня, — v2.1.296 від 2026-10-09. Використано для часової прив’язки мінливих відомостей і версійних меж.