Transcription
OpenCL agents are brittle. When you give them one job, they're fine. But if you give them two or three, they start hallucinating and the entire thing falls apart. I'm a software engineer and here's what I did to fix it.
Today, I'm going to show you how to build multi-agent workflows in OpenClaw that actually scale. And instead of just talking theory, I will give you a real practical example that you can set up today where you can execute entire automations with a single command. When you start to use this framework, you will unlock the ability to automate complex workflows. This is the true power behind OpenClaw and why so many people are raving about it right now. But without it, you're pretty much just using a more expensive chat GBT.
When you use a single agent for all of your tasks, you can only go so far. The context gets bigger and the output gets worse. The agent starts cutting corners, making up details, or just ignoring half of your instructions, and you sit there tweaking the prompt for hours trying to get it right. This isn't a prompt problem. It's a design problem. You're asking one brain to be an expert at five different things simultaneously. That doesn't work with people and it doesn't work with AI.
The answer is the same answer every business already knows. You don't hire one person to do everything. You build a team of specialists who each do one thing really well, managed by someone who knows how to coordinate them. That's what a multi-agent workflow is. And in OpenClaw, it's shockingly simple to set up and incredibly powerful. I'm going to walk you through it using a real use case: a lead finder that detects buying signals and researches decision makers. But remember, this pattern works for an infinite number of workflows and can be used for complex automations, client onboarding, content pipelines, competitive intel. Once you see how it works, you'll never go back to single agents.
Here's how you actually solve this. You don't build one agent. You build a team and you give that team a manager. The first concept is the orchestrator agent. This is your main OpenClaw agent. It doesn't do the work. It delegates. When you tell it to find leads, it doesn't find the leads itself, but it knows which specialists to call and in which order.
Then, for this example, we will have two sub-agents. Sub-agent one is the signal detector. Its only job is to scan for companies actively hiring for roles that match your product. If you sell product management software, you can tell it to look for companies posting PM roles. If you sell sales enablement tools, you can tell it to look for companies hiring sales operations. It just has one job and is laser-focused.
Sub-agent two is the enrichment agent. It takes the companies from the signal detector and digs deeper. It finds the company size, industry, recent news, and most importantly, who's the decision maker you actually need to reach out to. Think of it like a sales team. You have a researcher finding the opportunities, an analyst qualifying them, and a manager making sure they work together. Nobody's stepping on anyone's toes because everybody has one job.
Now, here's the part that makes OpenClaw perfect for this, and it's way simpler than you might think. Most people hear multi-agent and think they need some complicated platform with drag-and-drop nodes and API connections everywhere. In OpenClaw, the entire setup is three markdown files and one command.
Okay, let's get into the details. Here is your OpenClaw workspace. Everything lives inside `claw/workspace`. Right now, you probably have your `agents.md` file in here. That's your main agent system prompt. We'll come back to that in a little bit.
Step one is to create the projects folders. You can create a new folder called `projects` in your workspace folder. Then, in your `projects` folder, create another folder called `leadfinder_agent`. In this `leadfinder_agent` folder, you can create an `orchestrator.md` file. This will be the system prompt for the orchestrator. Also, inside the `leadfinder_agent` folder, create a subfolder called `sub_agents`. In this `sub_agents` folder, you will create a `signal_detector.md` file and an `enrichment_agent.md` file. These are the system prompts for our sub-agents. That's the whole architecture.
Now we just need to write the system prompts. First, let's start with the sub-agents. We'll start with the `signal_detector.md` inside the `sub_agents` folder. This markdown file is the agent. It's the system prompt that defines what this agent does, how it thinks, and what it returns. So, anything we want the agent to know, we need to put in this file. For example, I could say: "Scan for companies posting job listings for specific roles that signal buying intent. If I sell product management software, I'm listing roles like 'product manager', 'VP of product', 'head of product'." Then I define the output: "Company name, the role they're hiring for, job listing URL, and a one-line reason this is a buying signal." This is structured, clean, no essays. I recommend using ChatGPT or Claude to help you write your system prompts. Since they are designed to weight certain words, they'll know how to write your exact prompt so that the model can understand it easier.
Now, let's move to the enrichment agent. We'll use the same pattern in the `enrichment_agent.md`. This one takes a company name as input and returns what actually matters for outreach: company size, what they do, recent funding or news, and the decision maker. That includes name, title, LinkedIn URL. I'm also telling it what not to include: "No generic company mission statements, no fluff, just the intel you'd actually read before getting on a call."
So now our two sub-agents are done, but we still need the brain that puts these together. And that's where the orchestrator comes in. This file lives one level up from the sub-agents, right inside the `leadfinder_agent` folder. The orchestrator doesn't find leads and it doesn't research companies. It manages the agents that do. In this markdown, I tell it which agents it has access to and where it can find them. Then I define the workflow: "First, spin up a sub-agent using the `signal_detector.md` as the system prompt to find the companies. Then, for each company it returns, spin up a sub-agent and use the `enrichment_agent.md` to get the full profile. Finally, compile everything into one clean report and return it." This is the playbook. The orchestrator reads it and knows exactly who to call, in what order, and how to combine the results.
The last step is the route command. Now that we have the agents set up, we need a way to execute the entire automation from our main agent. To do this, we go to our `agents.md` file. This is your top-level OpenClaw agent, the one you're already talking to every day. You add one instruction: "When I say `route leadfinder_agent`, find the `leadfinder_agent` folder in the `projects` folder and spin up a sub-agent using the `orchestrator.md` file as the system prompt." That's it. Your main agent now knows when it hears `route leadfinder_agent`, hand it off to the orchestrator, and the orchestrator handles everything from there.
And here's the beautiful part. Want to build another multi-agent workflow? Client onboarding, competitive intel, content pipeline? You can use the same pattern. Just create a new project folder, a new orchestrator, new sub-agents, and a new command. Your workspace scales without your main agent getting bloated. This makes execution more consistent, reliable, and decreases token usage.
Okay, the folder structure is set. The orchestrator knows the workflow and the route command is live. But if your sub-agent markdown files aren't written the right way, your orchestrator is going to get confused outputs and the whole pipeline falls apart. Let me show you the five things that make this production-ready.
Number one: boundaries in your sub-agent prompts. Every sub-agent markdown needs to define what it does and what it doesn't do. In the `signal_detector.md`, I'm explicit: "You find hiring signals. You do not research companies. You do not find decision makers. You return structured data only." Without this, your orchestrator sends a task to the signal detector, and it tries to be helpful by also doing the enrichment agent's job. Now you have duplicate data, conflicting information, and the orchestrator doesn't know which version to trust. Boundaries keep the lanes clean.
Number two: tuning your signal criteria. This is where your money is. Your `signal_detector.md` needs to be specific about what counts as a real buying signal versus noise. A company hiring one junior PM might not be a signal. A company hiring a VP of product and two senior PMs in the same month, that's a company scaling their product organization. That might look better for you depending on your situation. You can also add tiers to your markdown. High signal might be VP or director-level product hires. Medium signal might be multiple mid-level PM hires. Low signal might be single junior hires. You might want to flag these but de-prioritize them. The more specific your sub-agent prompt, the less garbage flows through the pipeline.
Number three: orchestrator error handling. What happens when the signal detector finds a company but the enrichment agent can't find a decision maker? If you don't handle that, the orchestrator either skips the company entirely or passes along empty fields. In your orchestrator markdown, add a role: "If the enrichment agent returns incomplete data, flag the company as 'needs manual review' instead of dropping it." You might still want that lead; it just might need a human in the loop to verify.
Number four: tool handling. Sub-agents need specific tools to handle their jobs, the same as your main agent. For the signal detection sub-agent, you might want it to use an API that scrapes a job board. In that case, you need to explicitly tell it to use that tool in the markdown file. Every agent will have different tools, and you can enhance and expand these tools as you optimize your agent.
Number five: model routing. Certain agents need a model that can handle more complex tasks, and others can use a lightweight model. By choosing the right model for the right task, you can ensure efficiency without wasting money. In your orchestrator agent, specify which model to use for which agent. If you want to do lightweight scraping, you might use a model like Haiku, whereas if you need to write marketing materials, maybe you'd want to use something like Sonnet.
And that's it. Now you know more about creating multi-agent systems than 99% of people. If you got value from this, hit subscribe. I'm putting out OpenClaw content that goes way beyond the surface level. And if you want to go even deeper, I run a community over on School where we share custom setups, configurations, and help each other build better agents. I'll put a link in the description. I'll also include a link for more information about building sub-agents in the description. Tell me in the comments what you'd like me to cover in upcoming videos.