How We Orchestrate 100+ AI Coding Agents With Claude Code

Most teams using AI coding tools are still in the one-assistant era: a single chat window, one task at a time, the developer waiting on each answer. The more interesting shift is fleets — one orchestrator decomposing a big job and fanning it out to dozens of workers running in parallel.

The unlock, popularized by a Towards Data Science piece on orchestrating 100+ agents with Claude Code, is simple: Claude Code has a headless mode. Run

claude -p "your task here" --output-format json

and a full agent session becomes a plain CLI process that works alone and exits with a structured result. If an agent can be launched like any other process, an agent can launch other agents. You stop talking to workers and talk to one orchestrator that spawns them, reads only their outcomes, and merges.

We liked the idea enough to build our own version into our codebase. This post is that version — not a summary of someone else's workflow, but the system we actually run, with the opinions we added after using it. Three of those opinions do most of the work.

Opinion 1: escalate through tiers, don't default to a swarm

A hundred agents on a job three could handle is waste with better marketing. Cost scales linearly with workers, so our playbook makes the smallest sufficient option the first choice:

Tier 1 — subagents inside one session. For up to roughly ten units of work, built-in subagents are enough. We defined four repo-specific workers, each with its own scoped prompt and tool access: a content writer, an SEO and structured-data specialist, a frontend builder, and a QA verifier. The orchestrating session spawns them in parallel and merges their output.

Tier 2 — headless fan-out. Past ten tasks, one command takes over: our runner reads a JSON file of { id, prompt } tasks, spawns parallel headless sessions with a concurrency cap, and writes each result to its own file plus a run summary. This is the 100-agent territory. Each worker gets a fresh context and can even get its own model — mechanical batch work goes to a cheaper, faster model; judgment-heavy tasks keep the strong one.

Tier 3 — git worktree isolation. Parallel agents editing the same files clobber each other. When tasks overlap, each one gets its own git worktree and branch. Workers edit in isolation; the orchestrator reviews every branch, merges the good ones, and resolves conflicts once instead of losing work silently.

Escalation is a decision, not a default. Twenty local-SEO city pages earn tier 2. A single feature does not.

Opinion 2: guardrails belong in the tooling, not the prompt

The standard advice for headless workers is "prompt them carefully." We think that's fragile — on a fleet of fifty, someone will eventually forget a rule in one prompt, and that one worker will commit half-finished work or wander out of scope. So our runner enforces the rules mechanically:

• Every worker prompt gets a house preamble injected automatically: read the repo's agent instructions first, never commit or push (the orchestrator owns git), stay strictly inside the assigned task, and finish by reporting files changed and how they were verified. Nobody has to remember to say it, because the tool says it every time.
• Workers run with edit-only permissions by default. They can modify files — that's the job — but nothing broader. The unrestricted mode exists for special cases, and the runner refuses to enable it outside an isolated worktree. An unsupervised agent can never run loose in the shared repo.
• A dry-run flag prints every task, model, and setting before a single token is spent. Fleet runs get previewed the way deploys get previewed.

None of this makes the agents smarter. It makes their failure modes boring, which is the property you actually want at scale.

Opinion 3: a fan-out isn't finished until a machine says so

Fifty agents returning code is not a result — it's a pile of unreviewed changes. Our runner has a verification flag that, after the last worker finishes, runs the repo's full CI-equivalent gate — formatting check, linter, production build — and records pass or fail for each in the run summary. If anything fails, the run itself reports failure. On top of that, a dedicated QA agent reviews the merged diff against our project rules before a commit exists, and a human reviews after that.

The pipeline is: decompose → fan out → machine verification → agent review → human review → commit. Every stage can reject. That ordering is the difference between a workflow and a backlog.

What this looks like day to day

A batch job in this setup is three commands: write the task list, preview it, run it with verification on. The orchestrator session then reads the summary, inspects only the failures, merges, and commits once. The workers' logs go unread unless something broke — outcomes over transcripts.

Why a business should care

This is a developer technique, but the architecture is the same one we use when we build AI systems for clients: one reliable coordinator, many narrow workers, guardrails enforced by the system rather than by hoping everyone prompts well, and a verification gate before anything touches production. Document processing, content operations, data migration — it transfers directly.

If your team is experimenting with AI agents and the results feel chaotic, the fix is usually not a smarter model. It is orchestration: smaller task definitions, isolation between workers, rules the tooling enforces, and a merge step that a machine — then a human — actually checks.

We build this kind of system for companies in the Philippines and abroad. If you want to talk through where agent fleets fit in your own operations, get in touch.