When to delegate vs do it yourself

The same wall that keeps a subagent’s mess out of your conversation also keeps its thinking out. That cuts both ways, and it’s the key to using subagents well.

Hand off work where the answer is small but the digging is big. Keep work where you need to watch how Claude got there.

A subagent’s context is invisible in both directions. It can’t see your conversation, so it only knows what you put in the handoff. And you can’t see its reasoning, so you get the conclusion without a chance to nudge it halfway through.

The shape of a good delegation

Three things make a job a great fit to hand off:

• Big process, small result. “Find every place we call the old payment API.” It might read eighty files; the answer is a short list. The cost stays in the subagent’s context, the value comes back to yours.
• Self-contained. You can describe the whole job up front, because the subagent can’t easily ask follow-up questions or read the history behind your request.
• You only want the destination. Searching, locating, summarizing a long document, investigating “where does this come from” — all perfect.

When to keep it yourself

• When you need to see the reasoning. A delicate refactor where you want to approve each move — don’t hand that off, you’d lose the very thing you care about.
• When you’ll change direction as you go. Exploratory work where the next step depends on what just showed up. A subagent commits to its task; you can’t steer it mid-flight.
• When it’s quick anyway. Spinning up a subagent has overhead. “Read this one file and tell me the port number” — just do it directly.

What’s next

You don’t always have to describe the helper from scratch. Claude ships with a few ready-made agents, each tuned for one of the most common jobs.