Multi-Agent Communication Patterns for OpenClaw Teams

When you run multiple OpenClaw agents, the question is not whether they need to communicate. It is how. A research agent that discovers relevant information needs to pass it to your executive agent. A monitoring agent that detects a calendar conflict needs to notify the scheduling agent. An intake agent that receives a Telegram message needs to route it to the right specialist.

The communication pattern you choose determines how reliable, scalable, and debuggable your multi-agent deployment will be. Choose well and your agents coordinate seamlessly. Choose poorly and you spend your time debugging lost messages, duplicated tasks, and race conditions.

This guide covers the four communication patterns that work in production OpenClaw deployments, when to use each one, and how to implement them.

Why Communication Patterns Matter

In a single-agent deployment, the agent talks to external services (Gmail, Calendar, Telegram) and talks to you. Communication is one-dimensional.

In a multi-agent deployment, agents also need to talk to each other. This creates a communication graph that grows in complexity with each agent you add. Two agents have one possible communication path. Three agents have three. Ten agents have 45. Without a structured communication pattern, this graph becomes an unmaintainable mess.

The right communication pattern provides three things: reliability (messages are not lost), ordering (messages arrive in the sequence they were sent), and decoupling (one agent failing does not break communication for other agents).

Pattern 1: File-Based Communication

The simplest communication pattern. Agents share a Docker volume, and they communicate by writing and reading files from that shared directory.

# docker-compose.yml
volumes:
  shared-comms:

services:
  agent-intake:
    volumes:
      - shared-comms:/app/shared
  agent-executive:
    volumes:
      - shared-comms:/app/shared

The intake agent writes a JSON file to /app/shared/tasks/ when it receives a new task. The executive agent watches that directory and picks up new files.

{
  "id": "task-20260406-001",
  "source": "telegram",
  "type": "research_request",
  "payload": "Find Q1 2026 revenue data for Stripe",
  "created_at": "2026-04-06T09:15:00Z",
  "status": "pending"
}

Advantages: Zero additional infrastructure. Works on any VPS. Easy to debug by inspecting files directly. Great for getting started with multi-agent communication.

Disadvantages: File system watching is not instant (polling introduces latency). No built-in ordering guarantees when multiple files arrive simultaneously. Race conditions are possible if two agents try to process the same file. Does not scale beyond 3-4 agents with moderate message volume.

Best for: Two-agent setups, low-frequency communication (fewer than 100 messages per hour), getting started before adding infrastructure.

Pattern 2: HTTP Direct Messaging

Each OpenClaw agent exposes an HTTP API. Agents communicate by making HTTP requests directly to each other's endpoints.

# Agent configuration
api:
  enabled: true
  port: 3001
  endpoints:
    - path: /tasks
      method: POST
      handler: receive_task

The sending agent makes a POST request to the receiving agent:

curl -X POST http://agent-executive:3001/tasks \
  -H "Content-Type: application/json" \
  -d '{"type": "research_request", "payload": "..."}'

Advantages: Near-instant delivery. Request/response model allows the sender to know immediately if the message was received. Easy to implement with OpenClaw's built-in HTTP skill.

Disadvantages: Tight coupling between agents. If the receiving agent is down, the message is lost unless the sender implements retry logic. Adding a new agent requires updating the configuration of every agent that needs to communicate with it. Does not support one-to-many broadcasting without explicit fan-out logic.

Best for: Sequential workflows where Agent A always hands off to Agent B. Low agent counts (2-4) where the communication graph is simple. Scenarios where immediate acknowledgment is important.

Pattern 3: Pub/Sub with Redis

The publish/subscribe pattern decouples senders from receivers. Agents publish messages to named channels, and other agents subscribe to the channels they care about. Redis provides the infrastructure.

# Agent configuration
messaging:
  backend: redis
  url: redis://openclaw-redis:6379
  publish:
    - channel: new_emails
    - channel: task_completed
  subscribe:
    - channel: new_emails
      handler: process_email
    - channel: calendar_conflicts
      handler: resolve_conflict

When the email agent receives a new email, it publishes to the new_emails channel. The calendar agent and the task agent both subscribe to this channel and independently process the email for their respective domains.

Advantages: Complete decoupling. Publishers do not know or care who subscribes. Adding a new agent that reacts to emails requires zero changes to the email agent. Supports one-to-many broadcasting naturally. Redis handles message routing efficiently.

Disadvantages: Messages are fire-and-forget in basic Redis pub/sub. If a subscriber is offline when a message is published, it misses the message. For guaranteed delivery, use Redis Streams instead of basic pub/sub. Adds Redis as an infrastructure dependency.

Best for: Event-driven architectures. Scenarios where multiple agents need to react to the same event. Deployments with 5+ agents where the communication graph would be unmanageable with direct messaging.

For workflow-level patterns that build on pub/sub, see the operator workflows guide.

Pattern 4: Shared State Store

Instead of passing messages, agents read and write to a shared state store. This is less about explicit communication and more about implicit coordination through shared data.

# Agent configuration
state:
  backend: redis
  url: redis://openclaw-redis:6379
  namespace: openclaw:state
  sync_interval: 5

All agents read from and write to the same state store. The email agent updates the inbox_summary key. The executive agent reads inbox_summary to decide priorities. The calendar agent reads today_schedule to check for conflicts.

locking:
  backend: redis
  url: redis://openclaw-redis:6379
  ttl_seconds: 300
  retry_delay_ms: 100