At some point the number of concurrent Claude Code agents stopped feeling like a milestone and started feeling like a unit of measurement. Today that number was 34.

Here’s what actually happened.

Why 34

It wasn’t planned. It grew.

Started with a few background agents handling repo cleanup while I worked on something else. Then I needed research across multiple projects simultaneously. Then the research agents spawned sub-agents. Then a few agents were babysitting other agents that had gotten stuck.

34 isn’t a record or a goal — it’s just where the session ended up when I finally counted. The more interesting question is: what were they all doing, and did it work?

The Stack

Orchestration:
 - 1 primary session (me, interactive)
 - 6 project-level orchestrators (one per active repo)
 - 12 research agents (parallel web search + analysis)
 - 8 code agents (active builds, migrations, fixes)
 - 5 background agents (monitoring, cleanup, watching for failures)
 - 2 "meta" agents (audit + synthesis)

The orchestrators were the key. Each project had a single agent tracking what the other agents in that project were doing. Without that layer, I’d have no idea which agents had finished, which were blocked, and which had gone in circles.

What Actually Shipped

Across all repos, today’s git log shows:

babel-voxtral-tts: Voxtral TTS integration scaffolded — reads Library of Babel books aloud
bythewei: Shadow Trooper skill audit (IT-0003) — scored all skills, found the broken ones
AgentManagementPublic: Agent registry updated, 34 new entries
autoresearch-mlx: MLX training run completed, checkpoint saved
skills rebuild: 3 skill files rewritten based on audit findings

Not bad for one session. The agents weren’t just running — they were shipping.

What Broke

Context bleed. Two agents working on related files started making contradicting changes. No locking, no coordination on file ownership. Fixed by assigning explicit file-level ownership: if agent A is editing config.ts, agent B can read it but not write it until A is done.

Zombie agents. Three agents had technically “finished” but their processes were still alive, consuming tokens on nothing. Added explicit exit conditions to the skill files: if there’s nothing left to do, say so and stop.

The “I’ll handle it” problem. Multiple agents decided to fix the same bug independently. Wasted work. The orchestrator layer is supposed to prevent this but it only works if agents check in before starting work, not just when done.

The Orchestration Pattern That Works

After enough sessions like this, a pattern has crystallized:

1. Decompose the session into independent work units
2. Assign one agent per unit with explicit scope (files + goals)
3. One orchestrator per project cluster
4. Agents report status via a shared artifact (file, JSON, git log)
5. Orchestrator checks for conflicts before dispatching new work
6. Human reviews at natural checkpoints, not continuously

The hardest part is step 2. “Independent” work units aren’t always obvious. Two features can look independent but share a config file. Spend 5 minutes mapping dependencies before spawning anything.

The Surprising Part

The agents didn’t need much supervision.

I expected to spend the session firefighting — catching agents going off the rails, redirecting confused ones, babysitting. Instead I mostly reviewed diffs and answered a handful of questions. The agents were more self-correcting than I expected. When they hit a wall, they’d describe the wall and wait rather than thrashing.

Maybe the skill files are working. Maybe the model is just better at knowing when to stop. Either way: 34 concurrent agents and I didn’t feel overwhelmed. That’s the benchmark that actually matters.