Not All Subagents Are the Same
Ask Claude to track down where a function lives somewhere in a sprawling codebase, and it won’t dig through the files itself. It spins up a separate agent, hands over the question, and waits for the answer. That part of the story is familiar by now. What’s easy to miss is that the agent it spins up for a job like that physically cannot edit or delete a single file, even if it decided that would be faster.
That’s not a missing feature. It’s the point.
The roster isn’t one agent, it’s several
“Spin up a subagent” makes it sound like there’s one kind of helper Claude reaches for every time. There isn’t. Some subagents can read files, search across a whole project, and report back, and nothing else. They don’t have a save button. Others carry the full kit: reading, writing, running code, the works. A third kind is built only to sketch out a plan, weighing tradeoffs and listing steps, without touching a single file to test that plan out. Same word, “subagent,” three very different sets of hands.
Which one shows up depends entirely on what the task actually calls for, not on what would be most convenient to reach for.
Read-only isn’t a downgrade
It’s tempting to think of the read-only agent as the crippled version, the one you’d upgrade from the second you could. That gets it backwards. A subagent that can only look and report is doing exactly what a locate-and-summarize task needs and nothing more, which means there’s no scenario where a bug in its instructions turns into a deleted file or an overwritten draft. The restriction isn’t a limitation bolted on around a more capable tool. It’s the tool being built to match the size of the job.
Matching the agent to the job
Say the task is “find every place this setting gets referenced.” That’s a search problem, so it goes to the agent that can only search. Say the task is “fix the bug once you’ve found it.” That’s a different job with a different blast radius, so it goes to an agent that’s actually allowed to write. Handing the second job to the first agent just gets you a polite explanation of why it can’t finish. Handing the first job to the second agent works, technically, but it means a task that only needed eyes was quietly handed hands too.
The judgment call sits with whoever’s dispatching the work: how much can this particular job actually damage if something goes sideways, and does the agent I’m about to use even have the tools to cause that damage in the first place. Picking the narrower agent on purpose, even when the broader one would also work, is the same instinct behind only granting read access to a calendar you don’t need to change.
Why this matters
This site keeps circling back to one idea: capability and permission aren’t the same thing, and the gap between them is where trust actually gets built. A subagent with no write access isn’t a weaker version of the “real” one. It’s a version that can’t do the one thing you never asked it to do in the first place. Scoping the tool to the task, instead of just trusting the task description to keep the tool in line, is a small design choice that quietly does a lot of the safety work most people assume comes from somewhere else.
