How I Run a Multi-Agent Engineering Pipeline

People ask me how I actually run several AI agents at once without the whole thing collapsing into a pile of half-finished branches and confident-sounding lies. Not the philosophy of it — the mechanism. This is that: the concrete shape of the pipeline, gate by gate, including the parts that still break.

The shape: parallel lanes, one orchestrator

Sequential work — a single thread of changes building on each other — stays on the active branch, one agent at a time, no ceremony needed. Parallel work is different. The moment I have several independent tasks that don't depend on each other, each one gets its own git worktree: a separate working copy of the repository, checked out from the same history, that an agent can edit without touching any other lane.

My job in that arrangement is to be the orchestrator, not another pair of hands on the keyboard. I decompose the goal into tasks that can genuinely run independently, dispatch each one to its own worktree and its own agent, verify what comes back before it goes anywhere near the trunk, and synthesise the results into one coherent change once every lane has cleared its gate.

The reason for worktree isolation is simple and, once you've been burned by the alternative, non-negotiable. A failed or half-finished lane can't poison the trunk, because it never touched the trunk — it lives in its own directory on its own branch until it's proven. Two agents editing overlapping files don't stomp on each other's uncommitted changes, because they're not sharing a working copy. And nothing merges unreviewed: a worktree existing is not a claim of correctness, it's just a container waiting for a gate to pass. Every worktree, at any point in a session, is in exactly one of two states — merged back into the trunk after re-verification, or explicitly flagged to me as needing manual attention with the branch preserved. An orphaned worktree, quietly abandoned with real work sitting in it, is a failure of the process, not a rounding error.

Cross-engine review as the core gate

The single rule that does the most work in this pipeline is also the simplest to state: the agent that builds a change is never the agent that clears it. If Claude Code writes the diff, Codex reviews it. If Codex writes it, Claude Code reviews it. The builder and the reviewer are always a different engine, from a different vendor, trained on a different pipeline — never the same model marking its own homework.

The reason this matters is that a model reviewing its own output tends to rationalise it. It wrote the code with a particular mental model of the problem in mind, and when it re-reads that code, it re-reads it through the same mental model — so the same blind spot that produced the bug is the blind spot doing the reviewing. A different engine has no investment in the diff and no shared training history to inherit the same gap. It reads the change cold, against the stated requirements, looking for what would actually break in production: missing authorisation checks, injection paths, race conditions, silent data corruption, the acceptance criteria the first pass quietly reinterpreted. Nothing in my pipeline is allowed to self-certify.

Proof of work, not the agent's word for it

A task is not done because an agent says it's done. "Done" is a claim, and I treat every claim as an input to be checked rather than a fact to be recorded. What actually closes a task is a receipt: the verbatim output of the test that was supposed to pass, the independent reviewer's written verdict, and — for anything a human being will actually look at — a screenshot of the rendered result, checked in both light and dark themes, not a description of what it should look like.

This sounds pedantic until you watch how often it changes the outcome. Agents write plausible test suites generously: assertions that can't fail, mocks that verify other mocks, coverage numbers that climb without the underlying behaviour being pinned down. The gap between "the agent reports it passed" and "the command actually produced that output" is where a surprising share of reported progress quietly evaporates. So the standard is fail-closed: if the evidence for a gate is missing, stale, or doesn't match the exact change being graded, the task is not proven — no benefit of the doubt, no "it's probably fine."

Matching the model to the task

Not every task deserves the most expensive model available, and putting everything on the top tier is waste dressed up as diligence. I try to reserve the strongest, highest-effort models for the places where being wrong is costly: novel design decisions, security-sensitive code, adversarial review itself, and debugging that's already resisted a couple of straightforward attempts. Everything else — the bulk of real engineering work, mechanical refactors, tests written against an existing pattern, configuration, formatting, straightforward CRUD — goes to a cheaper, faster model that's perfectly capable of it.

The economics only work this way because the pipeline is provider-agnostic by construction. Cross-engine review requires more than one vendor in the loop anyway, so there's no architectural reason to hardcode a single provider for the builder role either. Which model is best or cheapest this month changes; the routing logic that picks the right one for the job doesn't need to.

What a second engine actually catches

A concrete example from this month makes the case better than the abstract argument does. One engine diagnosed a performance problem in a piece of software I was building, produced a clear write-up of the causes, and proposed a set of fixes. I then handed the same codebase, cold, to a different vendor's engine and asked it to do its own independent diagnosis rather than critique the first one.

It agreed with the first engine on the fixes that mattered most — confirming three of the proposed changes independently, from its own read of the code, with no visibility into the first engine's reasoning. But it also surfaced five additional cost multipliers the first pass had missed entirely: real, separate contributors to the same problem that the first engine's diagnosis simply never touched. Had I shipped on the strength of the first review alone, I'd have fixed the three problems everyone agreed on and left five more sitting in the code, invisible, because nothing had forced a second, independent look.

That's the whole argument for cross-engine review in one worked example. Agreement between two independent engines is real evidence. A single engine's confidence, however articulate, is not.

What still goes wrong

None of this makes the pipeline reliable by default — it makes the failures visible and recoverable, which is a different and more honest claim. Agents still report success that isn't there; that's exactly why the proof-of-work gate exists, and why it's fail-closed rather than trusting. An agent can burn through its usable budget mid-task and simply stop, mid-file, with no warning; the answer there is to resume from the agent's own session transcript rather than respawning it from a blank context, so the work already done is preserved rather than redone from zero. And a lane can genuinely fail — a worktree left behind, unmerged, because the task it held turned out to be broken or superseded; the answer is that no session ends without an explicit accounting of every open worktree, each one either merged and removed or named out loud as needing manual attention, never just left to rot.

None of these are solved problems. They're managed ones, with a specific mechanism attached to each failure mode I've actually hit. That's the honest description of what "running a multi-agent pipeline" means in practice: not a system that doesn't fail, but one where failure is caught by a gate before it reaches anything that matters, and every piece of in-flight work is accounted for rather than assumed.