Building your own tools · Level 4

Delegating work

15 min intermediate

Think about the last time you built a ten-slide deck one slide at a time, waiting through each one. Or read your way through an unfamiliar codebase, file by file, because there was no faster way to understand it.

You were the bottleneck, and the work was splittable the whole time.

The guardrails from the last course matter more here than anywhere. An agent you dispatch and forget about is exactly the one you want fenced in properly.

Background agents: dispatch and walk away

You can hand a whole task to its own agent and carry on with something else while it works.

You met subagents in the previous course. The difference is waiting. When your main agent uses a subagent, it sits there until the subagent comes back. A background agent runs on its own and tells the main agent when it is finished, so nothing is blocked in the meantime.

That opens up a way of working. While you and your agent build one part of something, a second agent tests another part and reports back. You deal with what it found when it lands, rather than stopping to wait for it.

One caution. Several jobs at once means several sets of context. It gets easy to lose track of what each agent knows, and what it has already changed. Keep the pieces genuinely separate, and keep the number small enough that you can still hold it in your head.

Mostly you just ask. “Do this in the background and tell me when it is done.” Claude Code also sends work off on its own when a task is clearly self-contained, so you will see it happen without asking.

Exercise: review a codebase while you carry on working.

Open Claude Code in a real project, ideally one big enough that you have never read all of it. Pick three parts you would like to understand better: a couple of components, a module, the test setup.

Ask for the review, and be explicit about the background part:

Use background agents to review these three parts of the codebase, one agent each: [name them].
Have each one report what it does, how it is structured, and anything that looks fragile.
When they are all done, pull it together into one research report for me.

Now do something else in the same session while they work. Ask a question about a file, make a small edit. The point is that you are not waiting. When the report lands, read it and see how much of that you would have had to do by hand.

A team of agents, not just one

Once agents run on their own, you can put several on the same job and have them work as a team. Ten pieces at once, or a few agents with different roles, is where the time really comes back.

Picture a slide deck. Point one agent at each slide, sit in a meeting while ten slides get drafted, and come back to a full draft you can edit. The same shape fits any wide job: a dozen files to change, ten companies to research, a batch of replies to draft.

They do not all have to do the same thing either. You can tell your agents how to divide the work. One writes while another reviews what it produced. One builds while another tests. You describe the split you want in plain language and dispatch accordingly.

Two things stop that becoming a mess.

Keep them out of each other’s way. Each agent owns its own piece, its own file, its own copy. The cost is that an agent knows nothing about the other nine. Anything they must share, a template, a tone, a naming scheme, goes in every prompt.
Have the work checked before it reaches you. Either each agent re-reads its own output against the goal, or a reviewer agent goes hunting for what is wrong. Ten agents with no review hand you ten drafts you still have to check yourself, and some will be wrong. Eval loops is the whole course on this.

Before you dispatch a batch, get one piece back and look at it. A parallel run multiplies whatever you set up, including a wrong approach. An agent will happily hand you a complete, polished, ninety-percent-wrong deliverable. Someone asked for a twelve-slide deck and got all twelve, finished and quality-checked, and every one went in the bin because the approach was wrong from slide one. One slide, read early, catches that for about five percent of the cost.

Exercise: build a deck in parallel.

Give your agents a slide-making skill. A plugin is a bundle of skills you install in one go, and a marketplace is the catalog you install it from. Build a plugin covers both properly. Run /plugin marketplace add anthropics/skills, then /plugin install document-skills@anthropic-agent-skills. If your team has its own deck skill, use that.

Five slides on “AI agents at work”. Open the agent view and dispatch this, pressing Enter:

Use the pptx skill. One slide only: what an AI agent is, in plain terms.
Default template, one big heading, four bullets max. Save it as ./slides/slide-1.pptx.

Then dispatch the same prompt four more times, swapping only the topic and the number.

Slide 2. What a background agent is, and why you would hand it a task
Slide 3. How to run many agents in parallel
Slide 4. The guardrails, permissions and review
Slide 5. When not to use agents

Two details are doing the work. Each prompt is self-contained, because an agent knows nothing about the other four. And every prompt repeats the same style line, so the five slides come out looking alike.

All five write into ./slides/ in your project folder, so they cannot collide and the merge agent just reads the folder. You only need the isolated-copy setup from the docs when your agents edit shared code.

As each row finishes, peek at its slide and fix anything that is off. When all five are done, dispatch one last task:

Merge the five slide files in ./slides/, in order slide-1 through slide-5, into one deck: ./slides/agents-at-work.pptx.

Open it. Even counting the pass where you checked each slide, you built a whole deck in roughly the time one slide used to take you.

You now have three ways to start work without you. The question left is what any of them may touch while you are gone, and rules and guardrails is next for exactly that reason.

When the job is too big for that: dynamic workflows

A dynamic workflow runs your agents through a set structure, in phases, instead of you dispatching them one at a time. You describe the job. Claude Code writes a script that fans agents out, waits for a phase to finish, feeds the results into the next one, and repeats.

You get one by asking. Put the word ultracode anywhere in your prompt, or just say you want a workflow. Run /workflows to watch it: every phase, how many agents are running, and what it has cost you so far.

Two jobs suit this. The first is anything too big to hold in one head, like sweeping an entire codebase for a class of bug, or migrating five hundred files. The second is work where the steps are fixed but each step needs real thinking: find the issues, then verify each one, then write it up. You get the same structure every time and agents doing the actual work inside it.

Reflect

Think of a job you would happily hand over if you trusted the result. What check would have to exist before you would walk away from it?
Look at your last big piece of work. Could it have been split into pieces that ran at the same time? If not, what forced the order?