OpenClaw Multi-Agent System: Run a Team of Specialized AIs

You have one OpenClaw agent running smoothly, messages routing through Telegram, persistent memory accumulating across sessions. Now you hit the ceiling every capable developer eventually reaches: one agent cannot focus on everything at once. Ask it to manage your children’s homeschooling curriculum, review a pull request, reconcile last month’s invoices, and run a literature search simultaneously, and you get mediocre performance on all four tasks — distracted context, blurry priorities, and a soul.md that tries to be everything to everyone and ends up being nothing to anyone.

The fix is not a better model. The fix is specialization. This tutorial walks you through deploying a fleet of focused OpenClaw agents, each with its own workspace, identity, and permission tier — coordinated loosely through shared file conventions and cron-driven handoffs. By the end, you will have a working multi-agent architecture that mirrors real-world deployments, understands workspace isolation at the filesystem level, implements progressive trust so new agents earn permissions gradually, and handles cross-agent communication without any custom middleware.

If you want background on what OpenClaw is and why it takes this approach to agent architecture, start with What Is OpenClaw. If you have not yet set up persistent memory, read OpenClaw Persistent Memory first — multi-agent deployments assume each agent has its own memory configuration.

Why Multi-Agent Systems?

A single AI agent is a generalist under permanent pressure. Every task you assign competes for the same context window, the same system prompt, the same mental model of who this agent is and what it is optimizing for. Three failure modes appear reliably.

Context window fragmentation. Modern LLMs have large context windows, but they are not infinite, and more importantly, filling them with unrelated material degrades output quality even before the hard limit is hit. An agent managing homeschooling notes, infrastructure alerts, and budget spreadsheets in the same session has to hold all three mental models simultaneously. Performance on each degrades compared to an agent that holds only one.

Role confusion. A soul.md that tries to define an agent as simultaneously a warm encouraging tutor, a terse senior developer, and a detail-obsessed financial analyst produces an agent that is none of those things convincingly. Persona integrity requires focus. The moment conflicting identity signals are in the system prompt, the agent averages them into blandness.

Parallel task bottleneck. A single daemon processes one conversation at a time. Tasks queue up sequentially. A research job that takes 15 minutes blocks everything else behind it. If you want simultaneous progress on multiple workstreams, you need multiple daemons.

Multi-agent systems solve all three problems. Specialized agents have smaller, coherent context windows. Each soul.md is precise because it only has to capture one role. Tasks execute in parallel across independent daemons. The coordination overhead is real but manageable, especially in OpenClaw’s architecture where agents communicate through files and cron rather than a complex message bus.

Architecture Overview: The 5-Agent Pattern

Jesse Genet, founder of Loom, documented her home multi-agent setup publicly — five OpenClaw instances running on separate Mac Minis, each handling a distinct domain of her household and work life. This is the clearest real-world example of a multi-agent OpenClaw deployment at the edge, and it is worth understanding before you build your own.

Agent	Role	Primary Tools	Device
Sylvie	Homeschooling tutor	Vision (worksheet grading), curriculum planning	Mac Mini 1
Cole	Coding and dev work	Terminal, GitHub, code review	Mac Mini 2
Renée	Finance and admin	Spreadsheet export, invoice parsing, calendar	Mac Mini 3
Atlas	Research	Web search, document ingestion, summarization	Mac Mini 4
Ghost	Automation orchestrator	Cron scheduling, cross-agent handoffs, file routing	Mac Mini 5

Each agent runs its own OpenClaw daemon on a different port, with its own workspace directory, its own soul.md, and its own Mem9 workspace. They share no in-process state. The only communication channels are a shared filesystem directory and a Telegram group routing rules config that sends messages to the right agent based on channel or keyword.

You do not need five Mac Minis to replicate this. Five VPS instances work identically. So does five separate directories on one powerful machine running five daemons on different ports — though that sacrifices the true isolation that separate hardware provides. For hobby projects and prototypes, single-machine isolation by port and directory is fine. For production family or business use, separate machines prevent one runaway agent from starving others of CPU and RAM.

Why separate hardware matters. When Cole’s daemon is doing a 10,000-line codebase analysis, it should not throttle Sylvie mid-lesson. When Renée is processing 200 PDF invoices, Atlas’s research queries should not queue behind her. True parallelism requires true isolation. Separate hardware also means Sylvie cannot accidentally read Cole’s code repositories even through a misconfigured path — the filesystem boundary is enforced by the OS, not just by software conventions.

Setting Up Multiple OpenClaw Instances

Step 1: Install OpenClaw on Each Machine

Each machine (or each VPS) gets a clean OpenClaw installation. The process is identical to a single-agent setup, but you will configure each one differently afterward.

# Run on each machine
curl -fsSL https://install.openclaw.dev | bash

# Verify installation
openclaw --version

# Initialize without starting the daemon yet — configure first
openclaw init --no-daemon

The --no-daemon flag creates the config directory at ~/.openclaw/ and writes a default openclaw.json without starting the daemon. This lets you configure the workspace before the first boot.

Step 2: Create Per-Agent Workspace Directories

Each agent should have a clearly named workspace. On the machine designated for Cole, the setup looks like this:

# On Cole's machine
mkdir -p /agents/cole/{workspace,skills,logs,shared}
mkdir -p /agents/shared  # mounted on all machines via NFS or synced via rsync

# Verify permissions
ls -la /agents/cole/

The /agents/shared directory is the cross-agent communication channel. Mount it via NFS, sync it with rsync on a cron, or use a networked filesystem like Synology DSM shared folder. The specific mechanism does not matter — what matters is that all agents can read from and write to it.

Step 3: Configure the Daemon for a Specific Port and Workspace

Each agent runs on a different port to avoid conflicts and to make routing unambiguous. Configure ~/.openclaw/openclaw.json on Cole’s machine:

{
  "agent": {
    "name": "Cole",
    "port": 3002,
    "workspace": "/agents/cole/workspace",
    "skillsDir": "/agents/cole/skills",
    "logsDir": "/agents/cole/logs",
    "memoryScope": "cole-production"
  },
  "llm": {
    "provider": "anthropic",
    "model": "claude-opus-4",
    "temperature": 0.2
  },
  "memory": {
    "provider": "mem9",
    "api_key": "mem9_sk_xxxxxxxxxxxxxxxxxxxxxxxx",
    "workspace_id": "ws_cole_xxxxxxxxxxxxxxxx",
    "top_k": 8,
    "min_relevance": 0.75,
    "auto_extract": true
  },
  "permissions": {
    "trust": "executor",
    "allowedDirs": ["/agents/cole/workspace", "/agents/shared"],
    "blockedDirs": ["/agents/sylvie", "/agents/renee", "/agents/atlas"]
  }
}

Repeat this process for each agent, changing name, port, workspace, memoryScope, workspace_id, and the allowedDirs/blockedDirs lists accordingly. Sylvie runs on port 3001, Renée on 3003, Atlas on 3004, and Ghost on 3005.

Start the daemon after configuration is complete:

openclaw daemon start --config ~/.openclaw/openclaw.json
openclaw daemon status

Workspace Isolation

Workspace isolation in OpenClaw means three things: filesystem scope, memory namespace, and skill library separation.

Filesystem scope is enforced through the allowedDirs and blockedDirs settings in openclaw.json. When an agent attempts to read or write a file, OpenClaw checks the path against these lists before executing the operation. A path not in allowedDirs is rejected. A path in blockedDirs is rejected even if it would otherwise match an allowed prefix. This prevents accidental cross-contamination even if an agent receives an instruction that references another agent’s workspace by mistake.

Memory namespace is controlled by the memoryScope field. Each agent has its own Mem9 workspace ID, so memories extracted during Cole’s code review sessions cannot bleed into Sylvie’s curriculum planning context. This is more than a convenience — it is a correctness guarantee. An agent that occasionally retrieves irrelevant memories from another domain is a confusing agent, and confusing agents drift.

Skill library separation means each agent has its own skillsDir. Cole’s skills directory contains code-review scripts, GitHub integration hooks, and terminal session managers. Sylvie’s contains worksheet grading scripts, curriculum templates, and phonics assessment tools. Neither agent can accidentally invoke the other’s skills.

The practical result is that you can update Cole’s configuration, swap out his LLM model, or retrain his skill library without touching Sylvie’s runtime at all. Each agent is a stable, bounded system.

Designing Agent Personas with soul.md

Each agent’s soul.md lives at its workspace root. This is where personality, communication style, and role constraints are defined. A well-written soul.md for a specialized agent is shorter and more precise than a general-purpose one — because there is less to cover. The agent only has to be one thing.

Sylvie: Homeschooling Tutor

# Agent Soul: Sylvie

## Identity
You are Sylvie, a warm and experienced primary school teacher specializing
in early literacy and structured phonics instruction. You have been working
with this family's children for an extended period and know each child's
reading level, learning preferences, and progress in detail.

You are patient, encouraging, and genuinely excited by small breakthroughs.
You never express frustration or doubt about a child's ability.

## Role
Your sole responsibility is educational support: lesson planning, worksheet
grading, progress tracking, and reading practice facilitation.

You are NOT a coding assistant, financial advisor, or research agent.
If given tasks outside education, respond: "That's outside my area —
you might want to ask Cole or Atlas."

## Communication Style
- Lead with encouragement before corrections
- Use age-appropriate analogies and examples (animals, nature, everyday objects)
- Keep explanations short — 2–3 sentences per concept
- Celebrate specific wins, not generic praise ("You got all five -at words
  right" not "Great job!")

## Constraints
- Never give homework without first modeling how to do it
- Never compare children to other children
- Always flag if a child seems stuck for more than two sessions on the same concept

Cole: Senior Developer

# Agent Soul: Cole

## Identity
You are Cole, a senior software engineer with deep expertise in Python,
TypeScript, and distributed systems. You are pragmatic, direct, and
allergic to unnecessary abstraction.

## Role
Code review, architecture decisions, debugging, dependency management,
CI/CD pipeline work, and documentation for technical projects.

You do not handle educational content, financial data, or research tasks.
Route those requests to the appropriate agent.

## Communication Style
- Terse and precise. Prefer code examples over prose explanations.
- Call out anti-patterns by name. Don't soften feedback that would be
  actionable if delivered plainly.
- No filler phrases. No "Great question!" No "Certainly!"
- If the answer is a one-liner, write the one-liner.

## Constraints
- Never commit code without running tests first (use the test skill)
- Never approve a PR with a failing CI check
- Flag security issues immediately, before continuing with other review comments

Save each file to the agent’s workspace root:

# On Sylvie's machine
cp sylvie-soul.md /agents/sylvie/workspace/soul.md

# On Cole's machine
cp cole-soul.md /agents/cole/workspace/soul.md

# Restart daemons to pick up new soul files
openclaw daemon restart --agent sylvie
openclaw daemon restart --agent cole

Progressive Trust: Granting Permissions Gradually

New agents should start with minimal permissions. An agent that has been running for one day has not yet demonstrated that its judgment is reliable. An agent that has been running for six months, handling hundreds of tasks without errors, has earned more autonomy. Progressive Trust formalizes this instinct into a three-tier system.

Observer (Tier 1): The agent can read files and respond to queries but cannot execute system commands, write files outside its workspace, or trigger external actions. This is the right starting point for any new agent. It can demonstrate its reasoning without having the power to cause damage.

Executor (Tier 2): The agent can run approved CLI tools, write files within its workspace, send Telegram messages, and interact with external APIs in its configured skill list. Most mature agents operate at this tier.

Supervisor (Tier 3): The agent can spawn sub-agents, write cron jobs, modify other agents’ configuration files within defined bounds, and trigger cross-agent handoffs. Reserve this for your Ghost automation agent, which exists specifically to coordinate others.

Configure trust tier in openclaw.json:

{
  "permissions": {
    "trust": "observer",
    "allowedDirs": ["/agents/cole/workspace", "/agents/shared"],
    "blockedDirs": [],
    "allowedCommands": [],
    "allowedApis": [],
    "spawnSubAgents": false,
    "writeCron": false
  }
}

To promote Cole from Observer to Executor after 30 days of reliable operation, update his config:

{
  "permissions": {
    "trust": "executor",
    "allowedDirs": ["/agents/cole/workspace", "/agents/shared"],
    "blockedDirs": ["/agents/sylvie", "/agents/renee", "/agents/atlas"],
    "allowedCommands": ["pytest", "npm test", "git status", "git diff", "git log"],
    "allowedApis": ["github.com", "pypi.org"],
    "spawnSubAgents": false,
    "writeCron": false
  }
}

Restart the daemon after every permission change. The daemon reads openclaw.json at startup and caches the permissions in memory — live config changes require a restart to take effect.

openclaw daemon restart
openclaw permissions verify

The permissions verify command prints the active permission set with human-readable labels, so you can confirm the new tier is live before the agent begins its next shift.

Connecting Agents: Cross-Agent Communication

OpenClaw agents are separate daemons. There is no built-in agent-to-agent messaging bus — by design. Message buses add complexity and create coupling points that can fail in coordinated ways. Instead, OpenClaw deployments use three simple coordination patterns that compose well and fail gracefully.

Pattern 1: Shared Filesystem

The most reliable pattern. Each agent writes output files to /agents/shared/ using a structured naming convention. Other agents (or cron jobs) poll for new files and act on them.

File naming convention: [source-agent]_[target-agent]_[task-id]_[status].json

/agents/shared/
  cole_renee_task-2026040801_complete.json   ← Cole's work is done, Renée's turn
  atlas_cole_task-2026040802_ready.json      ← Atlas research ready for Cole to review
  sylvie_ghost_worksheet-042_graded.json     ← Sylvie finished grading, Ghost prints

The Ghost agent’s primary job is polling this directory and routing files to the right next step.

Pattern 2: Telegram Channel Routing

Each agent monitors a dedicated Telegram channel. Humans or other agents post messages to the right channel to route work. Ghost’s config includes a channel map:

{
  "telegram": {
    "channels": {
      "-1001234567890": "sylvie",
      "-1001234567891": "cole",
      "-1001234567892": "renee",
      "-1001234567893": "atlas",
      "-1001234567894": "ghost"
    }
  }
}

Anything posted to Cole’s channel goes only to Cole. Anything posted to Ghost’s channel goes to the orchestrator, which decides where to route it based on content classification rules.

Pattern 3: Ghost as Orchestrator via Cron

Ghost runs scheduled tasks that read output from one agent and feed it to another. Here is a cron job that takes Cole’s daily code review output and sends it to Renée for a budget impact check — useful when dev work involves external services with costs:

#!/usr/bin/env bash
# /agents/ghost/skills/route-cole-to-renee.sh
# Runs at 18:00 daily

SHARED_DIR="/agents/shared"
TODAY=$(date +%Y-%m-%d)

# Find Cole's completed outputs from today
for file in "${SHARED_DIR}"/cole_renee_*_complete.json; do
  [ -f "$file" ] || continue

  task_id=$(basename "$file" | cut -d_ -f3)
  output=$(cat "$file")

  # Send to Renée's inbox with routing metadata
  jq -n \
    --argjson payload "$output" \
    --arg task "$task_id" \
    --arg date "$TODAY" \
    '{from: "cole", to: "renee", task_id: $task, date: $date, payload: $payload}' \
    > "${SHARED_DIR}/ghost_renee_${task_id}_ready.json"

  # Archive Cole's file to prevent reprocessing
  mv "$file" "${SHARED_DIR}/archive/$(basename "$file")"

  echo "[$(date)] Routed ${task_id} from Cole to Renée"
done

# On Ghost's machine
openclaw cron add \
  --name "route-cole-to-renee" \
  --schedule "0 18 * * *" \
  --script /agents/ghost/skills/route-cole-to-renee.sh \
  --confirm-before-execute false

Real-World Workflow: Homeschooling Automation

Jesse Genet’s most-cited use case is worksheet grading: a child completes a reading worksheet, the parent scans it, Sylvie grades it and generates a corrected version, and the corrected worksheet prints automatically. The full loop runs without any manual steps after the initial scan.

Here is how to implement it.

Step 1: Scan the worksheet. An iOS Shortcut runs when a photo is taken from a designated album. It uploads the image to /agents/shared/incoming/worksheet_TIMESTAMP.jpg. This step uses the iOS Files app integration or a Shortcut that runs a curl upload to an SSH endpoint on Sylvie’s machine.

Step 2: Sylvie grades the worksheet. A cron job on Sylvie’s machine polls the incoming folder, sends new worksheets through the LLM with a grading prompt, and outputs a corrected PDF to /agents/shared/outgoing/.

#!/usr/bin/env bash
# /agents/sylvie/skills/grade-worksheets.sh
# Runs every 5 minutes

INCOMING="/agents/shared/incoming"
OUTGOING="/agents/shared/outgoing"

for worksheet in "${INCOMING}"/worksheet_*.jpg; do
  [ -f "$worksheet" ] || continue

  filename=$(basename "$worksheet" .jpg)
  timestamp=$(echo "$filename" | cut -d_ -f2)

  # Grade via OpenClaw daemon API
  result=$(openclaw task run \
    --agent sylvie \
    --port 3001 \
    --image "$worksheet" \
    --prompt "Grade this reading worksheet. Mark each question correct or incorrect. For each incorrect answer, write the correct answer below the student's answer in red. Generate a corrected worksheet as a PDF. Return only the file path of the generated PDF." \
    --output-format json)

  pdf_path=$(echo "$result" | jq -r '.output_file')

  # Move corrected PDF to outgoing folder
  cp "$pdf_path" "${OUTGOING}/corrected_${timestamp}.pdf"

  # Archive original
  mv "$worksheet" "${INCOMING}/archive/"

  echo "[$(date)] Graded and archived ${filename}"
done

openclaw cron add \
  --name "grade-worksheets" \
  --schedule "*/5 * * * *" \
  --script /agents/sylvie/skills/grade-worksheets.sh \
  --confirm-before-execute false

Step 3: Print the corrected worksheet. A cron on Ghost’s machine polls the outgoing folder and sends new PDFs to the household printer via lp:

# On Ghost's machine — fires every 5 minutes
for pdf in /agents/shared/outgoing/corrected_*.pdf; do
  [ -f "$pdf" ] || continue
  lp -d Brother_HL_L2350DW "$pdf"
  mv "$pdf" /agents/shared/outgoing/printed/
  echo "[$(date)] Printed $(basename "$pdf")"
done

The full cycle — scan to graded printout — takes under two minutes with a modern LLM and a local printer. No parent involvement required after the initial photo is taken.

Monitoring a Multi-Agent Fleet

Checking Agent Status

Each daemon exposes a status endpoint. Check all agents from Ghost’s machine using a simple wrapper script:

#!/usr/bin/env bash
# /agents/ghost/skills/fleet-status.sh

AGENTS=(
  "sylvie:3001"
  "cole:3002"
  "renee:3003"
  "atlas:3004"
  "ghost:3005"
)

for entry in "${AGENTS[@]}"; do
  name="${entry%%:*}"
  port="${entry##*:}"
  status=$(openclaw daemon status --port "$port" 2>&1)
  echo "[$name] $status"
done

Run this before your morning check-in to confirm all agents are healthy.

Log Aggregation

Each agent writes logs to its own logsDir. To tail all logs simultaneously from a monitoring terminal on Ghost’s machine:

tail -f \
  /agents/sylvie/logs/openclaw.log \
  /agents/cole/logs/openclaw.log \
  /agents/renee/logs/openclaw.log \
  /agents/atlas/logs/openclaw.log \
  /agents/ghost/logs/openclaw.log \
  | awk '{print strftime("[%H:%M:%S]"), $0}' \
  | grep --color=auto -E "ERROR|WARN|$"

The awk prepends a timestamp to each line (since log files from different agents arrive interleaved). The grep highlights ERROR and WARN lines in color while still passing all output through.

Decision Log Pattern

Each agent appends to its own decision.md file whenever it makes a non-trivial choice — a curriculum adjustment, an architectural decision, a budget flag. Ghost aggregates these weekly:

# Ghost's weekly summary cron — runs every Sunday at 07:00
openclaw task run \
  --agent ghost \
  --port 3005 \
  --prompt "Read the decision logs from all agents this week:
    - Sylvie: /agents/sylvie/workspace/decision.md
    - Cole: /agents/cole/workspace/decision.md
    - Renée: /agents/renee/workspace/decision.md
    - Atlas: /agents/atlas/workspace/decision.md
  Summarize in a single Markdown report: what decisions were made, any anomalies or contradictions, and any items requiring human review. Save to /agents/shared/weekly-summary-$(date +%Y-%m-%d).md" \
  --confirm-before-execute false

The resulting weekly summary file can be read via Telegram message routing or simply viewed directly. This pattern surfaces quiet drift — an agent making subtly different decisions over time — before it becomes a problem.

Common Failure Modes

Agent goes off-rails on an ambiguous cron task. Add --confirm-before-execute true to any cron task where the action is irreversible (sending an email, making a purchase, deleting files). The agent will pause and send a Telegram confirmation request before proceeding. Only use --confirm-before-execute false for idempotent, low-risk operations.

Cross-agent file routing deadlock. If Ghost writes to Renée’s inbox at the same moment Renée writes to Ghost’s inbox, and both are blocking on the other to complete, you have a classic deadlock. Prevent it by always having one-directional routing for synchronous tasks. Asynchronous polling (check, act, move on) is safer than synchronous handoffs.

Memory namespace collision. If you accidentally give two agents the same memoryScope or the same Mem9 workspace ID, their memories will mix. Catch this immediately after setup with:

openclaw memory status --all-agents

Each agent should report a distinct workspace ID and a distinct entry count.

Frequently Asked Questions

Do I need separate hardware for each agent?

No — separate hardware is the ideal for production setups that need true resource isolation, but it is not a requirement. You can run multiple OpenClaw daemons on a single machine by assigning each a different port and workspace directory. A machine with 16 GB of RAM comfortably runs four to five agent daemons with headroom to spare, since each daemon’s footprint is modest (the heavy lifting happens in the LLM API calls, not locally).

The argument for separate hardware is not technical necessity but operational cleanliness: when Renée is processing 500 invoice PDFs overnight, that job should not compete with Sylvie’s real-time lesson session for CPU. Separate machines enforce that boundary at the OS level. A single machine enforces it only through well-behaved cron scheduling and task priority settings — which is fine until one agent does something unexpectedly expensive.

For a first multi-agent deployment, start with separate ports on one machine. Move to separate hardware if you observe resource contention during real use.

How do I prevent agents from interfering with each other’s memory?

Use separate Mem9 workspace IDs for each agent. This is configured through the workspace_id field in each agent’s openclaw.json. Two agents with different workspace IDs cannot read or write each other’s memories — the Mem9 API enforces this through workspace-scoped authentication.

If you want controlled memory sharing — for example, you want Atlas’s research summaries to be available to Cole when writing technical documentation — create a dedicated shared workspace and configure both agents to also query it:

{
  "memory": {
    "provider": "mem9",
    "workspace_id": "ws_cole_xxxxxxxx",
    "shared_workspaces": ["ws_shared_research_xxxxxxxx"],
    "top_k": 8
  }
}

The shared_workspaces list lets the agent query additional namespaces without being able to write to them. Read-only access to a shared namespace gives you the benefits of cross-agent knowledge without the risks of accidental writes.

Can one agent trigger actions in another agent?

Yes, through the shared filesystem and Ghost as orchestrator. Direct daemon-to-daemon calling is not built into OpenClaw — agents communicate indirectly. Agent A writes a structured task file to /agents/shared/. Ghost’s cron detects the new file, classifies the intended recipient, and either delivers it to Agent B’s inbox directory or triggers Agent B’s daemon API directly.

For time-sensitive handoffs, Ghost can call an agent’s local API endpoint synchronously:

openclaw task run \
  --agent cole \
  --port 3002 \
  --prompt "Atlas has completed the research summary at /agents/shared/atlas_cole_task-042_ready.json. Review it and identify any gaps in the technical implementation section." \
  --wait

The --wait flag blocks until Cole’s response is written, making the handoff synchronous from Ghost’s perspective. Use this sparingly — it creates the same blocking behavior as synchronous function calls and can cascade delays if Cole’s task is long-running.

What happens if an agent crashes — will it restart automatically?

OpenClaw daemons do not self-restart by default. The standard approach on Linux is a systemd service, and on macOS a launchd plist. Both will restart the daemon if the process exits unexpectedly.

On Linux, create a systemd service for each agent:

# /etc/systemd/system/openclaw-cole.service
[Unit]
Description=OpenClaw Agent: Cole
After=network.target

[Service]
Type=simple
User=openclaw
WorkingDirectory=/agents/cole
ExecStart=/usr/local/bin/openclaw daemon start --config /home/openclaw/.openclaw/openclaw.json
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl enable openclaw-cole
sudo systemctl start openclaw-cole
sudo systemctl status openclaw-cole

With this configuration, if the Cole daemon crashes, systemd restarts it within 10 seconds. Ghost’s fleet-status script will briefly show Cole as offline during that window, then normal again once the restart completes. For crash-heavy periods, check the systemd journal for root-cause logs before the automatic restarts mask the pattern:

journalctl -u openclaw-cole -n 100 --no-pager

Next Steps

With a multi-agent fleet running, the natural next concerns are security boundaries and what your agents are allowed to access. Read the guide on OpenClaw Security and Sandbox to understand how to lock down filesystem access, restrict outbound network calls, and audit what each agent has touched over time.

For inspiration on what specialized agents can accomplish in practice, OpenClaw Use Cases covers deployments in education, software development, small business operations, and personal productivity — with configuration patterns you can adapt directly.

If you are coming from an AutoGen or multi-agent framework background and want to understand how OpenClaw’s loose coordination model compares to structured group chat orchestration, the Mastering AutoGen Group Chat guide offers a useful contrast — AutoGen’s explicit turn-taking and role negotiation sits at one end of the spectrum, while OpenClaw’s file-and-cron approach sits at the other.