Half of subagents are just a system prompt that wasn’t properly cleaned up

Before adding another subagent, first ask what problem it actually solves. The answer from Addy Osmani of the Google Chrome team is a bit deflating: most of the time, the problem is that the system prompt is too bloated.

A subagent works by opening another context window to do the job and, when finished, returning only the conclusion to the main thread. The appeal is obvious: the main loop doesn't have to read dozens of files and hundreds of lines of logs. The cost is right there too: you can't see the part of the process that was split off.

He offers only three rules of thumb, and all must be met for a split to be worthwhile: the work can truly be parallelized, it needs a fresh context, and a single agent really does choose the wrong tools. In all other cases, fold it back into the main loop, rewrite the original prompt as a skill, run an eval, and keep whichever wins.

Some commenters put it even more bluntly. Hardik said that half the subagents he has seen are just an absurdly long system prompt. Adam added that some people even have a name for this kind of thing: "architecture."

Rohan's criterion is stricter: look at whether the parent agent needs the full record. If only a few lines are returned, the split is worth it; if it needs the entire transcript, splitting just moves the context problem somewhere else.

Akash Hadagali pointed out an easily overlooked benefit: after folding back into the main loop, all tool calls land in the same trace, which makes it much easier to investigate when an eval fails.

Bits and Mettle offered a self-check method. Go through the system prompt, find the sections that are useful only for one type of task, and move them into a skill that loads on demand. A subagent only earns its place when the main thread would otherwise be stuffed with test logs and search results.

Two more dimensions are worth adding to the decision table. Bragi mentions permissions: a research subagent can read posts, but it should not have publishing rights. Kabel-Salat mentions the scenario: the cleanest case is noisy search paired with a short answer—let the subagent chew through 40 files and return ten lines.

Others disagree with folding everything. 0xserenade argues that context windows are a scarce resource, and stuffing everything into skills runs into the problems of a more expensive first call and overloaded responsibilities. Dave the screw-tightener offers a more practical reminder: a split that worked last month may no longer be worth its place after one model upgrade. Aapakari adds a number: after tool definitions exceed 30 to 50, tool-selection quality degrades, and in that case all you may need is tool search.

Of all the comments, the one I think is most worth remembering is Dusan's: a subagent returns only a summary, and you can never see what it quietly skipped.

So the question isn't whether you can split; it's who benefits after the split. If context isn't saved and the debugging path is broken in one more place, then you've just added a layer of abstraction for yourself.

Next time you get the urge to add an agent, delete the prompt first.