How I Finally Figured Out Multi-Agent Orchestration
The orchestration framework here draws from the fl-multi-agent-orchestrator skill by @philipstark on ClawHub.
The Setup
So I came into OpenClaw pretty late. Everyone I talked to already had their perfect setup — agents that just knew what to do, smooth handoffs, workflows firing on their own. Meanwhile I was still staring at my screen wondering which agent was supposed to handle what.
I ended up spending way too much time reading docs, testing configs, and honestly making a ton of mistakes before anything actually clicked.
The thing I struggled with wasn’t the individual agents. It was the orchestration — how do you actually get multiple agents to work on something without everything falling apart?
“Just Spawn Things” Doesn’t Scale
My first approach was embarrassingly simple: spawn an agent whenever something needed doing. One for research, one for coding, maybe a third for review. Seemed logical.
What actually happened? Chaos. Agents stepping on each other. Nobody knowing which file belonged to who. Results all over the place. I was coordinating more than I was getting done.
The problem wasn’t the agents. It was that I had zero framework for how they were supposed to communicate.
The Architecture That Made Things Click
The real shift happened when I stopped treating agents like workers and started thinking about them like parts of a system. Each piece has a role, but the relationships between them matter just as much.
Here’s what I figured out:
Agents need explicit roles. Not “figure it out” — specific roles with specific responsibilities. When a request comes in, there’s no confusion about where it goes.
Coordination follows patterns. Most complex tasks actually fall into a few patterns. Some need parallel work — multiple research threads running at once, then combined. Some need sequence — output from one feeds into the next. Some need a review loop — build, check, fix, check again. Once you see which pattern you’re dealing with, the path forward gets obvious.
The system needs a shared language. Agents can’t read each other’s minds. You need a place for decisions and findings to live where other agents can actually find them.
Simple tasks don’t need all this. If something can be handled by one agent in a few minutes, just do that. The overhead only makes sense when the task actually justifies it.
The Mental Shortcut
Here’s the question I now ask: does this task need orchestration?
Simple one-step thing? One agent. Done.
Complex but needs to be right? Build → Review → Fix loop.
Complex with independent parts? Parallel work, then aggregate.
Complex with dependencies? Sequential pipeline.
That’s really it. Four patterns for most situations.
What I’d Tell Myself Back Then
You don’t need the perfect system on day one. I started with two agents and a shared folder. The patterns came after I understood what was actually breaking.
Also — the rules that govern the system matter more than the tools. You can have all the agents in the world, but without clear behavior triggers, it’s just noise.
Build the architecture first.