When To Use Subagents

· aiproductivity

You ask a coding agent to fix an API that stops returning results after the first page. It traces the request, finds where the page number gets lost, changes the code, and adds a test for the next page.

Should you split that work among an investigator, an implementer, and a tester?

Probably not. Each step needs what the previous step found. The investigation informs the fix; the fix determines what the test should exercise. Handing the task from agent to agent can mean repeating context and reconciling partial results, without making the work any more independent.

Now suppose you haven’t settled on an approach. You want to compare a database index, caching, and a change to the query. Those are separate investigations. Each can start from the same requirements and report its costs and risks for you to compare.

The decision isn’t whether to use a researcher agent or a coding agent. It’s whether the work actually separates.

Keep dependent steps together

In the pagination example, the agent may need to revise its diagnosis after seeing the test result. The test may reveal that the page number is passed correctly but the backend applies the wrong default. Then the implementation changes, and the test needs to cover that behavior instead.

flowchart LR
    A[Investigate] --> B[Implement]
    B --> C[Test]
    C --> D[Adjust]

That is one connected loop: investigate, change, check, and adjust. A single agent can carry the context from one step to the next.

This doesn’t mean one agent has to do everything serially. If it needs to compare several independent approaches, check separate documentation sources, or inspect unrelated components, those branches may be worth delegating. The useful question is whether one branch can make progress without waiting for another’s findings.

If every worker needs the same evolving diagnosis, or their outputs depend on each other’s changes, splitting by job title may just add handoffs. If their work can proceed from a stable brief and come back as comparable results, delegation may save time or let each branch focus on a different part of the problem.

Delegate independent investigations

For the database example, the main agent can give each worker one option to evaluate. Each should get the same requirements and return a bounded result: what it would change, what it might improve, and what risks or checks matter.

flowchart TB
    A[Main Agent] --> B[Assess an index]
    A --> C[Assess caching]
    A --> D[Assess a query change]
    B --> E[Compare findings]
    C --> E
    D --> E
    E --> F[Main Agent decides]

The main agent still owns the decision and the implementation. It needs to compare the reports against the same criteria, check important claims, and resolve disagreements. Delegating an investigation doesn’t make its conclusion correct, and three reports aren’t useful if each starts from a different assumption.

Before delegating, ask:

  • Can each branch start without the others’ results?
  • Can each one return something useful on its own?
  • Will the main agent be able to compare the results and make the decision?

If not, keep the steps in one loop or clarify the shared starting point first.

Use a fresh context for a different reason

There is another reason to use a separate agent: you may want a review that isn’t shaped by the implementer’s explanation.

An agent that wrote the fix knows what it intended to change and which assumptions led it there. That context is useful while implementing, but it can make it easier to overlook a requirement the implementation didn’t meet.

A fresh reviewer can instead receive the original requirement and the resulting change, then check whether the behavior matches. For the pagination fix, it might try a request for page two and check that those results differ from page one.

flowchart TB
    A[Main Agent implements] --> B[Resulting change]
    C[Original requirement] --> D[Fresh reviewer]
    B --> D
    D --> E{Does it meet the requirement?}
    E -->|No| F[Report the gap]
    F --> A
    E -->|Yes| G[Review complete]

This is a separate check, not a guarantee. The reviewer can still misunderstand the requirement or miss a case. Give it a concrete scenario to test, and ask it to report what it actually checked. If it needs the implementation notes to understand the intended behavior, include them—but distinguish those notes from the requirement.

Start with one owner

You don’t need a planner, researcher, implementer, and reviewer for every task. Start with one agent responsible for the outcome and the checks.

Let it continue through steps that depend on its current context. Let it delegate bounded investigations when they can proceed independently. Bring in a fresh reviewer when a second judgment is worth the extra coordination.

The advice to fold subagents into the main agent loop makes a similar case for keeping work together when a separate agent adds overhead without enough benefit. The practical test is not which agent title sounds right. It’s what the work needs to share, and what it can safely do apart.

The rule I use is simple: continue by default, branch when the work is independent, and isolate when a fresh judgment matters.