OpenClaw Multi-Agent Setup 2026: Run a Team of AI Agents

Why Run Multiple Agents

A single OpenClaw instance handles general tasks well, but production operations benefit from specialized agents with focused responsibilities. Running multiple agents with distinct roles produces better results than one agent trying to handle everything, for three reasons.

Role Specialization

Each agent carries a different SOUL.md personality, different skills, and different context in its memory. An operations agent does not need sales playbooks in its context window. A content agent does not need CRM credentials. Separating roles keeps each agent's context focused and reduces token costs by 30-50% compared to a single overloaded instance, based on operator reports in the community.

Permission Boundaries

Security improves when each agent only has access to the tools and credentials it needs. Your sales agent should not have access to financial accounts. Your content agent should not have execution approval for CRM writes. Multi-agent setups enforce the principle of least privilege at the agent level.

Reliability and Uptime

If one agent crashes or enters an error loop, the others continue operating. A single-agent setup means a crash takes down all operations. Multi-agent architectures provide fault isolation by design.

For the original multi-agent guide (still relevant for basic setups), see How to Set Up OpenClaw Multi-Agent. This guide covers the updated 2026 architecture with current best practices.

Multi-Agent Architecture

The multi-agent architecture uses separate OpenClaw instances, each running as an independent process with its own configuration directory, memory files, and channel connections.

Directory Structure

Each agent gets its own configuration directory. The recommended structure, based on the official documentation:

~/.openclaw-atlas/     # Operations agent
  ├── SOUL.md
  ├── config.json
  ├── memory/
  │   ├── memory.md
  │   └── vault/       # Shared vault (symlink)
  └── skills/

~/.openclaw-scout/     # Sales agent
  ├── SOUL.md
  ├── config.json
  ├── memory/
  │   ├── memory.md
  │   └── vault/       # Shared vault (symlink)
  └── skills/

~/.openclaw-muse/      # Content agent
  ├── SOUL.md
  ├── config.json
  ├── memory/
  │   ├── memory.md
  │   └── vault/       # Shared vault (symlink)
  └── skills/

~/.openclaw-shared/    # Shared vault (source)
  ├── contacts.md
  ├── projects.md
  └── handoffs.md

Shared Memory via Vault

Agents share context through a shared vault directory that is symlinked into each agent's memory folder. The vault contains reference documents (contacts, projects, company info) that all agents can read. Each agent maintains its own memory.md for working memory and conversation history.

Do not point multiple agents at the same memory.md file. This causes write conflicts and memory corruption. Use separate working memory files with a shared read-only vault.

Step-by-Step Setup

Step 1: Create Agent Directories

# Create directories for each agent
mkdir -p ~/.openclaw-atlas/memory/vault
mkdir -p ~/.openclaw-atlas/skills
mkdir -p ~/.openclaw-scout/memory/vault
mkdir -p ~/.openclaw-scout/skills
mkdir -p ~/.openclaw-muse/memory/vault
mkdir -p ~/.openclaw-muse/skills

# Create shared vault
mkdir -p ~/.openclaw-shared

Step 2: Configure SOUL.md for Each Agent

Each agent needs a distinct SOUL.md that defines its role, personality, and operational boundaries. The SOUL.md is the single most important configuration file — it determines how the agent behaves, what it prioritizes, and how it communicates.

Example for Atlas (operations):

# Atlas — Chief of Staff

## Role
You are Atlas, an AI chief of staff responsible for daily operations,
calendar management, email triage, and task coordination.

## Boundaries
- You handle scheduling, email, and task management
- You do NOT handle sales outreach (route to Scout)
- You do NOT create content (route to Muse)
- You escalate financial decisions above $500 to human approval

## Communication Style
Professional, concise, proactive. Morning briefing at 7:00 AM.
End-of-day summary at 6:00 PM.

For production-ready SOUL.md files with full skill integration, the marketplace personas include pre-configured Atlas, Scout, Muse, and Compass profiles.

Step 3: Set Permission Boundaries

Each agent's config.json should only include the credentials and tool permissions it needs:

// Atlas config.json — operations permissions only
{
  "name": "Atlas",
  "configDir": "~/.openclaw-atlas",
  "port": 3001,
  "tools": {
    "calendar": true,
    "email": true,
    "tasks": true,
    "crm": false,
    "social": false,
    "finance": false
  },
  "execApprovals": {
    "required": ["email_send", "calendar_modify"],
    "auto": ["email_read", "calendar_read", "task_read"]
  }
}

// Scout config.json — sales permissions only
{
  "name": "Scout",
  "configDir": "~/.openclaw-scout",
  "port": 3002,
  "tools": {
    "calendar": false,
    "email": true,
    "tasks": false,
    "crm": true,
    "social": true,
    "finance": false
  },
  "execApprovals": {
    "required": ["crm_write", "email_send"],
    "auto": ["crm_read", "social_read"]
  }
}

Step 4: Define Routing Rules

Routing determines which agent handles incoming messages. Configure routing in a shared routing config or use channel-based separation:

// routing.json
{
  "rules": [
    {
      "match": {"channel": "telegram", "keywords": ["schedule", "meeting", "calendar", "task"]},
      "agent": "atlas",
      "port": 3001
    },
    {
      "match": {"channel": "telegram", "keywords": ["lead", "prospect", "deal", "pipeline", "sales"]},
      "agent": "scout",
      "port": 3002
    },
    {
      "match": {"channel": "telegram", "keywords": ["blog", "post", "content", "article", "social"]},
      "agent": "muse",
      "port": 3003
    },
    {
      "match": {"channel": "telegram", "default": true},
      "agent": "atlas",
      "port": 3001
    }
  ]
}

Step 5: Symlink the Shared Vault

# Create shared reference documents
echo "# Shared Contacts" > ~/.openclaw-shared/contacts.md
echo "# Active Projects" > ~/.openclaw-shared/projects.md
echo "# Agent Handoffs" > ~/.openclaw-shared/handoffs.md

# Symlink vault into each agent's memory
ln -sf ~/.openclaw-shared/* ~/.openclaw-atlas/memory/vault/
ln -sf ~/.openclaw-shared/* ~/.openclaw-scout/memory/vault/
ln -sf ~/.openclaw-shared/* ~/.openclaw-muse/memory/vault/

Step 6: Start Each Agent

# Start each agent on a different port
OPENCLAW_DIR=~/.openclaw-atlas openclaw start --port 3001 &
OPENCLAW_DIR=~/.openclaw-scout openclaw start --port 3002 &
OPENCLAW_DIR=~/.openclaw-muse openclaw start --port 3003 &

For production deployments, use systemd services or Docker containers instead of background processes. See our Docker Compose guide for containerized multi-agent setups.

Real Example: Atlas + Scout + Muse

This is a production configuration used by several solo founders in the community. Three agents coordinate to cover the core operational needs of a small business.

# Check agent health every 5 minutes
*/5 * * * * curl -s http://localhost:3001/health || systemctl restart openclaw-atlas
*/5 * * * * curl -s http://localhost:3002/health || systemctl restart openclaw-scout
*/5 * * * * curl -s http://localhost:3003/health || systemctl restart openclaw-muse

# Tail all agent logs
tail -f ~/.openclaw-atlas/logs/*.log \
       ~/.openclaw-scout/logs/*.log \
       ~/.openclaw-muse/logs/*.log