| name | multi-agent-loop |
| description | Use when Standard/Full tasks have explicit subagent permission, parallel tracks, runtime sync, long waits or high scope-drift risk. |
| verified_at | "2026-05-29T00:00:00.000Z" |
| covers | ["process","coordination","review"] |
| drift_covers | [".agents/skills/multi-agent-loop/**","AGENTS.md","agent-harness/modules/multi-agent-loop.md","scripts/harness_wave_check.py"] |
Multi-Agent Loop
Используй этот skill как workflow overlay, а не как замену AGENTS.md, Research → Plan → STOP → GO, safety guard или verification gate.
Цель: главный агент остаётся orchestrator, а маленькие xhigh сабагенты помогают на чекпоинтах ловить drift, blockers и параллельную работу.
Routing boundaries
Используй этот skill только как Standard/Full workflow overlay for runtime sync, generated files, code/integration tasks, 2+ independent tracks, long checks, high scope-drift risk or explicit subagent/delegation permission. Не используй для casual discussion of multi-agent systems, ordinary GO, simple single-track tasks, product ideation about agents or OMX/tmux/team runtime decisions.
Wave Mode / Work Orders
Wave Mode — optional execution overlay для задач, где есть 2+ независимых tracks или реальная параллельная поверхность. Это не новый обязательный task-contract и не постоянная команда агентов.
В каждом Standard/Full plan.md добавляй ### Wave Fit Check:
Wave: yes/no;Signals;Reason;Subagents.
Это короткая adoption-развилка, а не отдельный audit. Если Wave: yes, добавь ### Wave / Work Orders. Если Wave: no, reason должен показать, почему single-track flow достаточен.
Orchestrator всегда владеет:
- целью и
Task ID;
- plan, safety и approval boundaries;
- integration между tracks;
- финальной verification и closeout.
Для каждого Work Order фиксируй:
Track;Role;Owned files;Inputs;Deliverable;Verification;Handoff.
Ownership относится только к mutating scope: reading files never requires a lock. Если два tracks претендуют на одни Owned files, это plan revision или explicit handoff, не silent parallel editing.
Каждый Wave: yes Work Order должен быть полноценным brief. Missing Track, Role, Owned files, Inputs, Deliverable, Verification или Handoff означает неполный план.
Wiring/caller/shared-interface файлы должны быть либо в Owned files владельца изменения, либо явно описаны в Handoff как sequential integration. Hidden post-merge wiring не считается планом.
Scaffold/interface changes before parallel work are sequential pre-wave work, not another parallel lane, unless their mutating files are explicitly owned and verified before dependent tracks start.
Каждый worker/reviewer/inline verifier closeout должен вернуть bounded receipt:
Changed files или read-only;Checks;Blockers;Handoff / next owner;Residual risk.
Receipt — это evidence для orchestrator. Он не заменяет пользовательский GO, reviewer verdict, финальную verification или Task receipt.
Runtime/generated sync Work Orders must include checklist evidence:
- canonical source;
- repo mirrors;
- repo-only vs operator-home runtime;
- runtime manifest unchanged/changed reason;
- no live actions/secrets;
- trigger acceptance observed/not observed.
Этот checklist не даёт разрешение на home runtime install, hooks, MCP/live connector wiring, secrets access или manifest promotion. Для таких действий нужен explicit current-scope approval.
Cross-contour или async handoff идёт через существующий Dashboard/Task Handoff/*.md. Same-task coordination stays in plan.md / log.md. Не создавать LOCKS.md, outbox/, durable mailbox, .omx, tmux/HUD/team runtime или keyword routing для v1.
Wave v1.2 automation
Latest Wave adoption diagnostics входят в обычный harness gate:
python3 scripts/harness_check.py --mode fast
python3 scripts/harness_check.py --mode strict
Под капотом используется scripts/harness_wave_check.py validate, поэтому пользователь не должен вручную помнить отдельную команду.
Advisory helpers:
scripts/harness_wave_check.py suggest — draft Wave Fit Check, complete Wave / Work Orders skeleton and runtime/generated sync checklist from task text/targets;scripts/harness_wave_check.py measure --last 20 — stdout-only harvest of recent Wave result: lines.
Strictness v1.2:
- missing/generic
Wave Fit Check / Wave result: = warning-only;
Wave: yes без Work Orders = strict-mode error;- exact duplicate mutating
Owned files = strict-mode error unless explicit sequential handoff is present;
- potential glob overlap = warning-only.
- incomplete
Wave: yes Work Order fields = warning-only in fast mode and error in strict mode for plan sections dated 2026-06-01 or newer; older active sections stay warning-only.
Compact examples
Хороший Wave: yes:
Wave: yes
Signals: code/integration, generated files, 3 disjoint tracks
Reason: process wording, validator/tests and generated sync can move independently.
Subagents: no real subagents; no explicit skill/workflow/subagent permission.
Хороший Wave: no:
Wave: no
Signals: checked; single narrow text change, no generated/runtime sync, no long checks.
Reason: one file and one verification path; Work Orders would add ceremony.
Subagents: not applicable.
Плохие Wave patterns:
- overlapping
Owned files без plan revision или explicit handoff;
- locks for reading files;
- real subagents without explicit skill/workflow/subagent permission;
готово without test/build/diff/manual evidence.
В log.md closeout добавляй:
Wave result: used/not used/not applicable; helped/friction; next adjustment
Когда включать
Включай для Standard/Full задач, если есть хотя бы один сигнал:
- кодовые изменения;
- generated files или runtime sync;
- несколько независимых веток работы;
2+ независимых tracks;- долгие build/test ожидания;
- повышенный риск scope drift;
- user explicitly mentions
$multi-agent-loop, /multi-agent-loop, this skill by link/name, subagents, delegation or parallel agent work.
Не включай для обычных текстов, draft mode, коротких ответов, мелких локальных правок и рутинного Auto-flow.
Recommendation gate
Explicit permission для реальных сабагентов включает $multi-agent-loop, /multi-agent-loop, Markdown/link mention этого skill, subagents, delegation или parallel agent work. Casual multi-agent без named loop не считается permission.
Если задача подходит под loop, но пользователь не дал явного разрешения, один раз до исполнения скажи:
Рекомендую включить $multi-agent-loop: reviewer/explorer на gpt-5.4-mini xhigh. Реальных сабагентов я не запускаю без явного skill/workflow/subagent permission.
Не спрашивай повторно на каждый tool call. Если пользователь не даёт разрешение, продолжай обычный flow и при необходимости сделай inline reviewer-check.
Это platform permission boundary для реальных сабагентов, а не общий manual-invocation requirement для skill/check работы.
Обычный GO сам по себе не считается разрешением на реальные сабагенты, если в нём нет явного skill/workflow/subagent permission.
Native subagents vs OMX team
Codex native subagents и OMX/tmux team — разные runtime surfaces.
$multi-agent-loop authorizes only bounded in-session subagents, которые главный агент запускает, ждёт и интегрирует внутри текущей сессии.- OMX
team / tmux / HUD / mailbox runtime не является Codex App default, не включается через обычный GO и требует отдельного operator decision.
- Не переносить
.omx state, durable team workers или keyword routing в этот loop.
Model routing
Default для всех small-model сабагентов:
- model:
gpt-5.4-mini
- reasoning effort:
xhigh
Роли:
- reviewer:
gpt-5.4-mini, xhigh;
- explorer:
gpt-5.4-mini, xhigh;
- worker:
gpt-5.4-mini, xhigh, только для bounded/disjoint задач.
Escalate to full gpt-5.4 only if:
- задача архитектурная или high-risk;
- mini нашёл blocker, который требует сильного reasoning;
- два mini-прохода дают слабый или противоречивый результат;
- task scope слишком связан, чтобы безопасно делегировать mini-worker.
Если нужная mini-модель недоступна, используй ближайшую доступную mini-модель с максимальным reasoning. Если subagents недоступны или platform/developer instructions не разрешают их запуск, выполни reviewer-check inline главным агентом.
Checkpoint cadence
Не запускай reviewer после каждого tool call. Запускай на смысловых чекпоинтах:
- после research/plan на сложных задачах;
- после крупного edit-pass;
- во время долгих build/test ожиданий, если есть полезная параллельная работа;
- перед финальной verification.
Reviewer contract
Дай reviewer минимум нужного контекста:
- Task ID;
- цель и acceptance criteria;
- текущий план/TODO;
- active Wave / Work Orders, если они есть;
- что уже изменено или проверяется;
- известные ограничения и out-of-scope.
Попроси reviewer вернуть только:
Progress to goal;Blockers;Parallel candidates;Scope drift;Recommendation.
Reviewer may add Architectural Status: CLEAR | WATCH | BLOCK when reviewing a plan or checkpoint:
CLEAR means no blocker/watch item found by reviewer; it is not GO and not execution approval.WATCH means execution may continue only after the watch item is copied into plan risks/checks/acceptance criteria or current TODO.BLOCK means stop execution until the blocker is resolved or explicitly descoped.
Reviewer не должен редактировать файлы, approve-ить execution, выдавать GO, менять task scope или предлагать действия, которые обходят GO, safety guard, approval boundaries или live-system constraints.
Для Wave: yes, runtime sync changes, generated instruction changes, checker/validator changes and user-facing template-language changes перед closeout обязателен local read-only verifier pass. Если нет explicit skill/workflow/subagent permission, verifier выполняется inline главным агентом. Read-only verifier must not mutate working tree; verdict remains advisory evidence, not approval.
Delegation rules
Главный агент держит critical path и интеграцию. Не делегируй urgent blocking work, если следующий шаг главного агента зависит от результата.
Explorer получает read-only вопрос и возвращает короткий ответ с путями/фактами.
Worker получает bounded write scope только если:
- файлы или модуль явно отделены от других работ;
- задача не требует архитектурного решения;
- нет риска конфликтов с чужими изменениями.
Всегда сообщай worker:
- он не один в кодовой базе;
- нельзя откатывать чужие изменения;
- нужно работать только в назначенном scope;
- нужно перечислить изменённые файлы в финале.
Не запускай двух workers на один write scope.
Inline fallback
Если сабагенты недоступны, сделай короткий inline reviewer-pass:
Progress to goal:
Blockers:
Parallel candidates:
Scope drift:
Architectural Status:
Recommendation:
Затем продолжай обычный verification gate.
