Sub-agents: how to manage an AI team 👥

There is something irresistible about the idea of having a team of agents at work while we do something else. One explores, one implements, another checks. The whiteboard fills with arrows, the work appears to multiply and, for a few minutes, so does productivity.

Then comes the less cinematic moment: figuring out what they actually did.

The team metaphor is convenient, but it risks promising more than it delivers. Agents do not automatically share an understanding of the project, notice when they are working from incompatible assumptions, or take responsibility for the outcome. They can pass files and reports around; understanding and judgment do not travel quite so easily.

More agents, more coordination 🔀

Dividing work does not make it disappear: it changes its form. Some of it becomes coordination, checking for overlap, and recombining results. If two agents tackle aspects that seem separate but are not, parallelism produces alternatives to reconcile, not time saved.

Even when tasks really are separable, there is an unglamorous question left: is the benefit worth the cost of explaining, assigning, waiting, and checking? For a small task, the answer can be a very efficient no. Adding agents because we can is not a strategy; sometimes it is just a sophisticated way to multiply conversations.

Parallelism speeds up independent work. It does not make interdependent work independent.

Delegation does not transfer responsibility 🧭

Delegation is easy when the task is clear. The hard part is noticing that clarity was missing: a plausible result can hide a misread requirement, an ignored constraint, or an architectural decision that nobody actually made.

That is where the image of the “lead agent” can mislead. It sounds like a team lead, but it does not bear the consequences or answer to the people who will use the software. That burden remains with the person who chose to delegate and then integrates the result. If review becomes an automatic rubber stamp, we have not built a team: we have built a production line for plausibility.

When is it worth it? 🤔

There is no magic number of agents, nor a rule that complex tasks should always be split up. There is a more concrete assessment: are the parts independent enough to progress without constantly negotiating? Can each result be checked without trusting the agent’s account of it? And does the time saved outweigh the effort of keeping the work together?

If the answer is no, one agent — or a person who clarifies the problem first — may be the more sensible choice. That is not an automation failure. It is refusing to mistake the number of processes started for the value produced.

The interesting question, then, is not “how many agents can I put to work?” It is “which part of the problem can I genuinely separate, and who takes responsibility for putting it back together?”

The practical guide to the multi-agent workflow covers delegation, isolation, and verification in detail. For now, the least automatic point is worth remembering: agents can divide the work; judgment about the work is still ours.

Series references 📚

• Multi-agent, CI/CD and spec-driven — the practical guide to multi-agent patterns and workflows
• The repository is the contract — AGENTS.md as shared knowledge
• Context engineering — the foundation of context management