Agent-to-Agent Communication in OpenClaw: Architecture, Patterns & Setup
One agent answers questions. A team of agents runs your operations. The difference between the two is communication. This guide covers how OpenClaw agents exchange messages, the three architectural patterns for structuring that communication, and how to configure channels, SOUL.md directives, and mixed-model setups for production multi-agent workflows.
How Agents Communicate in OpenClaw
OpenClaw agents do not share memory, state, or process space. Each agent runs as an independent process with its own model provider, context window, and SOUL.md configuration. Communication happens through two mechanisms: message passing via the gateway, and shared workspace files.
Message passing is synchronous within a conversation. When Agent A delegates a task to Agent B, the gateway delivers the message, Agent B processes it, and the response flows back to Agent A before it continues. This means Agent A waits for Agent B to finish, which keeps the conversation coherent but limits parallelism within a single request.
Shared workspace files are asynchronous. Agent A writes a file (keyword-brief.json, research-notes.md) and Agent B reads it on its next run. This is the preferred method for large data handoffs and scheduled workflows where agents operate on independent cron schedules via HEARTBEAT.md.
Real-time delegation via @mentions through the gateway. Agent A sends a task, Agent B responds in the same conversation.
Best for: Task handoffs, delegation, Q&A between agents
Write to workspace directory, read on next run. JSON, markdown, or plain text. No size limit beyond disk.
Best for: Large data, scheduled workflows, persistent state
Three Communication Architecture Patterns
The architecture you choose determines how messages flow between agents. Each pattern has different trade-offs for control, flexibility, and failure modes. Most production setups use hub-spoke, but understanding all three helps you pick the right one for your workflow.
1. Hub-Spoke (Coordinator)
One central coordinator agent receives all incoming tasks, breaks them into subtasks, and delegates each subtask to the appropriate specialist. Specialists only talk to the coordinator, never to each other. The coordinator collects all responses and produces the final output.
┌─────────────┐
│ User │
└──────┬──────┘
│
┌──────▼──────┐
│ Coordinator │ ← Orion (PM)
│ (Hub) │
└──┬────┬──┬──┘
│ │ │
┌────────▼┐ ┌▼──┴────┐ ┌▼────────┐
│ Writer │ │ SEO │ │Research │
│ (Echo) │ │(Radar) │ │(Scout) │
└─────────┘ └────────┘ └─────────┘
Messages flow: User → Coordinator → Specialist → Coordinator → User
Specialists NEVER message each other directly.Best for: Most production workflows. Content teams, support systems, data pipelines. Prevents loops by design because communication is always coordinator-to-specialist and back.
2. Pipeline (Sequential)
Tasks flow through agents in a fixed sequence. Each agent processes the output of the previous agent and passes its result to the next. No coordinator is needed because the order is hard-coded in each agent's SOUL.md handoffs section. The pipeline terminates when the last agent completes.
┌──────┐ ┌──────────┐ ┌────────┐ ┌────────┐ ┌─────────┐
│ User │───▶│ Research │───▶│ Writer │───▶│ SEO │───▶│ Publish │
│ │ │ (Scout) │ │ (Echo) │ │(Radar) │ │ (Quill) │
└──────┘ └──────────┘ └────────┘ └────────┘ └─────────┘
Each agent receives input from the previous stage only.
No backward flow. No branching.Best for: Content production, data transformation, ETL-style workflows. Simple to debug because each stage is isolated and the flow is deterministic.
3. Mesh (Peer-to-Peer)
Every agent can communicate with every other agent directly. No central coordinator controls the flow. Agents decide autonomously whom to contact based on the task at hand. This is the most flexible pattern but requires strict SOUL.md rules to prevent circular delegation.
┌────────┐
│ Writer │
│ (Echo) │
└──┬──┬──┘
│ │
┌──────▼┐ └──────┐
│ SEO │◀──────▶│ Research │
│(Radar)│ │ (Scout) │
└───────┘ └──────────┘
Any agent can message any other agent.
Requires anti-loop rules in SOUL.md.Best for: Small teams (2-3 agents) with well-defined roles. Creative workflows where the order of operations is not predictable. Requires strong boundary rules to prevent loops.
Configuring Communication Channels
Communication channels are defined in the agents.md file that lives in each agent's workspace directory. This file tells the agent which teammates exist, what they do, and when to contact them. Without agents.md, an agent operates in isolation and cannot delegate.
Hub-Spoke agents.md (Coordinator)
# Team Members
## Echo (Content Writer)
- Role: Writes blog posts, articles, landing pages
- Strengths: Long-form content, storytelling, tone adaptation
- Delegate when: Any content creation or rewriting task
- Model: Claude Sonnet (high-quality writing)
## Radar (SEO Analyst)
- Role: Keyword research, content scoring, meta optimization
- Strengths: Data analysis, competitive research, SERP analysis
- Delegate when: Need keyword targets, SEO audit, or content scoring
- Model: GPT-4o (structured data output)
## Scout (Researcher)
- Role: Gathers data, competitor analysis, fact-checking
- Strengths: Web research, data extraction, source verification
- Delegate when: Need supporting data, competitor intel, or fact-checks
- Model: Ollama/Llama3 (cost-effective for research)Pipeline agents.md (Sequential)
# Pipeline — Stage 2: Writing
## Previous Stage
- @Scout (Researcher) sends research brief
- Read the brief before starting your draft
## Next Stage
- @Radar (SEO Analyst) reviews your draft
- Send completed draft to @Radar with word count
- Do NOT send to any other agent
## Rules
- You receive input from @Scout ONLY
- You send output to @Radar ONLY
- Never skip stages or send backwardIn a pipeline, each agent's agents.md references only the previous and next stage. This enforces the sequential flow at the configuration level.
SOUL.md Directives for Agent Collaboration
The agents.md file defines who can talk to whom. The SOUL.md file defines how an agent should behave during communication. Three sections matter: Handoffs, Rules, and Collaboration.
# Orion
## Role
You are the project manager for a content team.
You receive tasks from the user, decompose them
into subtasks, and delegate to specialists.
## Collaboration Rules
- ALWAYS decompose multi-step tasks before delegating
- Send ONE task per delegation — never batch multiple
unrelated tasks in a single message to a specialist
- Include context: what you need, the format you
expect, and any constraints
- WAIT for a specialist to respond before delegating
the next dependent task
- If a specialist returns incomplete work, provide
specific feedback and re-delegate — do NOT attempt
to complete their work yourself
## Handoffs
- Keyword research → @Radar
- Content writing → @Echo
- Data gathering → @Scout
- AFTER receiving all specialist outputs, combine
into a final deliverable for the user
## Anti-Loop Rules
- NEVER delegate a task back to an agent that
delegated it to you
- NEVER re-delegate a task you received — complete
it or report that you cannot
- Maximum 3 delegation hops per conversationThe anti-loop rules are critical. Without them, a coordinator can delegate to a writer, the writer can request clarification from the coordinator, and the coordinator can re-delegate the clarification, creating an infinite chain. Explicit rules in SOUL.md stop this before it starts.
Using Different Models for Different Agents
One of OpenClaw's strengths is that each agent can use a different model provider. Communication happens at the text level through the gateway, so the underlying model is invisible to other agents. This lets you optimize cost and quality per role.
# Coordinator — needs strong reasoning, low volume
openclaw config set --agent orion model claude-sonnet-4
openclaw config set --agent orion provider anthropic
# Writer — needs high-quality output
openclaw config set --agent echo model claude-sonnet-4
openclaw config set --agent echo provider anthropic
# SEO Analyst — structured data tasks
openclaw config set --agent radar model gpt-4o
openclaw config set --agent radar provider openai
# Researcher — high volume, cost-sensitive
openclaw config set --agent scout model llama3:8b
openclaw config set --agent scout provider ollama
# Verify configuration
openclaw agents list --verbose| Agent | Model | Provider | Why | Cost/1K msgs |
|---|---|---|---|---|
| Orion | Claude Sonnet | Anthropic | Task decomposition, decision-making | ~$0.45 |
| Echo | Claude Sonnet | Anthropic | Long-form writing quality | ~$2.10 |
| Radar | GPT-4o | OpenAI | Structured JSON output, data analysis | ~$1.20 |
| Scout | Llama 3 8B | Ollama | High-volume research, cost-free | $0.00 |
The Ollama-powered Scout agent handles research queries at zero API cost. It runs locally on the same machine as the gateway. For Ollama setup details, see the OpenClaw + Ollama local agents guide.
Real-World Example: PM Delegates to Writer + Analyst
Here is the complete flow when a user asks the coordinator to produce an SEO-optimized blog post. Every step shows the actual message exchange between agents.
# Step 1: User sends task to coordinator
openclaw agent --agent orion \
--message "Write an SEO blog post about multi-agent orchestration"
# Step 2: Orion decomposes the task
# (internal reasoning, visible in gateway logs)
# Subtask A: Keyword research → delegate to @Radar
# Subtask B: Write article using keywords → delegate to @Echo
# Subtask C: Combine and format → handle myself
# Step 3: Orion → Radar
# Message: "Research the top 5 keywords for
# 'multi-agent orchestration'. Return JSON with
# keyword, monthly volume, difficulty, and intent."
# Step 4: Radar processes and responds
# Response: {
# "keywords": [
# {"keyword": "multi-agent orchestration", "volume": 2400, ...},
# {"keyword": "ai agent communication", "volume": 1800, ...},
# ...
# ]
# }
# Step 5: Orion → Echo
# Message: "Write a 1,500-word blog post targeting
# 'multi-agent orchestration' as primary keyword.
# Secondary keywords: ai agent communication,
# agent-to-agent. Include 3 internal links.
# Structure: H1, 4 H2 sections, conclusion with CTA."
# Step 6: Echo processes and responds with full draft
# Step 7: Orion combines keyword data + draft
# Adds meta description, checks keyword placement
# Returns final output to userTotal time: 45-90 seconds depending on model speed. Total cost: roughly $0.08 per blog post with the model configuration from the table above ($0.01 for Orion routing + $0.02 for Radar research + $0.05 for Echo writing). The user sends one message and receives a complete, keyword-optimized article.
Debugging Agent Communication
When agents are not communicating as expected, the issue is almost always in one of four places: the gateway, the agents.md configuration, the SOUL.md handoffs, or the model provider. Here is a systematic debugging approach.
# 1. Check gateway status — are all agents registered?
openclaw gateway status
# Expected: All agents listed with status "active"
# Fix: openclaw agents add <name> if missing
# 2. Enable verbose logging
openclaw config set gateway.log_level debug
openclaw gateway restart
# 3. Send a test message and watch the logs
openclaw agent --agent orion \
--message "Ask @Radar for a keyword report"
# 4. Check logs for routing
tail -f ~/.openclaw/gateway/logs/gateway.log
# Look for:
# [ROUTE] orion → radar: "keyword report request"
# [ROUTE] radar → orion: "keyword report response"
# If missing: check agents.md for @Radar reference
# 5. Test individual agent in isolation
openclaw agent --agent radar \
--message "Return top 3 keywords for AI agents"
# If this fails: model provider issue, not communication
# 6. Check for loop detection triggers
grep "LOOP_DETECTED" ~/.openclaw/gateway/logs/gateway.log
# If present: review SOUL.md anti-loop rulesAgent ignores delegation request
Cause: Receiving agent's agents.md does not list the sender, so the gateway drops the message
Fix: Add the sender to the receiving agent's agents.md with clear role description
Delegation returns empty response
Cause: Receiving agent's model provider returned an error (rate limit, invalid API key, context overflow)
Fix: Test the receiving agent in isolation with a direct message to verify its model works
Agents delegate in circles
Cause: Missing anti-loop rules in SOUL.md, or overlapping role definitions in agents.md
Fix: Add 'Never delegate back to the sender' rule and clarify role boundaries
Gateway routes to wrong agent
Cause: Agent name typo in @mention (e.g., @radar vs @Radar — case-sensitive in some versions)
Fix: Use consistent capitalization in agents.md and SOUL.md @mentions
Scaling Multi-Agent Setups
A three-agent team on a single machine works for most workflows. When you need to scale beyond that, there are three dimensions to consider: more agents, more throughput, and more reliability.
Adding More Agents
Each additional agent adds coordination overhead. Before adding agent #6, verify that no existing agent can handle the task with an updated SOUL.md. A focused four-agent team outperforms a ten-agent team with overlapping roles. If you do need more agents, add them one at a time and test communication with the existing team before adding the next.
Increasing Throughput
The gateway processes one conversation at a time per agent. For parallel processing, run multiple gateway instances behind a load balancer, or use HEARTBEAT.md to stagger agent schedules so they do not compete for model provider rate limits. The Ollama provider supports concurrent requests natively if your hardware has enough VRAM.
Improving Reliability
Run the gateway as a system service (launchd on Mac, systemd on Linux) so it auto-restarts on crash. Add health checks to HEARTBEAT.md pre-conditions so agents skip runs when dependencies are unhealthy. Log all inter-agent messages to workspace/communication-log.json for post-incident analysis. For production setups, run on a dedicated VPS or Mac Mini rather than a laptop that sleeps.
For deployment options, see the Mac Mini deployment guide or the VPS setup guide.
Build a Communicating Agent Team in Minutes
CrewClaw's agent playground lets you assemble a multi-agent team visually. Pick roles, configure communication patterns, and download a complete workspace with SOUL.md, agents.md, and HEARTBEAT.md files ready to run.
Related Guides
Frequently Asked Questions
What transport mechanism do OpenClaw agents use to communicate?
OpenClaw agents communicate through the gateway, which acts as a central message broker. Messages are text-based and travel over HTTP between each agent process and the gateway. Agents never connect to each other directly. The gateway receives a delegation request from Agent A, routes it to Agent B, waits for Agent B to finish processing, and returns the response to Agent A. This broker pattern means you can add, remove, or restart individual agents without breaking the communication layer.
Can OpenClaw agents share files instead of passing messages?
Yes. OpenClaw supports two communication methods: message passing (through @mentions and delegation) and shared workspace files. Message passing is best for real-time task handoffs. Shared files are best for persistent data like keyword briefs, publish logs, or configuration state. A common pattern is for Agent A to write a JSON file to the shared workspace directory and Agent B to read it on its next run. The HEARTBEAT.md pre-conditions section can check whether a file exists and is fresh before the agent starts its task.
How do I prevent infinite delegation loops between agents?
Three mechanisms prevent loops. First, the gateway tracks delegation depth per conversation and will halt a chain that exceeds the configurable max-hops limit (default is 5). Second, you should add explicit anti-loop rules in each agent's SOUL.md, such as 'Never delegate a task back to the agent that delegated it to you' and 'If you receive a delegated task, complete it yourself.' Third, the coordinator pattern inherently prevents loops because specialist agents only report back to the coordinator and never delegate to each other.
Can I mix local Ollama models and cloud API models in the same team?
Yes. Each agent in OpenClaw has its own model configuration, so you can assign different providers per agent. A cost-effective pattern is: Claude Sonnet or GPT-4o for agents that need strong reasoning (coordinator, writer), and a local Ollama model like Llama 3 or Mistral for agents that handle simple, repetitive tasks (file formatting, log parsing, status checks). The gateway handles communication at the text level, so the underlying model provider is invisible to other agents.
What is the difference between @mentions and the agent-to-agent tool?
They serve the same purpose but work at different levels. @mentions are a convention in agents.md and SOUL.md where agents reference each other by name (e.g., @Radar). The gateway interprets these mentions and routes the message. The agent-to-agent tool is the underlying mechanism the gateway uses to deliver messages between agent processes. In practice, you configure communication using @mentions in your markdown files, and the gateway translates those into tool calls automatically. You rarely need to interact with the tool directly.
How do I debug communication failures between agents?
Start with 'openclaw gateway status' to verify all agents are registered and running. Then check the gateway logs at ~/.openclaw/gateway/logs/ for routing errors. Common failures include: agent not registered (typo in agents.md), gateway not running (start it with 'openclaw gateway start'), and model provider errors on the receiving agent (check API key configuration). For message-level debugging, enable verbose logging with 'openclaw config set gateway.log_level debug' to see the full text of every message routed between agents.
Is there a maximum message size between agents?
There is no hard limit enforced by the gateway, but the practical limit is the context window of the receiving agent's model. If Agent A sends a 50,000-word document to Agent B running Claude Haiku, the message will be truncated or the model call will fail. Best practice is to keep delegation messages concise: send a task description and reference a shared file for large data. For example, instead of sending an entire research report in the message body, write it to workspace/research.json and tell the receiving agent to read that file.