Running a Team of Agents Without the Chaos

Six months ago you paired with one AI. You typed a prompt, waited, read the diff, corrected it, repeated. Your ceiling was whatever fit in a single context window, and the conversation thread was your workspace.

That model is already legacy. When GitHub announced its Copilot app at Build on June 2, 2026, it reframed the assistant as a control center for multiple agent sessions running in parallel — each in its own isolated git worktree so several agents can work the same repo without overwriting one another. GitHub isn't alone; there's now an entire ecosystem of orchestrators doing the same thing. The shift has a clean name, courtesy of Addy Osmani: you've gone from conductor — one musician, real-time guidance — to orchestrator — a whole ensemble, coordinated asynchronously. The codebase becomes your canvas instead of a chat thread.

Here's the catch nobody tells you when you spin up your third agent: the bottleneck moved. It used to be the agent's capability. Now it's coordination. Uncoordinated parallel agents don't just fail to help — they actively corrupt a codebase in ways that are expensive and, worse, quiet. This is a field guide to running the ensemble without the chaos.

First, the primitive: git worktrees

Almost every serious orchestration setup in 2026 is built on one Git feature that's existed since version 2.5 and suddenly became essential: worktrees. A worktree is a real, separate working directory that shares the same underlying .git object database. Each agent gets its own files, its own staging area, and its own HEAD — but they all sit on top of one history.

# One repo, three isolated working directories on three branches
git worktree add ../wt-export   feature/csv-export
git worktree add ../wt-ratelimit feature/rate-limit
git worktree add ../wt-audit    feature/audit-log

git worktree list          # the authoritative view of who's where

Point one agent at each directory and they can edit, build, and run tests simultaneously without touching each other's files. Conflicts get deferred to intentional merge points instead of happening live while three agents fight over the same working tree. That deferral is the whole game — it's what turns "parallel chaos" into "parallel work you review on your own schedule."

What goes wrong when you skip coordination

Worktrees solve file-level collisions. They do nothing about the harder failures, and you need to be able to name them to defend against them. Four show up constantly:

Shared-hotspot conflicts. Every real repo has files everything touches — the route table, the DI container, the config registry, the migrations directory. Point two agents at features that both register a route and they'll both edit routes.ts. Worktrees don't warn you; Git only notices at merge, as a text conflict, after both agents have "succeeded."

Duplicated implementations. Two agents solving related tasks in isolation each write their own formatCurrency helper, their own validation wrapper, their own retry logic — slightly different, all "correct," quietly fragmenting the architecture. Nobody shared the intermediate decision, so nobody reused the work.

Semantic contradictions — the dangerous one. Two changes each look right on their own and contradict each other when composed. Agent A renames a field and updates its callers; Agent B, in parallel, adds a new caller using the old name. Both branches compile. Both pass lint. The bug only exists after the merge, at runtime, where no gate was looking. This class is the hardest to catch precisely because every automated check passes.

Silent failure. The reason multi-agent work is riskier than a human team doing the same thing: agents don't notice when something's gone wrong. A human who realizes their task overlaps a colleague's walks over and says so. An agent burns its budget confidently down a path that's already been invalidated by another agent's merge, and reports success.

Notice that three of these four are invisible to the tooling. That's why coordination has to be designed, not hoped for.

The operating model that works

The pattern that's emerged across the good orchestration tools is a three-role split, borrowed straight from how you'd run a human team. It's worth adopting even if your "tooling" is just three terminal tabs and a markdown file.

A coordinator owns decomposition and merge order. Its job is to cut the work into tasks whose boundaries genuinely don't overlap, sequence anything with a dependency, and let only the truly independent tasks run at once. This is the role that prevents the shared-hotspot problem — by not handing two agents work that lands in the same file.

Specialists do the implementation, one per worktree, each with its own context window scoped to its slice. The isolation is a feature: an agent working only on the export feature isn't spending budget loading — or getting distracted by — the rate-limiter code.

A verifier checks each specialist's output against the spec before it merges — running tests, and specifically probing for the semantic contradictions the other gates miss. This is the gate that connects directly to code-review discipline: it's where you catch the SSRF, the missing authorization check, the hollow test, before three of those land at once.

Then the merges happen sequentially, never in a batch. You merge one branch, let the verifier re-check the others against the new state of main, resolve, merge the next. Sequential merging is what preserves coherence when several independently-correct changes need to become one working system.

An architecture diagram of multi-agent
orchestration: a Coordinator at the top decomposes a spec into three scoped tasks; each task runs as
a Specialist agent in its own isolated git worktree branch; all three feed into a Verifier gate that
runs tests and checks for semantic conflicts; the Verifier then merges branches one at a time,
sequentially, into main. — Coordinator decomposes, specialists build in isolation, the verifier gates and merges one branch at a time.

A worked example: scoping so agents don't collide

Say you want three things done on a web service: a CSV export endpoint, request rate-limiting, and an audit log. The naive move is to fire off three agents with those three sentences. Two of them will end up in your middleware stack and your route table, and you'll spend the afternoon merging.

The coordinator's job is to scope by boundary, not by feature name. Here's the decomposition I'd actually write, as a TASKS.md at the repo root that every agent reads but none of them edits while working:

# TASKS.md — parallel batch 1 (independent; safe to run concurrently)

## agent: export     → worktree ../wt-export     branch feature/csv-export
Scope: NEW files only under src/export/**. Register exactly ONE route by
appending to routes.ts via the marked "// <export-routes>" anchor. Do not
edit existing handlers. Reuse src/lib/csv.ts if present; do not add a CSV dep.

## agent: audit      → worktree ../wt-audit      branch feature/audit-log
Scope: NEW files under src/audit/**. Add a migration in db/migrations/ with
a timestamped name. Do NOT touch routes.ts. Expose a logEvent() function only.

## SEQUENCED — do NOT run with the above (touches shared middleware)
## agent: ratelimit  → after export+audit merge, on fresh main
Scope: src/middleware/rateLimit.ts + wire-up in app.ts. Depends on nothing,
but edits app.ts, which the export merge also touches — so it goes second.

Two things make this work. Each concurrent task is confined to its own directory tree with an explicit "new files only" boundary, and the one place they must share — the route table — is mediated by a single append-only anchor rather than open edits. And the task that touches genuinely shared middleware is pulled out of the parallel batch and sequenced after, because the honest answer to "can these run at once?" was no.

That last point is the discipline most people skip: not everything should be parallelized. Tightly coupled work run in parallel costs you more in merge-and-reconcile than you ever saved in wall-clock time. Parallelize the independent, sequence the coupled, and be ruthless about which is which.

A decision graphic titled "Parallelize the
independent, sequence the coupled." A left-to-right flow asks three questions of a batch of
tasks — do they touch the same files or shared hotspots, does one need another's output, does each
fit inside one subsystem's context — routing a "yes" on the first two to SEQUENCE, a
"no" on the third to SPLIT SMALLER FIRST, and an all-clear to PARALLELIZE. Below, a
serial-versus-parallel timeline shows parallel finishing sooner but paying a red "reconcile"
tax, with the wall-clock saving real only when that tax is near zero. — Three questions decide it: shared files, dependency, or subsystem fit — parallelize only the all-clear.

Guardrails and gotchas

Serialize your Git plumbing. Worktrees isolate working files, but they share one object database. Running git commit, fetch, or pull concurrently across worktrees can corrupt shared metadata. Let agents edit and test in parallel, but funnel the actual Git write operations through one lane.

There is no cross-worktree conflict warning. Git will not tell you that two worktrees are editing the same file on different branches. Until you merge, you're blind to it — which is exactly why the coordinator's up-front scoping matters more than any runtime safety net.

Constrain checkouts in monorepos. Each worktree is a full working-directory checkout, and in a monorepo the disk I/O compounds fast once file watchers, test runners, and build tools all run per-worktree. Pair git worktree add with git sparse-checkout set <paths> so each agent only materializes the files it needs.

Pick the right tier for the job. The 2026 landscape sorts into three: in-terminal subagents you drive yourself (great for 3–10 agents on a codebase you know), local orchestrators with dashboards and diff review (the sweet spot for parallel sprints), and cloud agents you dispatch and collect as pull requests later (for draining a backlog overnight). Most of us end up using all three depending on the task, not committing to one.

Watch the meter. Orchestration and usage-based billing arrived in the same week for a reason: ten agents cost roughly ten times the tokens, and a lot of that spend is agents re-loading context or chasing a path another agent already invalidated. Token efficiency — good scoping, small context per specialist, killing dead sessions early — is now a real line item, not a footnote.

The skill that actually changed

The uncomfortable truth about orchestration is that it demands a different skill than the one that made you good at pairing with a single agent. Guiding one agent well is about tight, real-time feedback. Running an ensemble is about the things a good engineering manager does: writing specs clear enough that independent workers don't diverge, decomposing work along boundaries that don't overlap, and verifying output you didn't watch get made. The typing is increasingly the agents' job. Deciding what they type, making sure the pieces compose, and owning the quality of the merged whole — that's the job that's left, and it's a bigger one than it looks.

Companion piece: once your verifier is catching output before it merges, the natural next question is what exactly it should be looking for. That's the subject of "The AI Code Review Gauntlet" — the specific failure classes AI-generated code ships, and the fast checks that catch them.

This is Part 2 of The Agent Stack. Next: "Loop Engineering" — the system that drives this whole ensemble toward a goal without you poking it every turn.