I Let a Team of AI Agents Ship My Feature

One agent writing code is yesterday's news. The interesting question in 2026 is what happens when you hand a task to five of them at once - and whether the result is a symphony or a food fight. I tried it on a real feature. Here is what actually happened.

The wall every single agent hits

A single AI agent is bounded by one thing you cannot prompt your way around: its context window. Ask one agent to review a 40-file pull request, and by file 25 it has quietly forgotten what file 3 looked like. Ask it to migrate a codebase, and it starts confidently repeating work it already did.

The problem is not intelligence. It is working memory. And the fix is the same one humans found a century ago: stop hiring one genius, and start running a team.

That is the shift happening across AI engineering right now. Single-agent workflows are giving way to orchestration - a lead agent that plans, delegates, and synthesizes, plus a pool of specialized workers that each see only their slice of the problem.

The building blocks

Before the war story, the vocabulary. Multi-agent setups in Claude Code boil down to four pieces:

• The orchestrator. The main agent you talk to. It never does the heavy reading itself - it decides what needs doing, splits the work, and merges the results.
• Subagents. Fresh agents spawned for one task each. They start with a clean context, do their job, and return only a summary. The raw noise of their exploration never pollutes the orchestrator's memory.
• Fan-out. Launching several subagents in parallel on independent slices - one per module, one per review dimension, one per search strategy. Wall-clock time drops to the slowest worker instead of the sum of all of them.
• Adversarial verification. The step almost everyone skips. Before trusting a finding, you spawn a second agent whose only job is to refute it. Plausible-but-wrong results die here instead of in production.

If you read my earlier post on skills versus agents, subagents are the "worker" side of that distinction taken to its logical end: not one worker, but a staffed team.

What I actually ran

The feature was on this very blog: reworking how post pages load so navigation feels instant. On paper, a one-agent job. In practice it touched routing, caching, prefetching, and a handful of components - exactly the shape of task where one context window starts to fray.

So instead of one long session, I ran it as a team:

1. Two explorer agents in parallel. One mapped every place the post pages fetched data. The other dug through how Next.js caching actually behaves, because my assumptions were two versions out of date. Each came back with a tight summary instead of forty files of noise.
2. One planner agent. It took both summaries and produced the implementation plan - which pages go static, where revalidation happens, what could break.
3. The orchestrator implemented. With clean context and a plan, the actual code changes were the easy part.
4. A reviewer agent I told to attack the work. Not "review this", but "find the scenario where this breaks". It found one: a page that would serve stale content after publishing a new post. That bug would have shipped.

Total wall-clock time: about the length of one coffee. The same task as a single monolithic session had failed twice before - not with errors, but with that slow drift where the agent starts contradicting its own earlier decisions.

What went wrong

Honesty section, because every multi-agent writeup needs one:

• The two explorers overlapped. I scoped them lazily, so both read the same three files. Wasted tokens. Scoping the split is your job, not the model's.
• Summaries lose detail. One subagent compressed away the exact line number the planner needed, and the planner guessed wrong. If a detail is load-bearing, tell the subagent explicitly to preserve it.
• It is not cheaper. Five agents burn more tokens than one. You are trading tokens for reliability and time - a good trade on hard tasks, a terrible one on easy ones.

When not to do this

The fastest way to look silly with multi-agent orchestration is to use it on a task one agent handles fine. Skip the team when:

• The task fits comfortably in one context - a bug fix, a single-file change, a rename.
• The steps are strictly sequential - parallel workers cannot help if step 2 needs step 1's output.
• You cannot describe the split - if you cannot say what each worker owns, the orchestrator cannot either.

A decision table, because I like decision tables:

Situation	Reach for
Small, well-scoped change	One agent, no ceremony
Large read, small write (audit, review, research)	Fan-out explorers + one synthesizer
Large write across many files	Orchestrator + workers, one worker per area
High-stakes conclusion	Add an adversarial verifier, always

A starter checklist

If you want to try this on your next oversized task:

1. Write one sentence per worker describing what it owns. If you cannot, the task is not ready to split.
2. Make workers return summaries, not transcripts. Tell them what details to preserve.
3. Run independent workers in parallel. Sequential subagents are just a slower single agent.
4. Add one skeptic. For anything you will act on, spawn an agent whose only goal is to prove the finding wrong.
5. Keep the orchestrator's hands clean. The moment it starts reading forty files itself, you are back to square one.

The team is the tool

The mental shift that matters: stop thinking of the model as a very smart intern, and start thinking of it as a very cheap staffing agency. The intelligence was never the bottleneck - the working memory was. Orchestration is how you spend a little more money to stop hitting it.

Ask yourself one question before your next big task: can I split this into slices that do not need to talk to each other? If yes, you have a team. If no, you have a job for one agent - and that is fine too.