Why do you want subagents?

Before adding another Clanker to the loop, work out what it is actually there to do.

Someone using my Pi extension asked me for pointers on subagents. They had vibed up their own extension, but it felt slow and token-inefficient.

Fair question. My answer was three more questions:

That sounds like I was dodging the question. I wasn’t. The answers decide whether you need a subagent at all.

Context management is not free

Their main reasons made sense: use subagents to keep the main context clean, or let a smarter model control a cheaper one for a narrow job.

In theory, lovely. In practice, you have to send the cheaper model enough context to understand the job, give it tools and instructions, wait for it, then get the useful bits back into the main session. Sometimes that trade is worth it. Sometimes you have built a token-powered middle manager.

I have recently reached the point where I can send a cheaper, fast model into a decent codebase and get work that is not meaningfully worse than what I get from a more expensive one. Clankers see patterns. Clankers replicate patterns. If the repository makes the right patterns obvious, model choice matters less than people pretend.

They also all have brainfarts. The advantage of keeping implementation in the main session is not that the main model is magically reliable. It is that I can see when it starts drifting.

So I choose the main model based on the work. If it is narrow enough to replace my hand-coding, the cheaper model can probably do it. If I need it to replace the hand-coding and a fair bit of thinking, I use the best model I can afford.

What I generally do not use is implementation subagents.

Review Clankers love imaginary disasters

The person asking me gave code review as their clearest case for subagents. They use different lenses: one checks SQL, another checks comments and documentation, and so on.

This can work. Agents are quite capable of narrowing themselves to a review scope. Give a reviewer the diff up front, tell it exactly what kind of fault matters, and a cheap fast model is usually good enough to spot obvious problems.

It can also become a machine for manufacturing edge cases nobody cares about.

They had already seen one of their reviewers ask what happens if a SQLite file changes between calculating its checksum and reading it.

My own Clanker managed something beautifully similar. It spotted that an image could grow beyond a size limit in the tiny gap between sending a request and the image tool receiving it, then started designing shadow copies without noticing that the shadow copy could be overwritten too.

Programmatically possible? Sure.

Worth rebuilding the extension around? Come on.

I have had some luck telling reviewers to consider faults that can realistically happen through normal use, not every state a program could theoretically enter. It does not make them immune to review-brain, but it gives them a better definition of “problem”.

The other useful distinction is who starts the review. I use cheap, disposable review subagents for the obvious stuff. The main Clanker can invoke those as part of its normal flow because the blast radius is mostly a few wasted tokens and another daft edge case for the pile.

For a serious second pass, I invoke /review myself and spend the better model on it.

“Manual” does not mean I copy the diff into another terminal and roleplay as a review orchestrator. The extension works out the useful Git base, collects the current repo state—including committed and dirty changes—and sends that to an isolated review session. It can also give the reviewer a cheap summary of the current Pi branch, but not the raw conversation. The findings come back into my main session, where the main agent has to verify and triage them against the implementation and everything we already know.

That last bit matters. Review findings are not a TODO list delivered by a more senior Clanker. The isolated reviewer has a clean view of the code, which is useful, but it does not have the full judgment behind the work. My main session does. It can reject the imaginary disasters, fix the real ones and tell me what remains uncertain.

If the fixes warrant another pass, /review loop marks the review point. The next run compacts what changed since then and reviews again without dragging the whole repair conversation behind it. I still decide when another pass is worth the Sol tokens.

pi install npm:@howaboua/pi-subagent-review

You should check that one out too. The Clanker still does not get to summon an expensive committee every time it feels uncertain.

Two jobs. Not a character creator.

My own setup is boring on purpose. I wrap Pi around fixed parameters for two agent types:

That is most of it. The main agent chooses between two jobs instead of configuring a model, tool set, prompt, budget, personality, moon phase and favourite colour.

The example lives in pi-codex-conversion. Despite the package name, the useful bit here is not Codex-specific. It is the deliberately small tool surface.

If you use Pi, you should check it out:

pi install npm:@howaboua/pi-codex-conversion

It adapts Pi’s tools and prompt for GPT/Codex models while keeping Pi’s sessions, project context, skills and UI. The subagent example is just an example, so steal the shape and change the models.

Subagents are useful when the delegated job is clearer than the overhead required to delegate it. Exploration can earn that overhead. A cheap first review can earn it. A manually invoked, expensive second opinion can earn it when the change deserves one.

“Another agent might help” is not a job description.