For a while, my biggest problem with AI coding agents wasn't that they wrote bad code. It was that they got tired.

Not literally, of course. But on a big task, the single conversation would fill up: file after file read to understand the problem, a few long test outputs, a couple of dead ends. By the time the agent got to the actual change, the context was crowded with everything it had looked at along the way, and the quality of its decisions showed it.

Sub-agents changed how I handle those tasks. Not because they're smarter, but because they keep the main conversation clean. Here's how I use them in Claude Code day to day, and where they don't help.

What a sub-agent actually is

A sub-agent is a separate AI worker that the main agent can hand a task to. It gets its own fresh context window, its own instructions and, if you like, a restricted set of tools. It does the work, then returns a summary to the main conversation. All the files it read and commands it ran stay in its own context and are thrown away.

The analogy I use: the main conversation is the lead engineer on a task. Sub-agents are colleagues you send off with a clear question ("find every place we calculate late fees and tell me how they differ"). They come back with a one-page answer, not a dump of every file they opened.

In Claude Code, the main agent can start general-purpose sub-agents on its own, and you can define your own specialised ones as Markdown files in .claude/agents/ (the /agents command helps you create them). Other tools have similar ideas under different names. The principle is what matters: delegate the reading, keep the deciding.

Four ways I use them

1. Research before a change

The most common one. Before changing anything that crosses boundaries, I want a map. For example, a change to how maintenance request statuses work in Kate PMS touches the Laravel API, the staff app and the tenant app. Instead of the main agent reading all three codebases, I ask for sub-agents to investigate each side and report back:

• where the status values are defined and validated,
• which screens or endpoints read them,
• which notifications or jobs fire on a status change.

The main conversation receives three compact reports, and its context stays focused on the decision: what to change and in what order.

2. Parallel exploration

Those research tasks are independent, so they can run at the same time. It's the same reason you'd split a code audit across colleagues instead of doing it alone. I find this most useful for questions like "how is X done across the codebase?", where the answer is spread over many files that have nothing to do with each other.

3. A reviewer with fresh eyes

This one surprised me most. When the same conversation that wrote the code reviews it, it tends to agree with itself. It "remembers" why each decision was made. A review sub-agent starts with none of that history. It only sees the diff and the rules I gave it, which is much closer to how a human reviewer reads a pull request.

Here's a simplified version of the kind of reviewer definition I keep in a project:

---
name: code-reviewer
description: Reviews the current branch for bugs, security issues and
  missed edge cases. Use after finishing a change, before committing.
tools: Read, Grep, Glob, Bash
---
You are a careful senior reviewer for a Laravel and React Native codebase.
Review only the changes in `git diff main...HEAD`.
Report real bugs first, then security concerns, then missed edge cases.
For each finding: file, line, why it matters, and a suggested fix.
Do not edit any files. Ignore formatting; the linter handles it.

Notice it has no write tools. A reviewer that can't edit can't "helpfully" change things you didn't ask for. It still doesn't replace a human pull-request review in our CI/CD flow. It's a first pass that catches things before a colleague spends time on them.

4. Noisy jobs that produce a short answer

Running a full test suite, reading a long log, or checking how a library is used across a big folder all produce lots of output and a small conclusion. A sub-agent can run the tests and report back only the failures and their likely cause. The pages of passing output never touch the main context.

How I brief a sub-agent

A sub-agent doesn't see your conversation. It only gets the brief. That makes the brief the whole game, and it's the same skill as delegating to a person:

• The goal, not just the task. "Find where late fees are calculated, because we're about to change the grace period" gets a better answer than "find late fees".
• The boundaries. Read-only? Which folders? What to ignore?
• The shape of the answer. "File paths with line numbers, one sentence per finding, a list of open questions at the end." A vague question returns a vague essay.
• What counts as done. Otherwise a thorough agent will keep going long after you have what you need.

And I verify what comes back. A summary is a compression, and compressions lose detail. When a report says "the status is only set in one place", I'll ask the main agent to open that file and confirm before we build on it.

Where sub-agents don't help

• Small tasks. Spinning up a sub-agent to rename a variable adds overhead and nothing else.
• Tightly connected edits. Several agents editing the same files in parallel is a recipe for conflicts. I use parallel sub-agents for reading and reviewing, and keep the actual edits in one place, in a planned order.
• Work that needs the conversation. If the right answer depends on a trade-off we discussed an hour ago, a fresh agent won't know about it unless I write it into the brief.
• Cost and limits. Each sub-agent reads its own files, so parallel work uses more of your usage overall. It's worth it for big tasks, not for everything.

The bigger lesson

Sub-agents made me think about AI work the way a lead thinks about a team: who needs to know what, what can run in parallel, and where the decisions are made. The same instincts that make a good tech lead (clear briefs, small focused tasks, review by someone who didn't write the code) turn out to be exactly what makes agents useful on a large codebase.

It pairs well with the other things I keep in my setup: a CLAUDE.md with the project's rules, custom skills for repeated workflows, and a knowledge-graph skill that gives agents a map of the codebase before they start reading.

If you use sub-agents (in Claude Code or anything similar), what's the one job you always delegate? Mine is the first-pass code review.