The default way most teams use AI agents: one assistant, all tasks. You ask it to analyze requirements, write code, write tests, review the PR, and draft the PR description. In the same chat. With the same context. Back to back.
This works until it doesn’t. And when it doesn’t, the failure is hard to see — the agent produces something plausible-looking that misses the real problem, because it’s been asked to hold too many contexts at once.
We spent six months building a 15-agent system for our engineering team. Here’s what we learned about why specialists beat generalists.
The three problems with a single generalist agent
Context dilution. A generalist agent carries everything in its context window simultaneously. Requirements analysis patterns, code generation conventions, test strategy heuristics, PR formatting rules. Each competes for attention. The rules that matter for this task are buried in noise from every other task.
Inconsistent quality gates. A generalist agent reviews its own work. Ask it to write code and then review it in the same session and it’ll find problems — but not with the same rigour as a dedicated reviewer who hasn’t spent the last 20 minutes writing the thing. Self-review has a well-documented blind spot problem.
No structured handoffs. When context needs to move between phases — from requirements analysis to implementation to testing — a generalist agent just keeps going. There’s no checkpoint, no validation that the handoff package is complete, no structured confirmation that what’s coming in to the next phase is what’s needed.
What specialists give you
Deep domain knowledge, narrow scope. A @code-backend agent has C# patterns, .NET conventions, security rules, and nothing else. It doesn’t have frontend naming conventions cluttering its context. It doesn’t have PR formatting templates competing for attention. Everything it knows is relevant to the current task.
Role-based quality gates. @author-code reviews code. It doesn’t write it. This separation isn’t philosophical — it means the reviewer brings fresh context, applies a different lens, and can rate without attachment to the output. A reviewer that didn’t write the code will catch different problems.
Intake checks at every handoff. When @story hands work to @code-backend, the backend agent validates the handoff before starting. Does it have the story ID? The plan file? The acceptance criteria? If not, it reads the saved plan. Only as a last resort does it ask the human. Structured handoffs mean context is preserved, not reconstructed.
The AI agent orchestration layer
Specialists without orchestration are just multiple chatbots. The orchestrator is what makes them a system.
In our framework, @story is the orchestrator for single-story implementation. It:
- Reads the story from ADO
- Detects scope (backend, frontend, full-stack)
- Routes to the appropriate specialist agents
- Saves the story plan to disk so any agent can resume mid-flight
- Manages the dev/QE split so two people can work the same story on the same branch
The orchestrator doesn’t write code. It thinks, routes, and coordinates. The specialists don’t think about routing. They execute.
This separation keeps each agent’s context small and its behaviour predictable.
The model selection corollary
Once you have specialists, you can match models to jobs:
- Orchestrators need deep reasoning — Claude Opus. They run infrequently and their outputs determine everything downstream.
- Implementers need speed and throughput — Claude Sonnet. They run frequently, produce large outputs, and correctness is verified by reviewers.
- PR formatting is deterministic enough for a smaller model — GPT-5.4 mini. No reasoning required.
A generalist architecture forces you to pick one model for everything, or context-switch uncomfortably mid-conversation. A specialist architecture lets you right-size the model to the job.
The tradeoff
Specialists add coordination overhead. You need orchestrators. You need handoff protocols. You need to think carefully about what each agent owns and where the boundaries are.
For a single developer doing exploratory work, a generalist is fine. The overhead isn’t worth it.
For a team running the same structured workflow repeatedly — story intake, implementation, testing, review, PR — the overhead pays for itself quickly. The quality gates catch problems early. The structured handoffs mean QE doesn’t start from scratch. The specialist context means every agent is operating with high signal.
The question isn’t “generalist or specialist.” It’s “how often does this workflow run, and what does a missed quality gate cost?”