Splitting an AI Coding Agent Into Specialists
The default way to use an AI coding agent is one agent with every tool, handed a task. It works, and then it stops working as the task gets bigger. The failure is not that the agent is bad at any single step. It is that everything it read while doing step one is still in the context window during step four, and that the same actor that decided what to build is the one deciding whether what it built is any good.
Splitting it into specialists with deliberately restricted tools fixes both. This is how I have it set up for building n8n workflows, and the reasoning generalises.
The problem with one agent
Building a workflow means browsing a template library, reading node schemas, constructing the thing, validating it, and checking the result. A single agent doing all of that accumulates every intermediate artifact it touched. Node schemas are verbose. Template listings are verbose. By the time it is making the decisions that matter, most of its context is search results it no longer needs.
There is a second, less obvious problem. An agent that has just spent twenty minutes building something is the worst possible reviewer of that thing. It knows what it meant. It will read its own intent into ambiguous output.
The split
Three agents, each with one job.
The scout is read-only research. Given a build intent, it returns a ranked shortlist of two or three candidate templates or node types, with IDs, a one-line rationale each, and the credentials the caller will need. It browses everything and returns a paragraph. It cannot create, modify, or delete anything — it does not have the tools.
The builder takes that shortlist and constructs the thing. It creates or edits, wires the project's standard error-handling pattern onto every fallible node, validates, and then re-reads the structure to verify the wiring actually landed. It hands back an ID and a summary.
The auditor is read-only health checking. Given a workflow ID, it returns a pass/fail report on validation, wiring integrity, error-routing completeness, and naming conventions. It never modifies anything.
The main thread orchestrates and makes decisions. The token-heavy browsing happens somewhere else and returns a summary.
The tool list is the specification
This is the part that took longest to appreciate. The prose in an agent's definition is a suggestion. The tool list is enforcement.
The builder agent's definition says, in as many words, that it never tests and never activates anything. That sentence is not what makes it true. What makes it true is that the agent's tool list contains no test tool, no activate tool, and no delete tool. It could not activate a workflow if it decided it should.
The comment in its definition is explicit about this being deliberate rather than an oversight: it has no test tool, no activate, and no delete tool on purpose. Every workflow it produces is a validated inactive draft, waiting for a human to test and turn on.
An instruction like "do not activate the workflow" is a request. A missing activate tool is a guarantee. When an agent is running unattended, that difference is the entire safety story.
A builder that cannot ship
The most useful constraint in the whole arrangement is the one that sounds like a limitation: the builder is forbidden from making anything live.
The temptation is obvious. The agent just built and validated the thing, it is right there, activating it is one more call. But "validated" and "working" are different claims. Validation checks structure. It does not check that the credentials resolve, that the upstream API returns what you assumed, or that the error path fires.
So the builder's terminal state is a validated draft plus a summary, every time. A human tests it and turns it on. The agent that is most confident the work is good is structurally prevented from acting on that confidence.
This also gives the arrangement a natural review checkpoint. There is a moment, by construction, where a person looks at the output before it can affect anything.
Read-only agents are not a lesser thing
Both the scout and the auditor are read-only, and both are more valuable than they look.
The scout exists because search is expensive in tokens and cheap in conclusions. Browsing a template library might mean pulling many results to decide that two are worth considering. Doing that in the main thread means carrying all of it forward. Doing it in a subagent means carrying forward three lines.
The auditor exists because verification by the builder is not verification. It comes to a workflow with no memory of building it, no investment in the choices, and no ability to change anything to make its own report look better. It can only report.
What this actually costs
Honest accounting, because the pattern is not free.
Every subagent starts cold. It re-derives context the main thread already has. If a task is small enough that the main thread could just do it, spawning an agent is strictly more expensive — a one-line parameter change should go direct, not through a builder.
The interface has to be real. "Return a shortlist" only works if the shortlist has a defined shape: IDs, rationale, required credentials. Vague handoffs between agents produce vague work, and you cannot debug it by reading one agent's transcript.
Three agents is three definitions to maintain. When a convention changes, it changes in more than one place, and they drift if you let them. The mitigation is to have the agents reference shared skill files rather than restating rules inline — the definition says which rules to follow and where they live, not what they are.
The generalisation
None of this is n8n-specific. The shape is:
- Research is read-only and returns a summary, not its inputs.
- Construction is separated from activation, and the separation is enforced by the tool list, not by instructions.
- Verification is done by something with no stake in the result.
If you take one thing: when you want an agent not to do something, do not tell it not to. Take the tool away.