Using AI, properly · 08: how to use subagents

In the last one we looked at what a skill is, and when to make one. A skill is a folder that teaches your AI how to do one job.

This one starts where that stops. Some jobs are too big for one AI to do and grade at the same time.

You give your AI something real to do. “Go through this and tell me what is wrong with it.” A job with actual work in it.

So it goes off. It opens a file, searches, opens four more, tries something, backs out of it, tries again. A while later an answer lands at the bottom of a long wall of it looking around.

You read the answer. You believe it. Why would you not, it just did all that work in front of you.

Two things went wrong there, and the second one is the expensive one.

The first is noise. All that looking around now lives in the chat with you. Every question you ask after it has to share the room with it.

The second one is quieter. The thing that did the work is also the thing telling you the work went fine. It read its own notes and graded its own answer. It is not lying to you. It just cannot see the spot where it went wrong, because being wrong about that spot is what sent it down the wrong road in the first place.

My own merge rule puts it in one line: the agent that produced the work cannot judge the work. Where that rule lives is the end of this piece.

A subagent is a second AI you send off with one job and an empty memory.

Empty is the word that matters. It has not read this morning’s chat. It has not read the answer you are asking it to look at. It goes away, does the one job somewhere else, and comes back with what it found.

The first AI has been in the room all day. The second one just walked in the door.

Four parts. Once you have seen them you will spot them in any setup.

1. One job, written down. One job, and the facts it needs, because it starts with nothing. My builder agent is called sdd-implementer and its whole rule is that it runs exactly one brief. Not the next one, not the tidy-up next to it.

2. An empty memory. It does not get the first AI’s chat. My merge check, sdd-merger, is a rule with a name: fresh eyes, never the builder’s own session. If it inherits the room it is just the same opinion twice.

3. A limit on what it can touch. Each one gets a lane. sdd-planner cuts a big piece of work into briefs and never builds anything. sdd-verifier reads the whole wave afterwards and reports, and changes nothing at all. There is a fifth on my list, sdd-researcher.

4. One report back. People miss this one, and it is the plainest win of the four. A subagent can read a hundred files and hand you back a paragraph. The hundred files never enter your chat. My own note for this is two words: subagents = firewall.

the hundred files stay out there, the paragraph comes back.

Three ways one shows up, and the first needs nothing from you at all.

Sometimes your AI just does it. It reads what you asked, decides the job is worth splitting, and runs a piece of it somewhere else without saying so. You notice because the answer came back tidier than the work behind it. How often that happens depends on the tool and on the job, so it is a thing to spot, not a thing to count on.

Or you ask. Plain words, no setup: “open a fresh session, read this, and tell me what is wrong with it.” Most people never try that one, and it is most of the value.

The heavy one you set up once and then stop thinking about, so the agents are already there with names and fixed jobs. That is the next section, because it is the one I actually run.

same move every time. only the effort changes.

Whichever way it arrives, the move is the same. Next time your AI hands you an analysis you are about to act on, do two things. Save it, in full, in a file. Then open a fresh one that has seen none of it, give it the file, and ask it to check the analysis.

That is a rule in my own instructions file, for when I am running on the big model: when Claude gives me an analysis, save it in detail, then send another one in with fresh context to check it. Every time. The analysis is not true yet. It is a draft of the truth until something clean has been over it.

Same shape, wired up once, for the kind of work I keep coming back to.

When a job is too big for one pass, I type /sdd. What happens next is the whole point, because nothing starts building. A planner reads the job and cuts it into small tasks, one written brief per task, and it is not allowed to build anything at all. Its own file says so.

Then every brief gets its own implementer. One brief, one agent, and that agent knows nothing except what is written in the brief. That sounds like a handicap. It is the feature. A thin brief comes back wrong straight away, where you can see it, instead of the gap being quietly filled in with a guess.

The last one does no building. It reads the finished work with fresh eyes, and the line in its file is blunt: the agent that produced the work cannot judge the work. It goes twice, once asking is this green, once asking is this right, and it will not let anything through on red.

On the 22nd of July that ran here as four things: one written pack of facts, two builders working at the same time, and one reader who had seen none of it. Six pull requests across five repos came out of it, each one through its own fresh-eyes check before it landed. Both gates green on each.

I never make any of those agents by hand, and that is the part worth stealing. The command makes one per task, every time, so the split falls out of how the job was cut up rather than out of what I remembered to do. There is a smaller door into the same thing: /subagent runs one builder and one reader, which is the whole idea with the ceremony taken off.

one command, three stages, and the last one has seen none of it.

I will explain commands in the next chapters; super helpful for your automation

Pick the last answer your AI gave you that you acted on without checking. Save it to a file. Open a fresh chat, paste the file, and ask it what is wrong with it.

If it comes back clean, you have lost nothing. If it comes back with something you had already acted on, you now know what I know.

That is subagents. Follow for more; I write up the things I actually run.

Next one is workflows.