Multi-AgentArchitectureMarch 2, 2026·12 min read

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.

Message Passing

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

Shared Files

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)

agents/orion/agents.md
# 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)

agents/echo/agents.md (pipeline writer stage)
# 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 backward

In 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.

agents/orion/SOUL.md (coordinator with collaboration rules)
# 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 conversation

The 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.

Terminal — configuring models per agent
# 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
AgentModelProviderWhyCost/1K msgs
OrionClaude SonnetAnthropicTask decomposition, decision-making~$0.45
EchoClaude SonnetAnthropicLong-form writing quality~$2.10
RadarGPT-4oOpenAIStructured JSON output, data analysis~$1.20
ScoutLlama 3 8BOllamaHigh-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 user

Total 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.

Terminal — debugging communication step by step
# 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 rules

Agent 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.

Build Your AI Agent Now

Design, test with real AI, and export a production-ready deploy package. Docker, Telegram, Discord & Slack bots included.

Open Agent Designer

Free to design. No credit card required.