How to run a team of AI coding agents: a practical guide to orchestration
One AI coding agent, working on one task, in one terminal, is easy to run. You write a prompt, you watch it go, you read the diff, you decide if it’s right. Almost everyone’s first experience of “AI coding agents” looks like that, and for a single task at a time, it’s genuinely all you need.
This guide is about what happens next — the point where a person or a team wants more than one agent working at once, on more than one task, maybe on more than one machine. That shift looks small from the outside (“just run another instance”) and turns out not to be. It’s a coordination problem, not a bigger-prompt problem, and it shows up whether you’re a developer running a fleet of specialist agents across your own machines, or a product person with a backlog of ideas and no engineering time to spend on them. Both of you end up needing the same thing: a way to brief work, watch it move, and trust what comes out the other end without personally supervising every step. That’s what orchestration means in practice, and it’s what the rest of this guide walks through — the problems a herd of agents creates, and an operating model that handles them.
What “orchestration” actually means
It’s worth being precise about this, because the word gets used loosely. Orchestrating AI coding agents doesn’t mean making any single agent smarter, faster, or better at writing code. It means coordinating a group of them — deciding which agent works on what, in what order, under what rules, with the results checked before they count as done. A faster car doesn’t solve a traffic problem. Orchestration is the traffic system: routing, sequencing, and the rules that keep everyone from colliding.
If you’re a developer, that group might be several specialist agents, each tagged for what it’s good at, running across a couple of machines you own. If you’re a non-technical product person, the “group” might just be one agent doing the work your team doesn’t have spare hours for — but you still need the same guarantees: that the work actually gets reviewed, that you can see where it stands, and that nothing ships without a check. Orchestration is the layer that provides those guarantees regardless of how many agents you’re running or whether you’re the one writing code.
The six problems a herd creates
None of these problems exist when there’s exactly one agent and one person watching it. They all show up, reliably, the moment there’s more than one agent, more than one task, or more than one machine in the picture.
Visibility. With one agent in one terminal, you always know what it’s doing — you’re looking at it. Scatter that across several terminals and tmux panes on different machines and there’s no single picture of who’s working on what, what’s stuck, and what already shipped. You end up polling each pane by hand, which doesn’t scale past two or three agents.
Cost attribution. Token spend on a single agent is easy to eyeball. Spend across a herd running concurrently is not — it burns with no attribution to any particular task, and you find out the total at the end of the month from an invoice that doesn’t say which piece of work was expensive and which wasn’t.
Collisions. Two agents can grab the same file, the same task, or the same branch and quietly fight each other, each unaware the other exists. Manual coordination (“I’ll tell agent A to avoid touching that file”) works until it doesn’t, usually right when you stop paying close attention.
Handoffs and context loss. Every agent session starts from a clean context. Whatever the previous run figured out — the approach it took, the constraint it hit, the decision it made and why — evaporates unless something outside the session captures it. Whoever picks the work up next has to re-derive all of that from scratch, which is slow and error-prone even for a human, let alone an agent starting cold.
Quality gates. Left alone, whatever an agent produces is what ships — review is whatever a person remembers to do themselves, under whatever time pressure they’re under that day. That’s fine when there’s one agent and one careful reviewer. It stops being fine the moment there are more tasks moving than one person can personally read every diff for.
Routing. Placing work by hand — deciding which agent should take which task — is manageable for a handful of tasks and breaks down past that. You end up either guessing or building an ad hoc spreadsheet, and either way, work sits waiting for the right agent to become free instead of moving as soon as it’s ready.
Notice that none of these are “the AI isn’t good enough” problems. They’re organizational problems that show up around good agents, the same way a growing engineering team needs process that a two-person team never did.
An operating model that works
The fix isn’t a smarter agent. It’s a system wrapped around the agents that handles routing, sequencing, and verification so a person doesn’t have to do it by hand for every single task. Here’s what that system needs to do, concretely.
Give every task a real lifecycle. Instead of “an agent does the work and someone eyeballs it,” every task should move through a defined pipeline — plan, then code, then review, then merge, then verify, then done — where each stage is a genuine gate, not a checklist step someone can skip under deadline pressure. A task shouldn’t be able to leave planning until its acceptance criteria actually exist in writing. It shouldn’t be able to leave the code stage until there’s a real, reviewable pull request. Enforcing that server-side, rather than trusting everyone to remember, is what lets the pipeline scale past the point where one person is watching every step personally.
Route work by capability, not by hand. Every agent should be tagged with what it’s actually qualified to do — a language, a role, an access level — and every task should declare what it requires. Matching them by set inclusion (an agent only claims a task when its tags cover everything the task declares) means a Go-only agent never accidentally claims a TypeScript task, and a read-only auditor never picks up work that needs write access. Claims need to be atomic, so two agents can never grab the same piece of work at once — that’s what eliminates the collision problem outright, rather than mitigating it with convention.
Track cost at the level that actually matters: the task. Aggregate workspace spend tells you the number was big. It doesn’t tell you which task was expensive, which agent burned the tokens, or which model was responsible. Cost needs to roll up per task, per agent, and per model, and it needs a hard budget cap that actually stops new work when it’s hit — not an alert that arrives after the spend already happened. A cap that takes effect at the next agent turn (letting in-flight work finish, but refusing to start anything new past the limit) turns “we went over budget” into “the system paused itself and told us.”
Make handoffs structured, not tribal. Every time a task moves between stages, the outgoing agent should be forced to leave a real note — what it did, why, and what’s still open — that the next agent inherits automatically. That’s different from hoping someone writes a good commit message. It means a fresh session, with zero memory of what came before, starts already knowing the decisions that got made and the reasoning behind them.
Give the system a memory that outlives any one session. Beyond a single task’s handoff notes, a workspace benefits from a shared, durable memory: conventions, architecture decisions, the gotcha that bit someone last week. Write it once, and every future agent session — on any task, on any machine — starts already knowing it, instead of every new session rediscovering the same lesson.
Put together, that’s the difference between “a bunch of agents running” and a fleet you can actually trust with real, unattended work.
Where non-technical builders fit
Everything above sounds like infrastructure a developer sets up — and the initial setup is, in fact, a technical step. But day to day, using it shouldn’t require touching a CLI or knowing git at all, because the whole point is that the pipeline is the interface.
If you’re a product person or a founder with an idea you know how to describe but don’t have engineering time to build, the entry point is a plain-language brief: open the web app, create a task, write a title and a description of what “done” looks like — the same brief you’d hand a human engineer. From there, you watch the work move through the same lifecycle described above: planning, building, review, merge, verification. You don’t write any code, and you don’t need to understand the pipeline’s internals to trust it, because the gates are the same ones any careful engineering team would insist on. Your job is to make the calls only you can make — approve a plan before code gets written against it, read a hand-off note when a task changes stages, accept the final result.
The honest caveat, worth stating plainly rather than glossing over: connecting the first machine that will actually run agents is a one-time technical setup. Someone — you, pairing with a technical teammate, or your IT department — needs to register that machine once. After that, your day-to-day is entirely the web app: file the brief, watch it move, approve the result. It’s not “no technical involvement, ever.” It’s “one technical afternoon, then none.”
Keeping it in your perimeter
None of this requires handing your source code or your model provider credentials to a third party, and it shouldn’t. Agents run on machines you register and control — your laptop, a cloud VM, a CI runner — and your provider key (an Anthropic API key, for instance) is configured on that machine and used directly from it. The coordination layer sees task descriptions, stage transitions, cost summaries, and structured logs; it never receives your source code, your diffs, or your provider tokens. You’re never billed for token spend through a markup — you bring your own key, and that spend goes straight to your provider’s own dashboard.
Every state-changing action — a task moving stages, a member’s role changing, a cost event — writes an append-only audit record, scoped to your workspace and queryable, so there’s a real trail of what happened and when. Credentials are scoped and revocable: an API key is shown once, stored only as a hash, and revoking it is instant. And if keeping the coordination plane itself inside your own network matters — a VPC, an on-premises deployment — that’s available as a self-host option for teams that need it, so tasks, agents, messages, and cost data never leave your environment either.
Getting started
You don’t need to solve all of this on day one. Start with the smallest version: register one machine, connect a repository, and file a single task with a clear description of what “done” looks like. Watch it move through plan, code, review, merge, and verify once, end to end, before you add a second agent or a second task. Trust builds from seeing the gates actually hold, not from reading about them.
From there, the shape of what you add next depends on which side of this you’re on. If you’re a developer already running one agent as a tool, the next step is tagging a second agent with a distinct capability and letting the routing send it the matching work automatically — see how it works for the full walkthrough of setup, capability tagging, and the task lifecycle, or why CodeHerder for the side-by-side of running agents by hand versus running them as a coordinated herd. If you’re briefing work without writing the code yourself, the use cases page walks through exactly that path, brief to shipped result, and the solo developer use case covers the other end of the spectrum — one person scaling a small fleet without a team behind them.
Whichever side you’re starting from, the features page has the full inventory of what the coordination layer actually does, pricing covers how plans are metered on concurrent agents rather than seats, and security goes deeper on the trust boundary described above if that’s the blocker for your team. When you’re ready, the work starts in the app.
Two related posts are worth reading alongside this one: one agent is a tool, a herd needs a shepherd goes deeper on the coordination problem itself, and cost-aware AI engineering is the fuller treatment of the budget and attribution problem this guide only summarizes. Together, the three cover the shift from one agent to a herd from every angle that matters — this one is meant to be the map; the other two are the terrain.
