This is the honest version of the multi-agent journey on this rig, told in the order it happened: what was built first, why each layer was added, what the measurements said about it, and what the next design changed as a result. The story matters because it ends somewhere most multi-agent writing never goes: the current system is less than the sum of what was built. Layers were removed on evidence, not opinion, and knowing why each one earned its deletion is the transferable part.
Every claim below carries one of three labels. Measured means a number from local telemetry, trace, or session store. Directional means observed consistently enough to guide a decision, but not isolated enough to quote as a clean delta. Recommendation means what this rig would do again, with the reasoning attached. Where a field-note article owns the underlying evidence, it is linked rather than repeated.
Phase 1 — native Codex subagents: parallelism without evidence
The first instinct was the one almost everyone has: spawn a worker per task, let them run in parallel, harvest the results. On a 2026 Codex subscription the native subagent route made this a one-line operation, and for a while the rig ran exactly that way. The instinct was not wrong — parallel work genuinely moves bounded slices off the main model's context — but the execution had a structural blind spot: no shared memory, no per-worker trace, no attribution of tokens to the worker that spent them.
Measured. An audit of the historical sessions that fed what 551 Codex sessions revealed showed the shape of the problem clearly: one GPT-5.6 parent recorded 25,980,767 measured tokens against 45,741,825 from its children, and the bulk of that child volume came not from the bounded DeepSeek workers (1,590,714 tokens across three of them) but from two oversized GPT-5.6 recovery children — one of which had effectively become a second orchestrator. The parent called wait_agent 93 times. Parallelism worked; supervision was invisible and expensive.
The failure that surfaced was operational, not theoretical: when two workers disagreed, there was no trace to settle the disagreement. No recoverable handoff existed. The lesson carried forward into phase 2 was specific — the instinct to delegate survives, but delegation without measurement is unfalsifiable, and unfalsifiable delegation cannot be improved.
What phase 2 changed: per-worker traces, token attribution, and recoverable handoffs became the design priority before any further layer was added.
Phase 2 — measurable workers: telemetry as a first-class citizen
The fix was not a new orchestration tool. It was instrumentation: portable traces per parent and child transcript, tokens attributed to the worker that spent them, bounded work packets, and handoffs that could resume from a checkpoint instead of replaying a chat. How I made Codex subagents measurable owns the full build and the reliability incident that motivated part of it — a persistent Chrome debugging endpoint used as a dependable shared resource, which it was not, and which produced error 1006 on a WebSocket that had never been properly owned. The repair work (flock-locked ownership, bounded packets, queue states, queue teardown on health-check failure) mattered because it made the next conclusion possible.
Measured. With attribution in place, the same historical audit could finally ask where the tokens went. The answer was uncomfortable: bounded workers were cheap, but the supervision and recovery path — the part designed to keep workers on task — was where the volume concentrated. That is the finding that reframes everything that follows: the problem was never "do we delegate?" but "who pays for the coordination, and does the coordination repay itself?" Without phase 2's traces, no subsequent layer could have been judged at all.
Directional. Reliability of the browser-control path went from intermittent failure to stable once ownership and health checks existed — consistently observed across subsequent runs, not isolated to a matched pair.
What phase 3 changed: with visibility in place, the next question became structural rather than observational — should planning and execution live in the same tool at all?
Phase 3 — the Codex/OpenCode split: what a planner/worker split taught
Splitting planner and executor into two tools with two models looked like an architecture win: the expensive model stays on the control plane, a cheaper executor carries the bulk, and each side specialises. The rig built exactly this in its simplest form — Codex as planner and parent, OpenCode Go as the bounded execution worker, and nothing else between them — and it worked immediately well enough to teach the next lesson. Two things became clear that phase 1 could not show: a fresh worker with a clean contract outperformed an overloaded parent doing everything itself, and every hop between the two added a context resend. The split earned its place; the cost of adding more hops was now visible for the first time.
Measured. The specific case study and its economics belong to How I split Sol planning from OpenCode Go execution, which measured one completed delegation-heavy bounded task: the Codex parent used 4,997,110 tokens, the OpenCode Go worker 11,967,667, for a known total of 16,964,777 — the worker held 70.54% of the known total, and the article is explicit that this shows where work occurred, not what Codex would have spent alone. The lesson that mattered architecturally came from the per-call traces across this two-tool split: even the simplest planner/worker hop carries real overhead. Why agent systems become slow, expensive and fragile owns the cost mechanism (context resends on every hop, oversight cost, cumulative failure probability); this article owns the decision that followed from it.
Directional. Recovery worked as designed — one worker touched an unrelated coordination path and the controller rejected the result, which was the correct outcome. But every hop added a resend, and the traces showed the hops were not paying for themselves on single-repo editorial work.
What phase 4 changed: having proven that a simple split worked and that every hop costs something, the rig then tried to make the split more disciplined and auditable by adding coordination machinery around it.
Phase 4 — Beads, BVR, NTM, and Agent Mail: coordination machinery priced and removed
With the two-tool split proven, the rig added the coordination machinery that phase 3's split had deliberately lacked: Beads as the durable task list, BVR for task-ownership and state rules, NTM to schedule and watch workers, and Agent Mail as the message channel between hops. Together these turned the bare split into a full lifecycle system with reservations, leases, recorded handoffs, and message threads — the most professional-looking version of the rig yet.
Measured. The per-call traces showed each lifecycle layer adding measurable coordination cost: records to write, states to transition, leases to expire, message threads to carry. What the traces did not show — and what no benchmark in this journey tested — is a matched quality comparison proving each layer reduced or failed to improve output quality. The honest evidence is narrower: the traced overhead was real and consistently present, and no operational failure in the recorded history was prevented by any lifecycle layer that the simpler split in phase 3 would not have caught at the parent's acceptance gate. The layers were removed for traced overhead and the absence of demonstrated need, not for a measured quality regression.
Directional. The complexity itself created new failure modes: the recovery incident in the linked case study (a worker touching an unrelated coordination path) only existed because there was a coordination surface to touch. Removing the surface removes the failure class, not just its cost.
What phase 5 changed: the design stopped asking "how should agents coordinate?" and started asking "what is the minimum set of hops that still catches real failures?"
Phase 5 — the current model: five hops, each paying its way
What survives is a two-part model. The general core — three roles, each justified by a specific failure it catches — is what every multi-agent task needs:
- Codex as supervisor — understands the request, writes the worker contract, holds the acceptance bar, and edits nothing itself. The role matters more than the model name; the point is that the actor writing the contract is not the actor doing the work.
- GLM-5.3-Flash as the workhorse, via native Codex task rotation — bounded implementation inside an isolated worktree, fresh context per task. Rotation is a trigger, not a timer: context pressure or a genuine stall, not token counts or phase-complete events.
- Independent parent acceptance — the same supervisor re-checks the rendered result with criteria it did not inherit from the worker's summary. In the case study this gate caught all three real failures: an insufficient visual gate, stale editable-source links, and a homepage regression that rode in on an otherwise reasonable evidence commit.
The conditional extension — two more steps this editorial batch added on top of the core — applies when the work needs expensive narrative or design judgement:
- Targeted Claude Opus through OpenCode for expensive narrative review — read-only, bounded, judging what a reader sees. The case study measured one such review at 56,747 tokens and $0.47 — cheap because it was bounded, not because Opus is cheap.
- GLM amendments inside the worker's own scope — review verdicts become edits through the same disciplined channel that produced the original work, never by a reviewer reaching into the tree.
The loop then returns to step 3 — independent parent acceptance — which re-checks the amended result under the same criteria before anything merges. Acceptance is not a separate sixth step; it is the same gate every path closes through, and it never inherits its criteria from the work it is checking.
Measured. The full execution behind The multi-agent execution behind one rebuild — this same loop applied to a real 13-article rebuild — is the case study, and its economics are stated there with their provenance and caveats. This article does not repeat the numbers; it states the structural claim the numbers support: the expensive model is affordable when its task is judgement, the cheap workhorse absorbs the volume, and the acceptance gate is what converts all of it from "the agent said it worked" into a shippable result.
Recommendation. For general multi-agent work, the three-step core — supervisor/contract, bounded workhorse, independent acceptance — is the minimum honest loop, and many tasks need nothing more. Add the two-step judgement extension only when the output itself needs expensive review that the workhorse cannot self-apply: editorial, design, or high-consequence work. This batch used all five steps; the next task might need only three. Anything beyond the extended five — a second coordinator, a message protocol between the hops, lifecycle state machines — needs to show a failure it prevents that this loop does not already prevent. Nothing in the traced history did.
Where A2A fits — and why this batch did not need it
The rig did build an A2A plane — How I got four AI agents talking to each other proved all 12 directed routes between Codex, OpenClaw, OMP, and Hermes on loopback. That experiment was a genuine capability test, and it succeeded at what A2A is for: agents that live in different runtimes discovering each other, exchanging stable task and context identifiers, and negotiating work without custom plumbing. A2A is not an inferior design; it is a different problem's solution.
The editorial batch that produced this article ran through native Codex task creation plus the OpenCode review path, and that was the right call — not because A2A fails, but because the discovery problem A2A solves did not exist here. One supervisor, one workhorse, one reviewer, one acceptance gate, one repository, one parent's line of sight. There was nothing to discover. Adding an A2A plane would have added endpoints, envelopes, and a second control surface to maintain, in exchange for zero capability the loop did not already have.
Recommendation. Reach for A2A when participants live in different trust domains, different runtimes, or different organisations — or when the question "who exists, what can they do, how do I reach them" is itself the hard problem. Reach for native tasks plus OpenCode when the participants are one operator's tools on one machine. The comparison is about fit, not rank: both paths appeared in this journey's measured history, and both earned their place.
What survived, stated plainly
Three things carried through every phase, and none of them is a tool:
- Measurement as a first-class citizen. Every architectural claim in this article is checkable against a trace, a session store, or a published article's evidence pack. That habit — built in phase 2 — is what made every later deletion possible. Without it, the story would be a sequence of opinions.
- Role-aware routing instead of model loyalty. Cheap workhorse by default, frontier escalation only for genuinely hard judgement. The conclusion outlives the specific model names on this page.
- The minimum loop that catches real failures. A three-step core, extendable to five when the work demands expensive judgement. Everything else was removed on traced overhead and the absence of demonstrated need.
The older field notes remain as the paper trail — the OpenRouter-backed AI team, making subagents measurable, one agent, two models, the A2A mesh, and the Sol/OpenCode split. They are evidence, not the through-line; this article is the through-line.
Why this matters outside the terminal
If you build anything with AI tools, the subtractive arc is the useful part, and it generalises further than coding agents. Every layer you add so that agents can coordinate has a cost that becomes measurable the moment you instrument for it — and most coordination layers, at single-operator scale, do not repay that cost. The honest sequence is not "build more" but "instrument, then subtract until the loop is as short as the failure modes demand." That is what happened here: parallelism first, measurement second, then the discipline to delete what the measurements condemned.
Where to go next
- The multi-agent execution behind one rebuild — the case study this article's current model descends from, with the measured economics
- How I split Sol planning from OpenCode Go execution — the specific website-remediation case study and its token economics
- Why agent systems become slow, expensive and fragile — the mechanism behind the middleman tax
- What should be an agent — and what should be normal code? — the decision rule this journey produced