The org-chart repo — a dozen named agent roles, a coordinator, a config file mapping who reports to whom — mostly does not run in practice. Here is what does.
There is a recognisable genre of open-source repo right now: a dozen named agent roles — planner, researcher, coder, reviewer, sometimes literally "CEO" — wired together by a coordinator and a configuration file describing who reports to whom. It reads like an org chart, and it is usually presented as the future of how agentic work gets done. I have looked at a lot of these, and tried to run several, and the pattern I keep finding is the same: an impressive-looking architecture diagram sitting on top of a system that does not actually survive contact with a real task, because most of the roles never get exercised and the configuration exists mainly to look thorough.
The failure mode is specific, not vague scepticism. Adding another named agent role to a swarm adds a handoff, and every handoff is a place context can get lost, restated wrong, or silently dropped, because the receiving agent only knows what the sending agent chose to pass along — never the full context a single continuous session would have kept. A twelve-role swarm has eleven more places for that to happen than a single well-scoped agent doing the work directly. The org-chart framing makes this look like more capability. In practice it is usually more failure surface for the same underlying task.
What I have found actually works is much smaller and much less photogenic: two or three agents, each with a genuinely distinct kind of judgment to apply, working on parts of a task that do not depend on each other's output in the same pass. A builder and an independent reviewer is the clearest example — the reviewer's value comes specifically from not having built the thing, so it is not defending its own choices. That is a real division of labour with a real reason to exist. A "marketing agent" handing off to a "sales agent" handing off to a "strategy agent" for a task that one competent agent could do in a single pass is division of labour in name only.
The tell, when I am looking at one of these repos, is whether I can point to a task the extra roles make possible that a smaller setup could not do. Usually I cannot. Usually the roles map to job titles from an org chart, not to distinct capabilities the task actually needs, which is a sign the architecture was designed to look like a company rather than to solve the problem in front of it. A repo with an impressive README and a coordinator.yaml mapping nine agents to nine responsibilities, that has never actually been run end to end on a real task by anyone who did not write it, is not evidence the pattern works. It is evidence the pattern demos well.
There is also a cost the org-chart framing hides. Every extra role is an extra agent burning tokens on its own slice of the task, whether or not that slice was the actual bottleneck. A twelve-role swarm is not twelve times the capability for the price of one agent — it is closer to twelve separate sessions, each paying to read and reason over its own share of context, for a task that may only have needed two or three of those roles to move it forward at all. The bill scales with the org chart long before the output quality does, and I have rarely seen anyone total that cost against what a smaller setup would have spent to reach the same result.
Multiple agents are not the wrong idea in themselves — I run parallel agents constantly, for real work, and the ones that earn their place are the ones with a clear, separate reason to exist: independence for a review, genuine parallelism on tasks that do not share state, a specialist model for a specialist job. What does not earn its place is scale for its own sake, dressed as sophistication. The honest question for any multi-agent setup is not "how many roles does it have." It is "what does the second agent know that the first one did not, and is that actually worth the handoff it costs to get it there."