Somebody using one of my extensions for Pi, a tool for working with coding agents, asked why their own subagent setup felt slow and wasteful.
A subagent is simply another agent asked to handle part of the work. It can search a large codebase, review a change or take a narrow task away from the main session. That sounds efficient, especially if the second agent uses a cheaper model.
It is only efficient when the second agent has a specific job.
Before adding one, I would ask:
- What problem is the extra agent meant to solve?
- Which job will it perform most often?
- Does the main agent need a choice, or can the tool encode the sensible choice already?
Those questions matter more than the number of models available.
Delegation has a handling cost
The second agent needs enough information to understand the task. Its findings then have to return to the main agent in a form it can use. Both steps consume time and tokens.
For implementation work, I usually prefer one capable main agent. It can follow the patterns already present in a well-kept codebase, and I can see when its reasoning starts to wander. Sending the work through another agent creates a hand-off without removing the need to inspect the result.
The model should still match the job. A narrow change may suit a fast, cheaper model. Work that requires more judgment may justify a stronger one. Automatically dividing every implementation between several agents does not guarantee a better result.
Research and review are different jobs
Two delegated jobs have been consistently easier to bound.
An exploration agent can search widely, trace relevant files and return a compact account without filling the main working context with every path it opened.
A review agent can receive a completed change, its diff and a precise question. The person who raised this with me used separate review lenses as their example: one for SQL behaviour, another for comments and documentation. A quick, inexpensive reviewer is often enough to catch an obvious omission.
The boundary matters. Review agents are very good at finding situations that are technically possible but practically irrelevant. His reviewer worried about a SQLite file changing between calculating its checksum and reading it.
I had seen the same tendency in my own work. One of my agents noticed that an image might grow beyond a size limit between requesting it and the image tool receiving it, then began designing shadow copies without accounting for the copy being overwritten in exactly the same way.
That is not useful caution. It is an unbounded brief.
I tell reviewers to focus on faults that a person can realistically encounter through normal use. For a more consequential change, I start a separate review myself and choose a stronger model deliberately. Costly scrutiny should be attached to the importance of the change, not triggered whenever an agent can imagine another edge case.
I built @howaboua/pi-subagent-review for that deliberate pass. It gathers the repository’s current changes and sends them to an isolated reviewer. The reviewer can receive a compact summary of the main working session, but not the raw conversation.
Its findings return to the main session for triage. They are advisory: the main agent must verify each one against the code and the context it already holds rather than treating the review as a list of compulsory fixes. The separation gives the reviewer a fresh view without handing it final authority.
If a change needs another round, review-loop mode records where the fixes began. The next pass receives a compact account of what changed since that point. This keeps repeated review bounded instead of accumulating the full review-and-repair conversation each time.
I still choose when to start the process. That is the useful human approval point: routine checks can remain cheap, while a stronger and more expensive review is reserved for work that warrants it.
Keep the choice small
The example I use exposes two fixed roles: an explorer and a reviewer. Each starts with parameters suited to its job. The main agent does not have to choose among a long list of models, prompts and tool combinations every time it delegates.
The example comes from a public tool for people building with Pi, but the design lesson travels. A useful tool should present the smallest set of decisions required to run the process well. More options often mean more opportunities for the agent to choose badly.
The example is included with @howaboua/pi-codex-conversion, which adapts Pi’s tools for GPT/Codex models while retaining Pi’s sessions, project context, skills and interface. If you use Pi, you should check it out:
pi install npm:@howaboua/pi-codex-conversionThe wider point is not about one model or extension. Give the main agent the best fit for the main job. Delegate only work with a clear input, a useful output and a reason to happen somewhere else.