I Built an OpenClaw Agent Squad (Multi-Agent Architecture Explained)

Hey guys, so in this video we are going to talk about Open Drw project built by Peter Steinberg and this is going to be my take on it. Uh we'll go through the project at a higher level. Uh especially the architecture because I've noticed that a lot of people using the project don't really understand what's actually happening behind the scene.

They use it but they don't really understand the product. Now apart from that we'll also talk about how builders founders and even tech undergrads can actually use openclaw in their day-to-day work. Over here I would like to highlight one more thing.

Uh lot of people think open claw is built for everyone including the nontext. So I've been experimenting with it for the past week and based on what I have learned that's not entirely true. But if you guys think you can keep up with the video, that's great.

Even some tech knowledge will work. So to get meaningful results, you do have to change and configure a lot of files. So you need to understand what you are doing to make it actually useful in your daily workflow.

But uh you know I'll try to explain it in the easiest way. Uh now some people have built one-click tools on top of it. for non- tech users, but I haven't personally used those, so I won't comment on how well they work.

Now, finally, I'll show you how to set up a multi- aent system, which I found to be one of the best approaches in terms of cost, token usage, and clear task division uh in a multi- aent architecture. So, let's get started. Okay.

So now before we even get into the architecture, it's important to answer why we should study it in the first place. The reason is very simple. When you understand what's happening under the hood, uh you become a much better judge of the system itself, uh its capabilities, its limitations, and most importantly, what's it actually good at and bad at.

Without that understanding, it's very easy to either overhype it or completely misjudge it. So, first thing, uh, Open Claw is not a personal assistant. It's not an AI agent and it's definitely not a chatbot.

Open claw is an agent runtime that you can install on your local machine along with a control layer or you can run it by connecting model APIs. Now at its core open claw uh is mostly built on typescript right. So what happens is open claw runs on your machine and exposes a gateway server.

This gateway is responsible for handling all the incoming connections whether that's telegram, WhatsApp, its own web UI or CLI or uh even a remote access from another machine. Uh on top of that it make calls to different LLM APIs. So if we come to the official doc search for providers.

So these are all the LLM providers that you can call with the help of open clock and then it executes the tools locally on your system. So think of it as an infrastructure that connects messages, models, memory and tools into one runtime. Okay.

So let's understand the architecture with the help of this diagram. So here's what actually happens when a user sends a message to open claw through any message provider. It can be telegram, WhatsApp or through open clause own CLI or web UI.

The first thing user message hits the channel adapter. Now the responsibility of channel adapter is normalization. So messages coming from any channel provider are always platform specific.

Uh let me uh give you an example. So this is how a message coming from telegram from the user will look like. It might have message ID, text, some attachments and other user metadata.

Now this is not useful for open claw as the system does not understand any of this. So the work of channel adapter is to normalize this message into something that the open clause system can understand regardless of where it is coming from. So after the channel adapter has done it its magic uh it will have some fields like user ID, session ID, tag, maybe the data coming from the PDF will be extracted in word format.

uh the images and the videos will be convert converted into something like blob that is something that the open system will be able to recognize and we'll be able to work with it. Okay. Now before the message moves further into the system there is a important onboarding choice that you'll have to make as a user when you are setting up open claw.

Now when you set up open claw you essentially have two modes of operation. Uh you can run it locally by default where it becomes a webocket server bound to local host loop back meaning the system cannot be accessible by anyone outside your machine. So that is the first mode of operation.

The second one is you can expose it remotely using SSH tunnels or tail scale. So tail scale deserves its own deep dive but at a higher level tail scale is a mashVPN. Let me show you guys on the left you can see this is a traditional VPN architecture where the server and the clients are uh connected with a centralized entity while on the right you can see how tail scale architecture works.

So you can think of it as a devicetodevice mash network. Now the advantage of tailscale is it can allow secure access without uh exposing the system publicly. You can read more about it on the tail scale official docs and about the product and you'll get the gist of it.

Now once the message is normalized using channel adapter it moves into step two the gateway server which has two major responsibility. The first is session router. This component decides which session the message belongs to, which agent instance should handle it, whether there is already an active session running or whether a brand new session needs to be created.

This is what gives open clock continuity instead of treating every message as a fresh request. The second responsibility of the gateway is handling the lane Q system. Each session gets its own queue and by default it follows a first come first serve scheduuling algorithm.

I think something you have already probably encountered back in college when learning aboutuling algorithms. Now since open claw is built using typescript and runs on nodejs which is singlethreaded you cannot afford to get stuck in async await loops and the lane q system ensures that even if multiple messages arrive at the same time tool calls are running or several sessions are active in parallel nothing blocks the system now let's understand it with the help of a example and a diagram so here it is the incoming message which was normalized by the channel adapter. Then it goes to the session router which decides which session the message belongs to and to which agent the request should go to.

Now let's say there are three parallel sessions going on. Session one, session two, session three. Each session has their own lanes.

Uh session one has three processes A, B and C. Session two has two processes D and E. And session three has two processes F and G.

Now for session one, the first process that comes into the lane is A. Uh it runs and gets executed. Then comes B.

It runs and gets executed and C which also gets executed. While in session two, the process D is still waiting for the IO approval. Now with this we can understand that while one session waits other sessions continue executing.

This ensures message are processed in order sessions don't interfere with each other and system runs smoothly under load. Now when a message clears the gateway it reaches step three which is the agent runner. The first thing that happens here is model resolution which is done by model resolver.

The system determines which model was selected by the user during onboarding and which model is configured for that particular agent. As in a multi- aent setup different agents can use different providers and can have different API keys. So all of this is resolved from the authentication configuration uh which stores your environment variables as well.

Now next come the system prompt builder. As the name suggest, it compiles everything the agent needs into a full LM context. This includes the available tools, the agent skills and workspace files that are stored locally.

These workspace files effectively define the agent's identity and as you continue interacting with the agent, these files can evolve and get updated over the time. After that, we have session history loader. So the loader pulls in the conversation history.

So the agent has full context. When searching for a relevant memory, the agent uh does not just scan text. Past conversations are broken into chunks and stored in SQLite using two indexing methods.

Now let's discuss those indexing methods in detail. So basically open claw maintains two files. Memory empty file which is a part of agent workspace.

It is a special kind of file that only stores key conversation blocks between the user and agent that can be used in future references. While uh session dot JSONL file, it stores the entire conversation between the user and the LLM for that entire chat session. Now these two files are broken in data chunks and stored for agent lookup using keyword and semantic indexing.

Uh let's talk about keyword indexing first. So keyword indexing stores each conversation chunk uh using SQLite full text search framework. Behind the scenes, SQLite builds a word to document map and inverted index which is the same code data structure used by search engines.

Now let's take an example. If the user asks agent what is the capital of India and the data chunk stored in the local DB is something like the capital keyword is occurring in doc 3, do 17 and do 9 respectively and the keyword Delhi is occurring in doc 3, do 8 and India is occurring in doc 9. Now the system immediately retrieves the chunk that directly matches those keywords.

This provides fast and precise recall with almost zero overhead. Now the second indexing uh that open claw uses is semantic or vector-based indexing. Now consider a more complex query like what is the capital of India as of 2026?

Tell me now. Now in this case exact keyword matching alone isn't sufficient. So the same conversation chunks are also stored as vector embedding inside SQLite blobs.

So chunks are combined uh and their respective locations are stored. So for the sentence, what is the capital of India? capital Delhi and the vector location is stored 10A 20 of India 11A 19 and Delhi India 200A 400.

These embeddings capture semantic meaning rather than just literal words. Uh comparisons here use cosine similarity or dotproduct effectively measuring the angle between vectors. The smaller the angle the closer the meaning.

This allows the agent to retrieve relevant context even when the phrasing doesn't exactly match the past conversations. Now finally the result from both vector and keyword indexing uh is merged through hybrid retriever. Uh this hybrid approach compiles the final memory context that agent uses to respond.

So at this point it should be clear that this is no longer behaving like a simple chatbot. There are complex systems in place that makes open claw one of a kind. Okay.

So again we come back to agent rer. We have discussed model resolver its purpose system prompt builder its purpose and session history loader. Now basically the llm context will be created from these two combined.

This context uh eventually passes to context window guard. Now what context window guard does is if there is enough space in the context window everything proceeds normally but if the context is close to full the session is compacted usually by summarizing or the system fails gracefully instead of crashing. Okay.

Then comes step four the LLM API call. Now the LM provider is chosen by you uh while doing the onboarding setup. This is where the actual model invocation happens.

Now here the model may stream responses token by token uh request extended reasoning if supported and return either a final text response a tool call instruction or maybe even both depending upon the message or prompt given by the user to the agent. Now after that system directly moves into step five the agent loop and tool execution. So the agent loop begins as the model response.

If the response contains a tool call, the system executes the tool via oh my pi RPC. Let me show you. So uh this is an open-source project.

Now what is RPC? So RPC stands for remote procedure call. It was developed in the late 1970s between early '9s 80s.

the new high term that you hear nowadays the MCP it is nothing but a new take on RPC only. Now what OMI PI is uh it's an AI agent toolkit with the RPC mode on OMI PI enables headless operations of the coding agent via JSON protocol. Uh this is how open claw agents can access and manage your applications IDE CLI or browser search.

Uh so now the final captured result feed its back into the model and repeats the loop. If there is no tool call, the response is treated as final and the loop exits. The cycle continues uh until a final answer is produced.

Uh maximum step limit is reached or an error occurs. Uh all of this is governed by tool access control. uh like which tools the agent is allowed to use and which one it isn't.

Here the arrow is wrong. Sorry for that guys. It should be pointing over here not here.

So sorry for that. So once the final output is ready, it moves back through the response part to the user. The response can be streamed token by token or sent uh sent as a single message.

Now the outgoing channel adapter then converts the internal response format back to initially whichever the message provider user chose to send the message. Uh now after working with the project for more than one week and studying the architecture uh one area that still clearly needs improvement that I thought is tool calling and tool gatekeeping. So during the initial setup many tools are exposed by default and the system still has to reason about so whether an agent actually has access to them.

So in that scenario tighter controls and clear boundaries uh have to be set to make the architecture even stronger. Now with that foundation in place we move on to the multi- aent setup guide. Hey guys.

So because I have already installed open crow on this machine uh so we'll just remove the existing configs and the uh agent context from this machine and start with a clean setup. For that I'll just need to run openclaw uninstall command. From here we just want to keep the gateway service.

Apart from that everything else goes. Okay. Now to start the open claw wizard we run open claw on boot command.

Yes we'll start with the manual setup. Now uh these are the two operations that we discussed during the uh during when we were going through the architecture as well. So here open claw is asking me that whether you want to configure me on this machine or you have uh a separate machine where I'm already running uh and you want to open a remote SSH tunnel to that uh to that device.

So we just want to run you on this machine. Then we choose the LM provider. I'm going with open router.

Let's choose the model flash back. Let's uh configure the message provider. We'll choose telegram bot token.

So I have pushed my bot token. Let's finish pairing. No, no.

Do this later. Now, uh this is the bot that I already have configured on Telegram. Let's put start.

Now, let's put this. So, you can see this is the pairing which is still pending. So we'll run open clock pairing approve and the pairing code.

Right. So now if I send a message from telegram I think my agent will be Yeah. So it is typing.

So guys with this open claw is running on your local machine and you have configured telegram and connected openclaw with telegram. Now if I ask my agent hey how are you today right so I am getting replies from the agent. So guys when you successfully configure openclaw openclaw creates aclaw folder in your root directory.

Now this folder contains all of the config file as well as the agent context file that uh openclaw needs. Now next we are going to go into the openclaw directory and learn a little bit about this workspace. Okay.

So guys let's dive in. Now you don't need to know everything here. We'll just focus on three things.

The agents folder, the workspace folder, and the global config file which is open. json. Let's start with the agents directory.

The first important file here is profiles. json. You can think of this as the LLM provider config file for your agent.

As you can see, it contains the information about the LM provider the agent is allowed to use and the API key for that provider. Next, we have session files. The first one is session.

json. This can be treated as the summary file. The system uses it to understand how the session should be resolved.

It uh contains the information about the message provider, the tools uh that are available to your agent by default uh and the part two the agents workspace file and few other agent level configuration fields. Then we have the JSON L file. This file contains the raw logs of every message exchange between you and your agent for that particular session.

Uh over time this file can grow quite large since it stores a full conversation history. Now let's move to the workspace directory. This directory represents the identity of your agent.

The agents MD file is loaded every time a new session starts. Now if we open it you'll see that it guides the agent through this directory basically telling it which files exist here and when each file should be used. The next we have identity MD file.

Uh this works like a identity card for your agent. So it defines the agent name uh its overall vibe and small things like uh whether it can use emojis or not. Then we have user.

md file. So this file tells the agent who you are, what kind of work you do and what you usually want help with. Now then we have the most important file in the workspace soul.

md. So this is where the agent's personality lives. Uh it defines how the agent thinks, how it behaves, what skills it can use, uh and when should it use those skills.

Okay. So now finally we have the global config file openclaw. json.

So this file is resolved at the gateway level. It defines uh routing default agent settings primary and fallback models and message providers. So uh if you ever want to make any system level changes in open claw uh whether that's llm calls tool calls messaging uh message routing or session binding everything sits inside this file.

So that's the code layout. Once you understand this structure navigating and configuring open raw becomes much easier. Okay guys so now let's move from a single agent setup to a multi-agent setup.

To do that, you really only need one command, open claw agents add and then the agent's name. So when you run this command, open claw automatically creates a separate agent session directory and a separate uh workspace directory for that new agent. Uh now uh every agent runs in its own directory with its own files.

Agents are not self-aware of each other by default. they don't know other agent exists unless you explicitly connect them. Uh this is a default behavior of open claw multi-agent routing.

So think of it like everyone has their own personality, their own memory and their own way of thinking. But in our case, we can make the main agent aware that our other agent exist and even let it read from their workspace if we want. Now instead of manually setting up everything from a new agent, I am going to spawn one using a framework that I have built called cast room.

So cast room automatically injects personality content into the agent workspace. So you don't have to spend hours writing prompts or training the agent from scratch. Agent still has full freedom to evolve.

You can overwrite its roles, guide it over time, and shape its behavior as you interact with it. So now I'm going to configure Michael as he is my favorite character from the office. Now I can directly run the command.

Yes, I want to create a separate workspace. Sure. Copy.

Uh, no. Configured chat channels. No.

Okay guys, so done. Now if we open our workspace we can see that open claw has created a separate workspace for Michael as well as uh separate agents session directory for Michael as well. Now to properly configure Michael so we can send messages to him directly from telegram.

We need to make a few changes in openclaw. json file. Also if you notice that identity MD file in the case of Michael uh is already populated compared to identity.

md file of our main agent that is because of the cast room framework that we used. Uh now in open claw file first we'll add the modified channel object and binding object to properly configure our uh agent channel binding. So here we go.

Here uh we have added the bindings to properly map our agent with our telegram channel. And here I have already uh added my previous bot token and uh token for our Michael agent as well. Okay.

So now if you want you can also add a tool allow list object inside your agent list object for your particular agent. So uh this part is optional as your agent has a read access of the file system by default. I'll this for both of them.

Now we'll finally add some context data in our main agent soul. md file uh so he can access Michael's workspace. So uh now this context you can add according to your needs and modify it further as well.

Now once these changes are done we'll stop the gateway and start it again. So for that we'll use the command open claw gateway stop and then we'll write open clock gateway. Now if you look at the logs uh you can see that the agent binding is resolved properly.

Okay. So now we are going to try to send message to uh Michael. Okay.

So Michael is active with his context. Now, let's open our main bot and tell it to reload it soul. md file and check if he has the access or context of who Michael is So he has the context of Michael.

Okay. So with this guys, you have successfully configured a multi- aent system. Now this was just an example.

You can play around and create something even complex with this knowledge. You have noticed by now that this is a pretty advanced open setup. I haven't really seen many people using it this way.

Most setups stick to a single main agent and if things get too complex, they spin up a sub agent. But this architecture is different here. You can properly couple and decouple multiple agents.

Each agent can stand on its own. You can still create sub aents for them. And if you want, you can even share knowledge or memory across these agents.

That gives you a lot more flexibility and control compared to the usual single agent approach. Now let's talk about some use cases. Your agents already have CLI access and browser search access by default.

So you can easily create a builder agent for your side projects. You can give it a to-do list or a prototype plan and let it help you build a MVP. You can create a personal assistant agent that reads your emails or Microsoft Team messages and helps you plan your day.

You can have a workout agent that designs your training and diet based on your daily matrix. Or you can mix all of this together and build a system where different agents handle different parts of your life. With this setup, you are not limited to one role or one workflow.

You can create as many agents as you want, each with a clear purpose. And honestly, once you reach this point, the sky is really the limit. So, on that note, we'll wrap this up.