Субагенти Codex: делегування, перевірка та інтеграція

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

Тут ідеться про вбудованих субагентів Codex: що їм передавати, що саме відокремлюється і як перевірити результат. Загальна будова агентів, контекст і передавання роботи розглянуті в главах 23, 24 і 26; тут зосередимося на Codex-специфічних наслідках.

38.1. Хто ставить задачу, хто її виконує і хто відповідає

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

Життєвий цикл можна подати як послідовність:

постановка → запуск → робота → уточнення або очікування → повернений результат → перевірка → інтеграція.

Codex керує запуском субагентів, передаванням уточнень, очікуванням результатів і закриттям потоків. Головний потік може продовжити іншу незалежну роботу, поки діти досліджують свої частини; згодом він отримує зібрані відповіді. У CLI (Command-Line Interface — інтерфейсі командного рядка) команда <code>/agent</code> дає змогу оглянути й переключити потік агента. У настільному застосунку активність показує відповідна панель; у розширенні IDE (Integrated Development Environment — інтегрованого середовища розробки) — коли доступний інтерфейс фонових агентів. Способи перегляду, керування й зупинки залежать від інтерфейсу; не припускайте, що всюди є однакова кнопка або що зупинка батьківського запиту однаково скасовує всі дочірні операції.

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

У звіті дитини важливо розрізняти чотири речі:

1. Доручення надіслано. Це підтверджує лише передачу запиту.
2. Потік активний або завершився. Це стан виконання, а не оцінка правильності.
3. Дитина повернула результат. Це може бути доказ, часткова відповідь, помилка чи тільки підтвердження отримання.
4. Головний агент перевірив результат на цільовому стані. Лише тут з’являється підстава включити його до відповіді або інтегрувати зміни.

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

38.2. Де працюють субагенти Codex і які налаштування документовані

Поточна документація OpenAI розрізняє локальні клієнти Codex, ChatGPT Work і API (Application Programming Interface — програмний інтерфейс). Це не одна універсальна система з однаковими командами, середовищем та числовими обмеженнями. На дату перевірки документація описує субагентні робочі процеси в Codex у настільному застосунку, CLI (Command-Line Interface — інтерфейс командного рядка) та розширенні IDE (Integrated Development Environment — інтегроване середовище розробки). ChatGPT Work надає їх лише відповідним обліковим записам і запускає підлеглих агентів у розміщеному середовищі. Наявність функції залежить від конкретного продукту, його версії та політики робочого простору документація Codex про субагентів.

Поверхня	Що документовано	Чого не слід переносити на іншу поверхню
Codex у настільному застосунку ChatGPT	Можна прямо попросити розбити незалежну частину роботи на субагенти; у застосунку видно потоки й підсумки. Правила проєкту чи Skill також можуть попросити про делегування.	Вигляд панелі чи керування із цієї версії застосунку не є контрактом CLI або API.
Codex CLI	Можна прямо попросити про паралельну роботу; команда <code>/agent</code> відкриває потоки, а головний потік збирає результати. Правила проєкту чи Skill також можуть попросити про делегування.	<code>/agent</code> — команда цього інтерактивного клієнта, а не загальна команда оболонки для будь-якого агента.
Розширення Codex для IDE	Коли доступний інтерфейс фонових агентів, панель показує активні потоки, дає зупинити всі активні запуски й відкрити окремий потік.	Документація не обіцяє однакової кнопки зупинки кожної окремої дитини; інтерфейс Work чи CLI може поводитися інакше.
ChatGPT Work	Доступно відповідним обліковим записам, робота відбувається в розміщеному середовищі. На більшості рівнів інтелекту делегування треба попросити прямо; Ultra може делегувати проактивно.	Не можна вважати, що тут доступні локальне ізольоване середовище Codex, його режими підтвердження чи локальний диск. Інтеграції й дозволи сайтів лишаються окремими.
Codex Cloud	Це окремі хмарні задачі в ізольованому середовищі, а не назва того самого дочірнього потоку в локальному Codex. Документація Codex Cloud	Публічна сторінка не встановлює, чи використовує кожна хмарна задача внутрішніх субагентів. Не приписуйте їм локальну модель керування.
Responses API	Документований режим багатоагентної роботи має власні API-поля, сесію, потоки подій і модель виконання. На сторінці для нього зазначено бета-статус і значення за замовчуванням для <code>max_concurrent_subagents</code>.	Ці поля, обмеження та поведінка не є налаштуваннями локального Codex CLI чи IDE.
Agents API	Інший API-контракт: підлеглі працюють у налаштованому застосунком середовищі, для якого документація задає окремі обмеження.	Їхні імена полів, типове число паралельних агентів і правила спільних файлів не можна прирівнювати до Codex-клієнта або Responses API.

У локальному Codex документоване налаштування <code>agents.enabled</code> має типове значення <code>true</code>. Параметр <code>agents.max_concurrent_threads_per_session</code> обмежує кількість одночасно відкритих потоків підлеглих агентів, не рахуючи головний. Якщо його не задано, Codex сам обирає значення; офіційна документація не публікує універсальне число для всіх клієнтів. Старі конфігурації можуть мати псевдонім <code>agents.max_threads</code>. Число шість у зразку конфігурації є прикладом, не гарантованим типовим значенням.

Модель і зусилля міркування теж можуть різнитися. Модель вибирається з явного параметра запуску, потім із <code>agents.default_subagent_model</code>, а за їхньої відсутності — з налаштування батьківського потоку. Рівень зусиль береться з явного параметра запуску, потім із <code>agents.default_subagent_reasoning_effort</code>. Якщо дитина успадкувала модель і для неї не задано іншого рівня зусиль, вона успадковує рівень батька; якщо ж явний запуск або типове налаштування вибрали іншу модель, а рівень зусиль не вказано, застосовується типовий рівень цієї моделі. Файл спеціального агента може переозначити розв’язані таким чином модель і рівень; інші не задані в ньому налаштування сеансу успадковуються від батька. Вбудовані типи <code>default</code>, <code>worker</code> і <code>explorer</code> описують призначення ролі, але сама назва ролі не визначає якість відповіді. Спеціальні файли конфігурації Codex зберігаються в <code>~/.codex/agents/</code> або в <code>.codex/agents/</code> проєкту та можуть задавати інструкції, модель і режим пісочниці (sandbox). Вони використовують TOML (Tom’s Obvious, Minimal Language — текстовий формат конфігурації); перед зміною звіряйте назви параметрів із довідкою про субагентів і довідником конфігурації.

Для перерваних запусків конфігурація має <code>agents.interrupt_message</code>: за замовчуванням Codex додає в контекст повідомлення про переривання. Це не скасовує саму роботу і не замінює перевірку того, чи повернувся результат.

Публічна документація вбудованих субагентів Codex не визначає підтриманий контракт для вкладених субагентів, максимальної глибини дерева або універсальної межі сумарної кількості дітей. Це означає «не задокументовано як можливість», а не «доведено неможливо». Не будуйте робочий процес навколо припущення про вкладеність. Посібник Responses API окремо описує дерево дочірніх запусків і не задає фіксованої глибини; Agents API має власний багатагентний контракт, але його публічний посібник не визначає семантику вкладеності. Ці правила не можна переносити на локальний Codex.

38.3. Коли варто делегувати

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

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

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

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

Кожен агент окремо використовує модель та інструменти, тому паралельна робота витрачає більше токенів, ніж подібне одноагентне виконання. До цього додаються час на підготовку, перегляд кількох результатів, повторні запуски та інтеграцію. Розраховувати виграш лише за кількістю відкритих потоків — погана оцінка; враховуйте увагу людини й оркестратора. Практичний розбір Фаулера про «податок оркестратора» описує один інцидент і є досвідом автора, а не універсальним вимірюванням Martin Fowler, “The Orchestrator’s Tax”.

38.4. Контракт доручення

Слово «експерт» у назві ролі не задає достатнього доручення. Корисний контракт дає дитині обмежений обсяг роботи і дає оркестратору підставу прийняти чи відхилити результат. Включіть щонайменше:

1. Мету і рішення. Для чого потрібна відповідь і яке рішення вона має підтримати.
2. Межі. Що входить до задачі, що прямо виключено, які файли або каталоги є власністю інших виконавців.
3. Джерела та ревізію. Точні документи, коміт, гілка, версія документації або часовий зріз даних.
4. Дозволені дії. Читання чи редагування, названі інструменти й системи, а також потрібні підтвердження. Не вимагайте від дитини вгадати відсутній дозвіл.
5. Очікуваний доказ. Посилання, шлях і діапазон рядків, пошуковий запит, команди та їхній результат, або інший спосіб відтворення.
6. Стоп-умови. Якої невизначеності досить, щоб повернути частковий висновок; де треба припинити роботу й запитати головного агента.
7. Формат відповіді. Висновок, докази, винятки, невідоме та наступний крок у фіксованій структурі.

Глави 24.8 і 26 вже розібрали, як обмежити переданий контекст і оформити передачу роботи. У цій главі контракт важливий для наступного кроку — розділення власності й точок збирання. Для пошуку без змін можна вимагати таблицю «виклик → файл і рядок → причина вважати це споживачем → перевірка → невизначеність», заборонити редагування й завершити пошук після визначених каталогів та запитів. Для реалізації контракт фіксує власників файлів і семантику полів обміну. Універсальний текст на кшталт «перевір усе і виправ» не задає ні межі, ні критерію завершення.

38.5. Контекст, файли, дозволи та зовнішній стан

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

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

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

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

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

38.6. Роздати роботу — і зібрати її в правильній точці

Коли контракт зрозумілий, оркестратор може роздати (fan-out) незалежні частини кільком виконавцям. Повернення та об’єднання результатів називають зведенням (fan-in). Точка зведення має власника: зазвичай це головний агент, який перевіряє кожну відповідь, зіставляє їх між собою та вирішує, чи дозволяють вони перейти до інтеграції. Автоматична збірка відповідей не робить цього рішення за нього.

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

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

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

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

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

38.7. Повний умовний приклад: пошук пропустив споживача API

Ситуація. Команда змінює поле <code>season_id</code> у відповіді спортивного сервісу. Перед реалізацією треба знайти всі місця репозиторію, які читають старе поле, щоб не лишити клієнт із непомітною помилкою. Пошук доручають субагенту, бо каталоги клієнтів, адаптерів і тестів можна перевіряти окремо від основного обговорення.

Доручення. Оркестратор вказує точний коміт, файли з описом відповіді, усі клієнтські каталоги та тести. Дитині дозволено лише читати. Запит просить знайти як прямі згадки <code>season_id</code>, так і побудову шляху відповіді через реєстр адаптерів; для кожного результату треба повернути файл, рядок, контекст виклику, пошуковий запит і пояснення, чому це споживач. Висновок має окремо назвати невідомі динамічні шляхи. Очікувана відповідь — таблиця, а не зміни файлів.

Повернений результат. Дитина знаходить два прямі типізовані клієнти, кілька тестів і приклади. У звіті написано «всі споживачі знайдені». Проте список пошукових запитів містить лише назву поля, а динамічний реєстр адаптерів дитина не перевірила.

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

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

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

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

Це навчальна модель, а не реальний запуск пошуку в курсі.

38.8. Повний умовний приклад: дві реалізації не збіглися на контракті

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

Контракт до запуску. Координатор фіксує, що кінцева точка повертає <code>amount_minor</code> — ціле число в найменших одиницях валюти, <code>currency</code> — код із трьох літер, а <code>captured_at</code> — час операції в узгодженому часовому форматі. За контракт відповідає одна визначена людина або одна задача. Агенту серверної частини й агенту інтерфейсу призначено різні файли; їм передані ті самі критерії та тестові приклади. Інтеграцію й перевірку між компонентами залишено координатору.

Незалежні результати. Сервер повертає суму <code>1234</code> як 12,34 одиниці валюти. Агент інтерфейсу трактує той самий атрибут як десяткові цілі одиниці й показує 1 234,00. Локальні тести обох частин проходять, бо їхні окремі тестові дані закріпили власні трактування поля. Такий результат можливий навіть тоді, коли кожен агент акуратно виконав свою локальну постановку.

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

Чому так. Різні файли зменшили конфлікт редагування, але не забезпечили спільного значення даних. Саме контракт і інтеграційний тест знайшли семантичну розбіжність, яку не бачили окремі локальні приклади.

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

Це навчальна ситуація; наведені результати не є фактично запущеними тестами.

38.9. Повний умовний приклад: «тести пройшли» без ревізії та журналу

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

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

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

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

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

Це умовний кейс, а не твердження, що тести в цьому прикладі запускалися.

38.10. Локальний Codex, Responses API та Agents API

Ліміти конкурентності різні й не переносяться між системами:

Система	Налаштування та типове значення	Середовище
Локальний Codex	<code>agents.max_concurrent_threads_per_session</code> (старий псевдонім — <code>agents.max_threads</code>); ліміт відкритих субагентних потоків, без головного. Значення за замовчуванням документація не фіксує; число шість у зразку конфігурації лише ілюстративне.	Поведінка залежить від клієнта й робочого дерева.
Responses API	<code>max_concurrent_subagents</code>; бета-режим, типово 3 активні субагенти, включно з нащадками, але без головного агента. Немає фіксованої верхньої межі ліміту, глибини дерева чи загальної кількості субагентів.	API-сесія та її модель подій.
Agents API	<code>max_concurrent_subagents</code>; типово 6 субагентів, не рахуючи координатора.	Координатор і субагенти спільно використовують файлову систему середовища; нової файлової системи для субагента не створюють.

Звіряйте контракт із документацією потрібної версії: API-поля й ліміти можуть змінитися. Дивіться посібник Responses API та посібник Agents API.

Ці відмінності не слід зводити до таблиці «скільки агентів краще запускати». В одному API глибина, середовище, події, моделі й інструменти задає його контракт; в іншому інші дефолти та файловий стан. Перевіряйте документацію того продукту й версії, де реально працюватиме код. Поточна документація Responses API позначає його багатоагентний режим бета-версією; окремі API-поля та підтримувані моделі можуть змінитися.

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

38.11. Відмова, очікування, повтор і автономія

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

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

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

38.12. Практичний цикл координатора

Для локального Codex застосовуйте послідовність, яка залишає за головним потоком відповідальність за інтеграцію:

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

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

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

Мінливу документацію і стан GitHub issue перевірено 26 вересня 2026 року.

1. OpenAI, Subagents, поточна документація Codex і ChatGPT Work. Поверхні, запуск, передавання результатів, моделі, конфігурація, дозволи та витрати; доступ 2026-09-26.
2. OpenAI, Configuration reference, поточна документація конфігурації Codex. Поля в секції <code>[agents]</code> та конфігурація спеціальних агентів; доступ 2026-09-26.
3. OpenAI, Configuration sample, приклад конфігурації Codex. Ілюстративні налаштування, зокрема приклад межі паралельності; доступ 2026-09-26.
4. OpenAI, Worktrees, поточна документація. Окремі робочі копії файлів, спільні метадані Git і робота паралельних чатів; доступ 2026-09-26.
5. OpenAI, Codex cloud, поточна документація. Окремі хмарні задачі й їхнє середовище; доступ 2026-09-26.
6. OpenAI, Multi-agent Responses API, поточний бета-посібник. Окремий API-контракт багатоагентного запуску й межі паралельності; доступ 2026-09-26.
7. OpenAI, Multi-agent Agents API, поточна документація. Інший API-контракт, типова межа конкурентності й спільне середовище; доступ 2026-09-26.
8. Anthropic, Create custom subagents — Claude Code Docs, поточна документація. Використано лише для контрасту задокументованої поведінки Claude Code; доступ 2026-09-26.
9. OpenAI Codex, Issue #23296, відкритий користувацький звіт про потік, що отримав доручення, але не виконав його. Використано як приклад типу відмови, не статистику; доступ 2026-09-26.
10. OpenAI Codex, Issue #24951, відкритий користувацький звіт про надзвичайно довге очікування; автор не надав мінімального відтворення, хоча навів логи. Використано з обмеженням, наведеним у тексті; доступ 2026-09-26.
11. Martin Fowler, “The Orchestrator’s Tax”, 16 липня 2026 року. Практичний розбір вартості уваги оркестратора на основі одного інциденту, не універсальна метрика; доступ 2026-09-26.