I Run 4 Coding Agents at Once: My Full Orchestration Setup

SecondShiftDev — Sat, 07 Nov 2026 06:31:41 +0000

I Run 4 Coding Agents at Once: My Full Orchestration Setup

Watch the video version here: I Run 4 Coding Agents at Once: My Full Orchestration Setup (8 minutes, 9 seconds). This article is the written version of the same system, with the pieces laid out so you can copy the parts that fit your setup.

The problem is management, not models

Leave one AI coding agent alone for an hour and you get a chaotic intern. Fast, eager, weirdly confident, and every so often completely wrong. Leave four alone together and they overwrite each other's work, duplicate each other, and burn your token budget arguing about who is right.

I run four coding agents at once: Claude Code, Codex, Antigravity, and Hermes. None of them runs unmanaged. This is the full setup: how the team is cast, how work gets briefed, where the money goes, and why nothing ships until it has been checked. It is about managing agents like a team, not about which model is best.

1. The cast: one orchestrator, the rest are workers

Rule one: not every agent gets to be a general purpose coder. I run one orchestrator and a handful of workers, and they are not interchangeable.

The orchestrator is the only agent I actually talk to. Its job is not to write the most code. Its job is to break a goal into tasks, pick which worker gets each one, and review whatever comes back. Tech lead, not typist.

Workers get exactly one assigned task each. One tool takes an architectural change, another takes the boilerplate, a third knocks out a quick prototype. A worker does not need the ten thousand foot view. It needs a brief it cannot misread.

Splitting the thinking from the doing is the whole trick. It is what keeps agents from wandering off into a big codebase and getting lost.

2. Roles before tools

The mistake I see everywhere in this space is model chasing. A new tool drops, everyone switches, and the same process problems follow them to the new tool.

In a multi agent setup, the role matters more than the model. Every time.

Roles are defined by the work. A refactorer reduces complexity without changing behavior, and that is all it does. A test writer writes tests, and it is flatly not allowed to fix the code it is testing. A feature implementer builds to a spec. Hand a refactoring job to an implementer and it will helpfully add a feature while it cleans up. Now your cleanup has a bug in it.

The useful part is that tools can swap in and out of a role whenever pricing or performance changes. The role and its boundaries stay put. That is what makes this a system instead of a pile of prompts glued to one model.

3. The packet: briefs an agent cannot misread

Open ended prompts are where agents drift. So I do not send prompts anymore. I send packets.

Every task that goes from the orchestrator to a worker is a self contained brief, and it always has the same five parts:

Goal. One sentence. What done looks like.
Context. The specific files, signatures, and constraints that matter. Not the entire codebase dumped in for luck.
Steps. The sequence I expect the worker to follow.
Output format. Exactly what comes back: a diff, tests, a summary, in a stated shape.
Verification. Stated up front, so the worker knows from the start that its work will be tested, not trusted.

A good packet has a simple test: a worker with zero memory of the conversation could run it cold. When a worker fails, I do not type "try again" and cross my fingers. I fix the packet. Nine times out of ten, the failure was in the brief, not in the model.

4. Cost routing: pay for judgment, not for typing

Run four agents on top tier models for everything and you will set money on fire. Work gets routed by how much judgment it actually needs, not by habit.

The bulk work goes to fast, cheap models: docs, type updates, boilerplate, first drafts, summaries. That work is pattern matching. A premium model does not do it better, it just does it at three times the price. Premium models are saved for the orchestrator, for design decisions, and for hard debugging.

I track spend per task too. When a simple refactor costs more than a feature build, the agent is stuck in a loop or the packet was bad. Cost is a diagnostic. Treat it like one.

5. Verification before trust

This is the load bearing wall of the whole setup. Nothing merges because a worker says it is done. Agent output is guilty until proven innocent.

Verification happens in three stages:

Tests. The worker ships tests with its code, runs them, and reports the real output. Failures included. Especially failures.
The diff. No agent commits straight to the main branch, ever. Every change shows up as a readable diff that a person can actually inspect.
A reviewer agent. A different model from the one that wrote the code, read only access, one job: find what is wrong. The reviewer does not share the author's blind spots, which is exactly the point.

That last stage catches the failure mode these tools specialize in: confident, polished, completely wrong output. A worker's report is a claim. Tests and diffs are evidence. Run on evidence.

6. Rules in CLAUDE.md, not in chat history

Agents forget. Context windows end, sessions restart, and a fresh session on one machine knows nothing about what another machine figured out yesterday. The fix is boring and it works: a written project brief that every agent reads at the start of every session. In Claude Code that file is CLAUDE.md.

Mine has four kinds of content:

The exact commands to build and test, written as "run these, not guesses."
The conventions that actually matter for that project.
The boundaries: what never gets edited, what never gets logged, where the secrets live.
A definition of done, so "done" stops being a matter of opinion.

I am picky about what goes in. Rules of the game, yes. State of the game, no. Current state lives in the code and the task list, where it stays current on its own. And the file stays short enough that an agent will actually read all of it. Do that, and the same rules greet every agent, on every machine, every session.

Why this exists: the honest failure

Early on I pointed two agents at one bug, with no roles, no packets, and no reviewer, and told them to collaborate. One changed the code. The other reverted it and applied its own fix. Then the first one reapplied its version. Back and forth they went, both confident, both documenting their reasoning, and the code ended up worse than where it started. Plus a token bill for the privilege.

More agents had just made more noise. Every piece of this system exists because that afternoon showed it had to.

Get the Starter Pack

The free Multi Agent Starter Pack is the three CLAUDE.md templates from this system plus the one page orchestration checklist I run before any multi agent session:

Download it on GitHub: https://github.com/second-shift-dev/multi-agent-starter-pack
Or get it by email and join the Second Shift Dev list for new videos and the December launch of the full Multi Agent Coding Ops Kit: https://second-shift-dev.kit.com/f1a6475d0f

The video version of this article is here if you want to see the setup walked through: https://www.youtube.com/watch?v=hUVGVdimCRw

The day job ends. The agent team clocks in.

Second Shift Dev

DEV Community: SecondShiftDev

I Run 4 Coding Agents at Once: My Full Orchestration Setup

I Run 4 Coding Agents at Once: My Full Orchestration Setup

The problem is management, not models

1. The cast: one orchestrator, the rest are workers

2. Roles before tools

3. The packet: briefs an agent cannot misread

4. Cost routing: pay for judgment, not for typing

5. Verification before trust

6. Rules in CLAUDE.md, not in chat history

Why this exists: the honest failure

Get the Starter Pack