Building an OpenClaw Agent Team with TUI Collaboration
Preface
Now let's try having different agents play different roles and work together.
Build an Agent Team
I've done a lot of experimentation. Based on my experience, it's best to first have openclaw study its own documentation and summarize it in context.
Study the documentation of openclaw yourself, especially agent setup and communication between agents
Send the following requirements in natural language in the TUI (the blue parts are up to you)
Create a new agent collaboration team, with multiple agents in the team
Create these agents, set their identities, and the collaboration relationships between them
Note: add new ones, keep the existing agent main
Note: these are agents, not subagents
In order for agents to send messages to each other, pay attention to modifying the openclaw.json file parameters
tools.sessions.visibility = all
tools.agentToAgent.enabled = true
Agent No. 1
Name = agent-leader
Identity = Overall task leader, decompose the total task into smaller tasks, and assign them to other agents
Knowledge = Know the full information of other agents (including identity and knowledge)
Agent No. 2
Name = agent-code
Identity = Accept tasks from other agents, notify the task initiator upon completion, and submit the results
Specifically, this agent is a programmer
Knowledge = The results after task completion need to be saved in a non-workspace directory before delivery
Agent No. 3
Name = agent-test
Identity = Accept tasks from other agents, notify the task initiator upon completion, and submit the results
Specifically, this agent is a tester, accepts the test object and test standards, and delivers a test report
Knowledge = The results after task completion need to be saved in a non-workspace directory before delivery
Common knowledge:
All agents in this team already exist, so don't use sessions_spawn, but use sessions_send
For sending messages between agents, use the sessions_send(sessionKey="...", message=...) method, don't use the label parameter
sessions_send uses the timeoutSeconds = 0 parameter, it does not wait for a reply, but the receiving agent actively reports back, and the sending agent can check periodically.
* The gray parts are common pitfalls I summarized based on multiple experiments. I believe that with the development of openclaw and models, these supplementary notes won't be needed in the future.
Wait a moment, openclaw is done
Need to check what was done. gpt-5.4 may very likely need you to explicitly ask it to restart the gateway
Check that the workspace directory is also set up.
If you're interested, you can check for yourself how these .md files are written.
"Monitor" Each Agent's session (Optional)
If you want to see the full process of multiple Agents working together, you can open multiple tui in multiple SSH sessions and switch to different agents.
Remember the /agent command we mentioned in the previous post?
* One trick is to directly run openclaw tui under a certain agent's workspace directory, which will connect to that agent instead of the system default agent
Saves you from loading an agent main session and then having to use the /agent command to switch
source
source
Test Sending Messages Between Agents (At the current time, this test is recommended; in the future it should be optional)
In agent main, ask how many agents and sessions exist in the system
How many agents and sessions are there in total in the system
In agent main, test sending messages to the sessions of other agents respectively
Test sending messages to the sessions of other agents respectively
In agent main, ask agent-leader to test sending messages to the sessions of the other 2 agents respectively
Ask agent-leader to test sending messages to the sessions of the other 2 agents respectively
If the above tests return incorrect results, it means there is a problem with the communication mechanism between agents. Don't start the complex tasks below (actually, they're not that complex)
* Note: To clear the context, use /reset, which does not create a new session; each of your agents' sessions should remain as main.
Don't use /new, which will create a new session and may mess up communication between agents.
(Of course, I'm speaking as of the current time; this should be improved in the future)
Send the Overall Task to the Team Leader Agent
Use a simple development task as an example.
Send the following task description to agent-leader verbatim, you don't need to analyze the task
Core function reference https://crazypeace.github.io/xkcd-password-generator/
Visual style reference https://onojyun.com/
My original expectation was this time sequence
agent-leader sends a message to agent-code
This message is printed in agent-code's tui
agent-code works
...
I'm not sure if it's a problem with my usage or with openclaw's system design.
I'm not satisfied with the collaboration process and final result of the entire agent "team".
It may need more prompts or a better model.
gpt-5.4 always uses the label parameter when calling session_send. I already instructed it not to, but it still uses it. I asked it in detail, and the answer was that the session_send function has a label parameter in its internal declaration, so the model always uses it that way.
openrouter/hunter-alpha doesn't have this problem. After I emphasized it, it will do as I instructed. (Of course, it's also possible that internally it also always tries the label parameter, but it just doesn't print it in the session for me to discover)
I requested the deliverables not to be placed under workspace, but gpt-5.4's handling was to place them at
/root/.openclaw/workspace-agent-code/password-generator-app/
/root/.openclaw/workspace-agent-leader/deliverables/password-generator-app/
Clearly it didn't understand my meaning.
openrouter/hunter-alpha's approach is to place them at
/root/team-delivery/agent-code/
/root/team-delivery/agent-test/
Obviously this is better, and more like real-world team collaboration practices.
Postscript
The model I used above is gpt-5.4 from a free public site
I've also tried the free nvidia/nemotron-3-super-120b-a12b and openrouter/hunter-alpha. Often it looks fine at first, but then while running it stops responding, times out, or errors out. I guess it's because too many tokens were used.
As openclaw becomes more popular, I think it would be very useful for model vendors to train the system architecture, usage documentation, common usage patterns, etc. for the openclaw system as part of the model.
Xiaomi's model xiaomi/MiMo-V2-Pro claims to be optimized for multi-agent collaboration and long-context scenarios, I think that's a good direction.
========
Posts
