Let the expensive model think and the cheap one look things up

I was about to refactor something a lot of code depended on, and the first job was finding who used it. I'd let the main agent do that search a few times. It reads dozens of files, and every one of them stays in context for the rest of the session.

That's the most expensive model doing the cheapest work, and it leaves it with a head full of irrelevant code when it comes to the part that needs judgement.

#Hand the looking to someone else

A subagent is a separate session with its own context window. You give it a job, it does the reading, and it sends back an answer. Everything it read stays with it.

So for that refactor I ask a subagent to find every consumer and report back. A brief looks something like this:

Find every place formatPrice() is used. For each one give the file and
line, how it's called, and whether the caller handles a null result.
Read only, don't change anything. Reply as a list, under 30 lines.

The main agent gets a page instead of forty files, from a cheaper model, and its context stays on the decision. I wrote about where rules should live last time. This is the other half: skills decide what an agent knows, subagents decide who does the work.

#What I send down

Anything that is mostly reading or fetching and has a small answer. Finding usages before a change. Working out how an unfamiliar part of the codebase fits together. Looking up library docs or pulling data from the web. And mechanical edits across many files, once the approach is settled.

The judgement stays with the main agent: picking the approach, deciding what to change, and checking what came back. My research agent is a good example. It runs on Sonnet, has no edit or write tools, and its prompt says it's read-only. It can look at anything, and its instructions say to change nothing.

Another benefit I didn't expect is focus. A subagent with one job isn't distracted by the whole conversation.

#Where it goes wrong

Vague briefs. If I say "look into the auth code", the subagent has to guess what I care about, and it'll pick a tool and an interpretation to suit the guess. I've had answers that were confident, tidy and aimed at a slightly different question.

Tools are the other trap. A subagent only has what you give it. If the set is thin or doesn't suit the job, it can't choose well and improvises with what it has.

And I don't take "done" at face value. It tells me the agent finished, not that it was right. I read what came back before I act on it.

I haven't measured any of the savings, so I won't put numbers on them. What I'm sure of is the cleaner context in the main session. If you want to try it, take one lookup you keep doing by hand and give it to a subagent with a brief like the one above.