Give a good harness access to subagents and everything starts looking like a team project.

You’ve got one agent working with the database layer. Another can research the API. Another can write the tests. Another can check the work. Another can manage moving the data. As work starts happening in parallel, colored dots appear, and the whole thing starts looking like an org chart.

That sounds like fun to me, but it can also be a mess.

Having more agents doesn’t automatically produce better results.

Sometimes they duplicate work. Sometimes they edit files at the same time, producing unexpected changes or behavior.

I mean, I still use subagents constantly. They are definitely the default.

Sometimes we need, like, a subagent arena. Two agents enter. One survives.

The Subagent Context Boundary

I started using subagents as a way to protect the main context window. I wrote about that back in March: the delegated agent can read files, inspect logs, and grind through intermediate reasoning in its own context.

It’s still one of the best reasons to delegate. When finding the right answer means searching through 20 files, reading five of them, tracing a configuration value, and checking the tests, that sounds like a subagent task to me.

The search is noisy, and the output needs to be compact.

Using subagents keeps the main context window free for the larger task.

I Delegate Bounded, Independent Work

The tasks I delegate have one thing in common: I can define the output before the work begins.

Here are some areas where a subagent makes sense:

• Repository research.
• A separate implementation surface.
• Specialist review.
• Independent verification.
• Real parallel work.

Don’t Delegate an Unclear Problem

Delegation is not a substitute for deciding what the work is.

If a request is vague, spawning more agents isn’t going to help with the vagueness. It’s just more output with no clear direction. The parent still needs to choose the requirement and figure out what we’re building.

Before I delegate, I want to handle the following in the parent context:

• what question the subagent is answering,
• which files or systems it owns,
• whether it may edit anything,
• what constraints it must preserve,
• what evidence it should return,
• when it should stop and ask instead of guessing.

If we can’t figure out answers to those, the next step should be planning, not delegation.

Don’t Split Tightly Coupled Work

Avoid having two agents edit code in neighboring areas. The code may share an interface, a fixture, or a schema, and if you start changing things in multiple places without coordination, you’re going to have problems.

Each agent has its own context window. When it reads a file, block of code, or dependency into that window, the context is only current at that moment. If another agent changes the same thing, how does the first agent know its context needs to be updated?

It’s a complicated problem, for sure.

So your best bet is to avoid parallel edits where agents are working in the same or similar areas of the code. The agent work areas need to be distinct.

If humans can have coordination problems, agents can too.

I Don’t Delegate Five Minutes of Work

Delegation has a cost. The parent needs to describe the task and load enough context for the subagent to do the work and summarize it. Then the parent needs to verify the result. All of that burns a bunch of tokens. Obviously, for one-line changes or small amounts of text, this handoff should never happen in the first place. To decide whether to pass the work to a subagent, ask: will using a subagent substantially improve the output?

Sometimes the answer is just to do it in the parent context window, even if that means you have to compact sooner.

A good subagent task looks a lot like a good software interface. It has a narrow purpose, explicit inputs, clear permissions, and predictable output.

Compare these two assignments:

Look into the tests and fix anything missing.

Review the unchanged-record tests for Book. Identify provider-owned fields
that are not covered. Add focused tests only in tests/test_books_client.py.
Do not change production code. Run the focused test file and report the result.

The first transfers uncertainty. The second transfers work.

The difference does matter.

The Parent Still Owns the Result

Subagents report completion. They don’t make completion true.

The parent still has to inspect the changes, reconcile conflicting findings, run the combined quality gate, and decide whether the original requirement was satisfied. If three agents each report that their piece passes, you have three pieces of evidence. You don’t yet know whether the assembled system works.

Delegation changes who gathers the evidence. It doesn’t remove the need to judge it.

The goal isn’t keeping every agent busy. The goal is finishing the work without turning yourself into middle management for robots.

Oh God, I think that’s my job title.

I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].