Subagents Need Separate Prompts

Subagents are recursive agents. One agent starts a narrower agent for a smaller task, with a different prompt and sometimes a different model. That is the useful model.

Teams often treat subagents as a speed feature. They are really a control feature. They split work by intent: one agent plans, another edits, another checks, another summarizes. If every layer uses the same prompt and model, you usually get more noise, not more leverage.

The pattern is simple. Use the outer agent to decide what to split, then give each subagent one job, one output shape, and one stop rule. A subagent should not be asked to “help with the feature.” It should be asked to “find the failing test,” “rewrite this function,” or “compare these two implementations and report the difference.”

Why recursion helps

Coding work is not one kind of work. Some steps need broad context. Others need narrow execution. A planning agent benefits from a larger context window and a more deliberate prompt. A patching agent may do better with a tighter prompt and a cheaper or faster model. A review agent may need a different instruction set entirely, because its job is to look for mistakes rather than produce code.

That separation reduces prompt conflict. A single agent asked to plan, code, test, and explain often drifts between modes. A subagent chain keeps those modes apart. The outer agent stays high-level while inner agents stay local.

There is a tradeoff. Every extra layer adds coordination cost. Recursive agents can waste time if the task is small, if the split is obvious, or if the handoff is vague. In those cases, a direct edit is better.

A practical structure

A workable setup usually has three layers:

• A planner that decides whether to split the task.
• Task agents that do one bounded job.
• A reviewer that checks the result against the original goal.

The boundary matters more than the count. Each handoff should include only the context needed for the next step. If a subagent gets the whole conversation, the recursion advantage shrinks.

For example, in an agent IDE or CLI, you might use one agent to inspect a failing test suite, then spawn a second agent to patch the smallest likely cause, then a third to rerun the relevant checks and summarize what changed. The same pattern works across tools. The names differ. The workflow does not.

When to use different models

Different prompts are the first lever. Different models are the second.

Use a stronger model when the task needs synthesis, ambiguity handling, or architectural judgment. Use a cheaper or faster model when the task is mechanical: search the tree, rewrite a function, extract a diff, or summarize logs. That is not a universal rule. Some smaller models are better at narrow tasks than larger ones if the prompt is tight and the output format is constrained.

The practical test is simple: if the subagent’s job can be checked quickly and the cost of a mistake is low, a lighter model is often enough. If the subagent is making a decision that will shape later work, spend more.

Implementation steps

Start by defining the task boundaries in plain language. Write down which steps should never be delegated and which steps are safe to split.

Then create prompt templates for each role. Keep them short. A planner prompt should ask for decomposition and risk flags. A patch prompt should ask for one change and no extra refactors. A review prompt should ask for correctness, regressions, and missing tests.

Next, define the handoff payload. Include the minimum useful context: file paths, failing output, relevant constraints, and the exact question. Avoid passing the full chat unless the task truly depends on it.

Finally, add a stop condition. A subagent should know when to stop searching, when to return uncertainty, and when to escalate. Without that, recursive agents can loop on low-value exploration.

Where this breaks

Subagents are weaker when the task is highly coupled. If the answer depends on many files, hidden product constraints, or a subtle system-wide invariant, narrow agents may miss the shape of the problem. In those cases, the outer agent needs to stay involved longer.

They also break down when teams over-automate delegation. Not every subtask deserves its own agent. If the overhead of spawning, prompting, and reviewing exceeds the work itself, you have added ceremony.

Another limitation is evaluation. Teams often measure success by whether the agent produced output, not whether the output reduced human work. That is the wrong metric. A subagent that returns a confident but unhelpful answer is worse than no subagent at all.

A useful rule of thumb

If you cannot describe the subagent’s job in one sentence, it is probably not ready to delegate.

That rule keeps recursion honest. It forces you to separate planning from execution and execution from review. It also makes the prompt and model choice easier, because each layer has a narrower purpose.

Methodology note

This is a Build question more than a theory question. The useful next step is to wire one small recursive path into a real task and see where the handoff fails. That kind of check is usually more revealing than debating agent structure in the abstract. We use that same bias toward concrete iteration in our methodology.

Bottom line

Subagents are not magic parallelism. They are a way to apply different prompts and models to different parts of the same job. Used well, they make agentic coding more controlled. Used loosely, they add another layer of noise.

The teams that get value from them usually do three things well: they keep tasks small, they define outputs tightly, and they know when not to recurse.