You’ve probably spent weeks wrestling with a multi-agent framework. You’ve read endless docs on ‘orchestrators,’ ‘coordinators,’ and ‘schedulers.’ You’ve built abstractions upon abstractions, hoping that somewhere in the pyramid of middleware, autonomy would finally emerge.
I’ve been there. And I have news: you don’t need any of that.
Last month, I watched a team of five engineers spend three weeks building a custom orchestration layer for their AI swarm. When I showed them that their existing agent—the one they already had working—could act as the orchestrator by simply adding other agents to its tool list, they stared at me like I’d just broken the universe.
This isn’t a hack. It’s the core insight that makes multi-agent systems simple: an orchestrator is just an agent that happens to have other agents in its tool list.
Think about it. What does an orchestrator do? It receives a request, decides which sub-agent to call, and passes the result back. That’s exactly what a single agent does—except instead of calling a weather API or a database, it calls another agent. The same recursive logic applies. The same error handling. The same state management.
I’ve been digging into the source code of every major multi-agent framework this year. And while they differ in syntax, they all reinvent the same wheel: a centralized loop that decides which agent to invoke next. They call it ‘orchestrator,’ ‘controller,’ ‘manager’—but it’s just a fancy name for what any agent already does.
Here’s the liberating truth: you can build infinitely composable, highly autonomous multi-agent systems using nothing but the single-agent tools you already own. No new framework. No new abstractions. Just one agent with a tool list that includes other agents.
Let me show you how this works in practice. Say you have an agent that handles customer support. It already has tools for searching a knowledge base, fetching order history, and escalating to a human. Now add a ‘sentiment analysis agent’ as another tool. When a customer sounds angry, the support agent calls the sentiment agent, which returns a severity score, and the support agent decides whether to escalate. That’s not orchestration—that’s just an agent using its tools.
Now scale it. Add a ‘billing agent’ tool. A ‘product recommendation agent’ tool. A ‘fraud detection agent’ tool. Each agent is itself a full agent with its own tools. Suddenly, without any central orchestrator, you have a swarm that can handle complex workflows—all built on the same simple pattern.
I’ve seen this pattern used in production for months. It’s stable. It’s testable. It’s debuggable. And most importantly, it’s understandable. When something goes wrong, you trace the call chain: agent A called agent B, which called agent C. No hidden coordinator logic. No mysterious ‘orchestrator’ state.
This is the paradox of control versus autonomy: to achieve truly autonomous multi-agent systems, you must surrender the illusion of central control. Let the agents decide who to call, just like humans decide who to delegate to. The framework doesn’t need to know the cast of characters; it just needs to know that each agent can call any other agent.
Critics will say: ‘But what about coordination? What about deadlocks? What about infinite loops?’ To which I say: solve those problems the same way you solve them in single-agent systems—with timeouts, retries, and blacklists. The complexity doesn’t disappear; it just gets distributed where it belongs.
If you’re building a multi-agent system today, here’s my challenge: take your best single agent, give it a tool that calls another agent, and see what happens. You might find that the orchestrator you were about to build was already staring you in the face.
You don’t need a framework. You need a recursive function and an appetite for simplicity.
FAQ
Q: What about error handling and coordination? Don't you need a central orchestrator for that?
A: No. Error handling works the same way as in a single agent: timeouts, retries, and fallback logic. If agent A calls agent B and B fails, agent A can retry, escalate, or log the error—just like it would with any other tool. Coordination emerges naturally from the call chain, not from a central bottleneck.
Q: How does this approach scale to hundreds of agents? Won't the call graph get messy?
A: The same way any distributed system scales: you introduce conventions, not central control. Each agent can have a limited set of 'sub-agents' it knows about. You can use a registry (like a simple key-value store) for agents to discover each other. The beauty is that no single agent needs to know about all agents—just its immediate neighbors. This is how real-world organizations work.
Q: Isn't this just reinventing the 'agent-as-tool' pattern? That's not new.
A: Exactly. That's the point. The industry has been over-engineering by creating separate 'orchestrator' frameworks when the solution was already in the tool abstraction. The contrarian take is that most multi-agent frameworks are solutions in search of a problem—they add complexity without adding capability. The simpler approach often works better.