Claude Codeのエージェントを3人に分けた話 — あえて細かく分けすぎなかった理由 A practitioner's account of organizing Claude Code into just three sub-agents rather than …

Anthropic's Claude Code increasingly supports a workflow where developers define multiple sub-agents, each with a specialized role, that collaborate on tasks. In this article, the author shares an experience of deliberately limiting their setup to just three agents rather than spinning up many narrowly scoped ones.

The motivation is rooted in a practical observation: over-fragmenting agent responsibilities tends to backfire. When you split work across ten or more specialists, each agent ends up with only a fragment of the relevant context, and every handoff requires re-injecting prompts and background information. The result is higher token consumption without a corresponding gain in output quality, and sometimes a noticeable drop in coherence as instructions ricochet between agents.

By keeping the team to three, the author reports finding a sweet spot where each agent retains enough context to reason effectively while still having a clearly bounded responsibility. Although the article does not exhaustively enumerate the roles, the split appears to follow familiar coarse-grained software engineering boundaries — something like design, implementation, and review — which maps naturally onto how human engineering teams already divide labor. That alignment makes the configuration easier to reason about and to debug when something goes wrong.

This perspective resonates with broader industry discussion around multi-agent design. Frameworks such as AutoGen, LangGraph, and CrewAI all expose machinery for elaborate agent hierarchies, yet experienced practitioners increasingly caution that simpler topologies tend to be more reliable. Anthropic's own essay "Building effective agents" makes a similar point, advocating for straightforward compositions and well-defined tools over baroque orchestration. Empirically, complex agent graphs are harder to evaluate, more sensitive to prompt drift, and prone to compounding errors as control passes between participants.

Claude Code's sub-agent feature lets you declare agents concisely in YAML, which is a strength but also a temptation: the low friction of definition can encourage over-engineering. Each new agent feels nearly free to add, yet the hidden costs — context fragmentation, longer execution traces, and harder failure analysis — accumulate quickly. The author's three-agent configuration can be read as a deliberate counterweight to that tendency.

It is worth noting that the optimal number of agents is likely task-dependent. For very large codebases or pipelines spanning multiple domains, a finer breakdown may still pay off, particularly when combined with shared memory or retrieval layers that mitigate context loss. Conversely, for day-to-day feature work, a small, tightly coupled team of agents may dominate. Readers considering their own setup may want to start coarse and only introduce additional specialization when a concrete bottleneck appears, rather than designing an elaborate org chart upfront.