multi-agent-orchestration

How to organize multiple Agents to work together without losing the gains to coordination overhead. Per tw93 in 2026-04-27-agent-principles-architecture-engineering: multi-Agent isn’t a default — measure the single-Agent ceiling first, then reach for multi-Agent only when the workload genuinely fits. Coordination cost frequently exceeds parallelism benefit.

Two work modes — Conductor vs. Coordinator

The Coordinator mode is where multi-Agent earns its complexity. The win isn’t “more model instances” — it’s converting persistent human attention into final review on durable artifacts.

The default topology

Main Agent as Orchestrator + multiple workers, communicating via JSONL inbox protocol, file isolation via git worktrees, dependencies tracked as a task graph:

Orchestrator (main Agent)
   │
   ├── .team/inbox/<agent-id>.jsonl   ── append-only message queue per worker
   ├── .tasks/                        ── task graph, dependencies
   └── .worktrees/<agent-id>/         ── per-worker git worktree (file isolation)
       ├── worker-1
       ├── worker-2
       └── worker-3

Subordinate Agents do search / try / debug in their own context; only summaries flow back to the Orchestrator. Source quote on the discipline:

const result = await runAgentLoop(task, { messages: [] });
return summarize(result);   // main Agent only sees this line

Protocol before collaboration

Multi-Agent breaks down fast when teams try to coordinate via natural language. Models don’t reliably remember who promised what or who’s waiting on whom. The hard rule: define the protocol first.

{
  request_id, from_agent, to_agent,
  content,
  status: 'pending' | 'approved' | 'rejected',
  timestamp
}
// Persist:  .team/inbox/{agentId}.jsonl  (append-only, crash-recoverable)
// Read:     parse line-by-line, filter on status

Three primitives that must be in place before any actual collaboration begins:

1. Protocol — structured, append-only, parseable.
2. Task graph — .tasks/ with dependencies; the Orchestrator dispatches against it.
3. Isolation — .worktrees/ per Agent so file edits don’t collide.

Don’t reverse the order. Protocol first; isolation second; only then collaboration / parallelism.

Hallucination amplification

Frequent Agent-to-Agent interaction amplifies errors instead of cancelling them: Agent A introduces a wrong belief, Agent B reinforces it citing A, Agent C extends it, and they all converge on a high-confidence wrong answer. The fix is independent verification — break the chain by inserting a non-participating verifier:

• A second Agent with a different prompt or context, asked to evaluate independently.
• Unit tests, compiler, or other code-graders (agent-evaluation).
• Human review on the critical step.

Order again matters: durable task graph first, then named worker identities, then structured protocol, then cross-verification or external feedback. Skipping the graph and identities makes verification hollow — you don’t know whose claim is being checked.

Sub-Agent constraints

Two non-negotiable boundaries the source insists on:

• Depth limit. Cap recursion. Without one, sub-Agents spawn grandchild Agents until something blows up.
• Minimal system prompt. Sub-Agents get only Tooling, Workspace, Runtime — no Skills, no Memory directives. Two reasons: avoid permission leakage from the parent’s privileges, and preserve the isolation boundary that’s the whole point of using a sub-Agent (claude-subagents).

Selection rule

The source’s framing of “when to use multi-Agent at all”:

• Single-Agent ReAct loop with an explicit task graph is the default.
• Reach for sub-Agents when the search / try / debug / review chunks would otherwise contaminate the main Agent’s context — isolation is the value, not parallelism.
• Use multi-Agent (multiple peer-level workers) only after task graph + worktree + identity + protocol exist and a single-Agent benchmark has been measured.

Anti-patterns

• “Let’s parallelize” without a task graph or worktree isolation.
• Workers that share working state through the Orchestrator’s context — the parent now has the children’s noise.
• Workers given the parent’s full Skills + Memory — isolation is gone.
• No depth limit — recursive sub-Agent spawning.
• Cross-Agent verification skipped — high-confidence convergence on wrong answers.

Relation to other concepts

• claude-subagents is one runtime instantiation of these principles inside claude-code.
• long-running-agents uses related machinery (filesystem-backed state) for a different purpose: cross-session continuation rather than concurrent workers.
• harness is the umbrella — protocol, isolation, depth limits, and cross-verification are all boundary and fallback components of the multi-Agent harness.
• ralph-wiggum-loop is one productized application: agents reviewing other agents’ PRs in a loop until everyone (agent + verifier) is satisfied.

OpenAI Codex: agent-to-agent reviews as the default

2026-04-27-harness-engineering-codex-agent-first reports a different shape of multi-agent in production: rather than parallel workers on a task graph, the OpenAI codex team wires multiple agent reviewers around a single producing agent. Each PR is reviewed by additional agent instances (local + cloud) before reaching a human; over time, almost all review work has shifted to agent-to-agent.

This is structurally compatible with the patterns above:

• Independent verification is what makes it work — different reviewer prompts, different contexts, different vantage points (local repo state vs. cloud full-repo, structural-test verifier vs. behavioral-test verifier).
• The hallucination-amplification risk is real and gated by the invariants regime: when reviewers disagree on subjective questions, the lint / structural-test verifiers tip the result, so the loop terminates against mechanical ground rather than vibes.
• Hallucination-amplification still applies to the cleanup-loop fleet (entropy-and-garbage-collection) — multiple cleanup agents converging on the same wrong “preferred pattern” is a specific failure mode the post doesn’t yet quantify but flags as plausible.

The Codex case sits between the Coordinator and Conductor modes above: humans set the goal at the start (Coordinator), but several agents — producer + reviewers + verifiers — converse in tight back-and-forth (Conductor-shaped) without the human in the room. The output is a durable PR (Coordinator artifact) but the work is conversational. Both columns of the table on this page are doing useful work simultaneously.