You know the pattern. You open a chat with your AI assistant to fix one bug, and by message ten it's rewriting tests nobody asked for, poking around in files two directories away, and telling you the bug is fixed without showing its work.
Most engineering teams already agree on what good AI-assisted work looks like: small diffs you can actually review, tests that test something real, bugs reproduced before anyone touches a fix. The problem with one open-ended chat window is that it's playing architect, implementer, tester, debugger, and reviewer at the same time. Agent trying to fulfill these five roles and is not going to be great at any of them.
Teams that have made it past the demo stage have mostly abandoned the single-assistant setup. The fix wasn't a smarter model. It was splitting the work across several narrow agents, each with one job and a hard rule against doing anyone else's. Done well, that changes how the work gets organized in the first place, not just how fast it moves.
Ask around and you'll hear the same complaint from teams running these setups in production: a general assistant holds up fine for small, self-contained tasks and starts to struggle as soon as a task has any real shape to it. Narrower roles cut down on drift and rework right at the point where things start to matter.
The idea itself isn't complicated. Stop asking one assistant to do everything. Treat AI as a set of roles, each with its own boundaries, and put a review step at every handoff. The discipline is in sticking to it once the deadline is tight and it would be faster to just ask the one assistant to "also fix the tests while you're in there."
Where narrow agents help
Four kinds of engineering work respond well to a single-purpose agent: implementation, testing, bug diagnosis, and research. Each one has a clean definition of done, and that's what keeps the agent narrow. Take the definition of done away and it starts drifting into everything adjacent.
Implementation
A general assistant told to "fix this" has to guess how far to go. Refactor the function while it's in there? Rename a variable to match some convention it half-recognizes? Left alone, scope creeps almost every time.
An implementation agent doesn't have that problem, because its brief never moves: make the smallest change that satisfies the requirement, in the style the file already uses. Hand it the target code path along with nearby patterns to match, tell it not to touch tests, and run lint and type checks right after the first real edit rather than waiting until the end.
You are an implementation agent.
Search the codebase for similar patterns before editing.
Make the smallest change that satisfies the requirement.
Follow the existing file's style and imports.
Do not expand scope after a failed check.
Do not write or modify tests.
What comes out the other end is a small, legible patch. You can review it the way you'd review a new hire's first pull request, not something you have to untangle before you can even start.
Testing
A test-writing agent is a different animal from a general assistant asked to "add tests," which tends to produce a grab bag: unit tests, integration tests, a couple of speculative assertions about implementation details, all mashed into one pass. Give the job to an agent whose only mandate is coverage on the code that actually changed, using the fixtures your team already has, and the output gets a lot more predictable. Point it only at the changed files, tell it to prefer parametrized cases over near-duplicate tests, and be explicit that production code is off-limits, even if it's convinced it's found a bug.
You are a test-writing agent.
Target full coverage on the files changed in this diff.
Use existing fixtures and mocking patterns, do not invent new ones.
Prefer pytest.mark.parametrize over repeated near-duplicate tests.
Do not modify production files.
If you believe the implementation is wrong, report it instead of fixing it.
That last line matters more than it looks like it should. Leave it out, and a testing agent will quietly rewrite behavior until its own tests pass.
Bug analysis
A general assistant is most likely to trip up here, jumping straight to a plausible-sounding fix without confirming what's broken. It's a reasonable instinct for a chat assistant that's trying to be helpful, but it's a bad habit to have running anywhere near production.
A bug-analysis agent has one job: reproduce the failure and explain it, then hand the fix off to someone else. Give it the bug report, the relevant logs, and enough of the codebase to trace the failure path. Ask for a minimal, deterministic reproduction; don't accept a narrative guess. And take editing production code off the table entirely, even when the fix looks obvious. Handed to an implementation agent afterward, a report like that turns a vague ticket into something scoped and reviewable. It stops being a guess dressed up as a fix.
Research
Vendor docs, API changes, library quirks: another spot where breadth works against you. Whether an API supports pagination is a question a general assistant will often answer from memory, and that memory tends to be a version or two behind whatever you're running. A research agent scoped purely to fact-extraction sidesteps most of that, mostly because it isn't also trying to write code in the same breath. Point it at official documentation rather than general web search. Ask it for a structured comparison table, not a written summary, and have it flag what it couldn't verify rather than quietly paper over the gap. The payoff shows up the first time a claim traces back to the actual page and not somebody's memory of it.
What shouldn't go to a narrow agent
None of this means every task benefits from a narrow role, or that people disappear from the process. Some work genuinely needs breadth, and some decisions must stay with whoever owns the outcome.
Exploration and brainstorming
An unfamiliar codebase, early design options, a "how does this system even work" question: these want an assistant that can range across a whole conversation, not one boxed into a single role. A general assistant is still the right tool for that first orientation pass, before there's a specific task to hand off.
Deciding when to hand off
Somebody still must judge when a bug-analysis agent's report is solid enough to pass to implementation, or when a research agent's gaps mean a human needs to dig further. No agent gets to make that call, narrow or general. That's on whoever owns the workflow.
Final review of production changes
A specialized agent can tell you a patch passed its checks. It can't tell you the change is safe to ship, that it matches what the ticket intended, or that it won't blindside another team relying on the same code path. That judgment stays with an engineer, no matter how well-behaved the agent producing the diff turns out to be.
A practical way to split the work
None of these matters unless it changes what you actually build. For any recurring task, decide whether it belongs to "specialize" or "keep broad."
- Specialize: implementation, test writing, bug reproduction, documentation research. Anything with a clear definition of done.
- Keep broad: early exploration, design brainstorming, and any call on whether something ships.
For the specialized roles, write the boundary down. Say what the agent should do, and just as important, what it must never touch. Give it only the context that job needs, not the whole codebase. Review its output the way you'd review a focused pull request from a new hire assigned to exactly that role. Over time you spend less effort untangling one sprawling AI conversation, and more time deciding whether the workflow itself is producing the right artifacts.
Three agents, one bug fix
Here's a real example: a CSV import job silently drops rows where a numeric field has a thousands separator, like "1,204."
With one general assistant, this usually turns into a single long thread: paste the bug, get a plausible fix, maybe remember to ask for a test, and hope the fix addresses what was reported rather than what the assistant assumed.
Split across roles, it plays out differently. The bug-analysis agent gets the report and the parsing code, with one instruction: reproduce, and nothing else.
You are a bug-analysis agent.
Reproduce this failure: CSV import drops rows where a numeric field
contains a thousands separator, e.g. "1,204".
Write a minimal failing test case.
Identify root cause with evidence.
Do not modify production code.
It comes back with a failing test and a one-line root cause: the parser splits on commas before it ever reaches the numeric field. That report, not the original vague ticket, is what goes to the implementation agent.
You are an implementation agent.
Fix the root cause described in this report: [root cause + failing test].
Make the smallest change that satisfies it.
Do not write or modify tests.
Once the patch lands, the testing agent takes the changed file and the original failing test and brings coverage on that function up to standard, without touching anything else.
Nobody had to babysit any of these agents' reasoning along the way. What comes out is three small artifacts: a root cause report, a minimal patch, a coverage summary. Each one is easy to check on its own. Compare that to one transcript where diagnosis, fix, and testing are all tangled together.
The takeaway
Let narrow agents handle bounded work: focused patches, targeted test coverage, bug reproduction, structured research. Anything with a clear definition of done and a manageable amount of context is fair game.
Keep a general assistant, or a person, on the open-ended stuff: early exploration, design tradeoffs, and the call on whether something is ready to ship.
A junior engineer with a clear brief moves faster than one handed something vague. Same logic here. Open-ended work still needs judgment about the system, the team, and the cost of getting it wrong, and that has to stay with a person.
Get the split right and this stops being a slide in a deck. In practice it just means fewer 40-message threads where you've lost track of what the model already tried, and more small, checkable pieces of work landing at the pace your review process can keep up with.
.webp)
