We stopped running one coding agent. Four specialized agents ship features 3x faster.

I used to build coding agents like super-smart interns. One agent that could plan, code, test, and review. It felt elegant — why complicate things with multiple agents when one could do it all?

Then I watched it spend 47 minutes debugging a CSS issue that a dedicated reviewer would have caught in 30 seconds. The planner kept changing scope mid-task. The tester got confused about what it was supposed to verify. The reviewer rubber-stamped its own work.

So I split it into a team: Planner, Coder, Reviewer, Tester. Each with a specific role and clear handoffs. The results were immediately better — until the handoffs started failing.

The breakthrough came when I stopped thinking about agent communication and started thinking about shared context. Instead of agents talking to each other, they all read and write to the same set of files:

• AGENTS.md — Role definitions, current assignments, and work boundaries
• PROJECT.md — Current feature scope, acceptance criteria, and progress
• DECISIONS.md — Architecture choices, rejected approaches, and why
• ISSUES.md — Known problems, debugging notes, and resolution status

Here's what a working AGENTS.md looks like:

# Engineering Team Roles

## Planner (Alice)
- Breaks features into implementable tasks
- Updates PROJECT.md with scope and acceptance criteria
- Does NOT write code or review code
- Hands off to Coder when tasks are defined

## Coder (Bob)
- Implements tasks from PROJECT.md
- Updates ISSUES.md with any problems encountered
- Commits work with descriptive messages
- Hands off to Reviewer when implementation is complete

## Reviewer (Carol)
- Reviews code against PROJECT.md acceptance criteria
- Updates ISSUES.md with any problems found
- Either approves or sends back to Coder with specific feedback
- Hands off to Tester when code is approved

## Tester (Dave)
- Runs tests and validates functionality
- Updates ISSUES.md with test results
- Either passes or sends back to Coder with failing test details

The magic happens in the role boundaries. Each agent has a specific job and knows exactly when to stop. No agent-to-agent chatter. No complex orchestration. Just specialized roles with shared context.

Key insight: Agents coordinate through files, not conversations. When the Coder updates ISSUES.md with a problem, the Reviewer sees it. When the Planner updates PROJECT.md with new scope, everyone stays aligned.

This pattern scales better than single agents because each role can be optimized for its specific task. The Reviewer uses a different prompt and model settings than the Coder. The Planner focuses on architecture without getting distracted by implementation details.

It's also more reliable than orchestrated multi-agent systems because there's no complex handoff protocol to break. Each agent reads the shared context, does its job, updates the files, and signals completion. Simple.

The productivity difference is dramatic. Features that used to take my single coding agent 3-4 hours now get done in 45 minutes with the team. More importantly, the quality is consistent — the Reviewer catches issues the Coder misses, and the Tester validates what the Reviewer approves.

If you're still running single coding agents, try splitting them into specialized roles. Start with Coder and Reviewer — just those two will catch 80% more issues. Add the Planner when scope creep becomes a problem. Add the Tester when you're tired of shipping broken features.

The shared context files are the secret. Without them, you're just running multiple confused agents. With them, you have an actual engineering team.