I want to explain what a subagent is, because every technical description I’ve read makes it sound less useful than it actually is.
The technical version: a subagent is a separate Claude instance invoked programmatically to handle a specific, bounded task, operating in its own context window with its own tool access, returning a finished result to the parent session when complete.
The accurate version: it’s a minion.
You give it a job. It goes and does the job. It comes back with the answer. You never watched it work, and you don’t need to.
The Babysitting Problem
Anyone who’s spent real time with AI tools in an agentic context knows the specific exhaustion I’m about to describe.
You’re trying to work on something. The AI is doing intermediate steps — calling tools, reading files, making decisions — and all of that process is happening in your context, in your conversation, in your attention. Every tool call result surfaces in the thread. Every intermediate output asks something of your brain, even if just to confirm “yes, continue.”
You wanted to delegate the work. Instead, you’re watching the work, which isn’t delegation — it’s supervision with extra steps.
Subagents solve this by design. The parent agent spins up a child instance, hands it exactly the context it needs for the specific job, and goes back to whatever it was doing. The subagent does its thing in complete isolation. When it’s done, it returns a result. The parent never had to watch.
The key architectural point: subagent context is scoped intentionally. You send exactly what’s relevant to the task. Not the full history of the parent session. Not every file in the project. Just the job description and the inputs. More context isn’t better when it’s not about the task — it’s noise that costs tokens and diffuses focus.
What Subagents Are Actually Good At
Not everything. That’s the first useful thing the course teaches.
Subagents earn their keep on tasks with three properties: they require unstructured reading, they produce structured judgment, and they’re genuinely independent of whatever else is happening in the parent session.
Research is the obvious one. Given a company name, go figure out whether it’s worth pursuing. What does their engineering blog actually say? Any recent funding or layoff news? What’s the remote policy in practice versus on the careers page? That’s a task that requires reading across multiple sources, synthesizing conflicting signals, and producing a verdict. A language model is genuinely good at that. A Python script is not.
Comparison and scoring are the other ones. Given two documents — a job posting and a resume, say — produce a structured assessment of fit. Which requirements are covered? What are gaps? Does the seniority match? Is the compensation range in range? That’s unstructured reading producing structured output, and a model handles it cleanly.
Anything deterministic — fetching, filtering, deduplicating, sorting, counting — that’s Python. Not a subagent. The model doesn’t need to decide whether a posting is older than three days; it needs to look at a date and do math. Let the code do the math.
Getting that split right — model for judgment, code for logic — turns out to be the main lesson of actually building something with subagents, and I’ll get to that in detail on Thursday.
What Surprised Me About the Course
Two things caught me off guard.
First: subagents don’t automatically inherit your skills. If you’ve built SKILL.md files — reusable capability definitions that Claude can invoke — a subagent running within the same project doesn’t see them by default. You have to wire that access explicitly.
At first, that felt like an obvious oversight. The more I sat with it, the more it made sense. A subagent scoped to “research this company” doesn’t need your commit message standards or your logging conventions. Automatic skill inheritance would be noise. Manual wiring keeps the subagent’s context intentional and narrow.
It’s just not the assumption you walk in with.
Second, the troubleshooting matrix for when subagents misbehave made me slightly nervous, not because the problems seemed catastrophic but because I hadn’t hit any of them yet. Reading a list of failure modes before you’ve seen the failures has a particular feeling — somewhere between “good to have this” and “oh, so these are coming.”
Some of them were coming. Thursday.
The Minion Mental Model
Here’s the frame that actually helped me think about subagents correctly.
You’re not delegating a conversation. You’re delegating an outcome. The subagent doesn’t report back on its progress, surface its intermediate reasoning, or ask clarifying questions. It takes the job spec, does the work, and returns a finished result.
Which means your job — before you spin one up — is to write a good job spec. A subagent prompt is less like a chat message and more like a brief to a contractor: here’s the task, here’s the input, here’s exactly what the output should look like, here’s what to do if the input doesn’t match expectations.
The better the brief, the better the result. The worse the brief, the more creative the subagent gets about interpreting ambiguity — and “creative interpretation of ambiguity” is not what you want from something executing autonomously without asking permission.
I learned that the easy way in the course. I also learned it the somewhat less easy way in the project. But that’s Thursday’s story.
What’s Coming Thursday
I built something with subagents last week. A pipeline that pulls job postings from company boards, vets each company, scores each posting against my resume, and produces a ranked shortlist of things actually worth applying to.
It took three days.
It never finished a clean run.
That’s not a failure story — it’s a sharper lesson about where agentic tooling earns its keep and where you should have just written a Python script. Turns out the line between those two things is more interesting than I expected.
The code is at github.com/bbornino/claude-cowork-job-pipeline. The project page with the full build retrospective is at bornino.net/projects.