Multi-agent setups are where OpenClaw gets interesting: one agent researches and drafts, another does reporting, another monitors ops health. The tradeoff is operational complexity—without guardrails, you can end up with noisy runs, duplicated work, or (worst case) an agent doing something you didn’t intend.
This guide is a practical runbook for building a safe multi-agent environment in OpenClaw using: (1) session separation, (2) cron scheduling, (3) explicit delivery targets, and (4) “hard rules” that prevent accidental side effects.
Goal
Design a multi-agent setup where each agent has a clear job, runs in the right isolation mode, and delivers output to the right place—while staying debuggable and safe.
Prereqs
- OpenClaw Gateway connected and running
- At least one delivery channel configured (e.g., WhatsApp) or a local surface like webchat
- A basic understanding of your workflows (what should run daily vs. on-demand)
Mental model: agents, sessions, and runs
Think in three layers:
- Agent: the “persona + instructions” (e.g., a writer agent, an ops agent).
- Session: the runtime context for that agent (what it can see, and what state it keeps between turns).
- Run: a specific execution triggered by you (manual) or by the scheduler (cron).
When you scale up, the key is to prevent unintentional cross-talk: the writer shouldn’t inherit the ops agent’s context, and the ops agent shouldn’t “learn” draft-posting details that could cause side effects later.
Step 1: separate responsibilities (one agent = one job)
A good starting decomposition looks like this:
- Research + drafts agent: reads sources, writes draft posts, creates drafts only.
- Ops health agent: checks service health, disk, uptime, logs; read-only.
- Social drafts agent: turns newly published posts into social copy; never auto-post.
- Manager (you): decides when to publish and what to change.
Even if you could do everything in one agent, you’ll get more predictable outcomes when each agent has a narrow scope and repeatable prompts.
Step 2: use isolated sessions for scheduled automation
For scheduled jobs, prefer isolated runs. Isolation reduces “prompt drift” and helps keep each cron run deterministic. In practice, your cron scheduler should launch an agent turn in an isolated context and deliver the output to a channel you read.
Common pattern:
- Scheduled work: isolated agentTurn
- One-shot manual tasks: main session or a dedicated test session
Step 3: design cron jobs that are observable
Cron jobs need two things: (1) constraints, and (2) visibility. Constraints prevent runaway behavior; visibility ensures you notice success/failure.
At a minimum, every job should define:
- Schedule: when it runs (cron expression + timezone)
- Session target: isolated for agent turns
- Timeout: prevent long/hung runs
- Delivery: announce to a channel (or webhook) so output is visible
Table: cron job fields you should treat as “required”
| Field | What it controls | Recommended default |
|---|---|---|
schedule.kind | How timing is expressed | cron for “calendar time”, every for intervals |
schedule.expr / everyMs | When it runs | Be explicit + set tz for cron |
sessionTarget | Main vs. isolated execution | isolated for automation |
payload.kind | What executes | agentTurn (isolated) or systemEvent (main) |
payload.timeoutSeconds | Maximum run time | 10–30 minutes depending on work |
delivery.mode | Where output goes | announce (channel + recipient) |
delivery.bestEffort | Delivery reliability vs. strictness | true unless you need strict delivery guarantees |
This table is intentionally “parameter-ish”: you can translate it directly into a job definition and review it in code review style.
Step 4: add guardrails as hard rules (not “nice-to-haves”)
Guardrails work best when they’re written as non-negotiable constraints in the job prompt, plus enforced by tooling where possible. Examples:
- Draft-only: writer agents must never publish.
- Rate limits: cap web searches per run and serialize calls.
- Caps: “do not process more than N items per run”.
- External actions: “generate drafts only; never post to social networks”.
In practice, you’ll often duplicate the guardrails in two places: (1) the cron job prompt, and (2) the scripts that actually touch external systems (e.g., a WordPress draft-posting script that always sets status=draft).
Step 5: route delivery explicitly (don’t rely on “someone will check logs”)
Multi-agent systems fail silently when delivery isn’t explicit. Every scheduled run should report somewhere you’ll see it. Typical options:
- WhatsApp/Signal/Telegram: best for “human-in-the-loop” daily results.
- Webhook: best for piping results into dashboards or ticketing systems.
- None: only acceptable for jobs that have their own monitoring/alerts.
For content workflows, “announce to WhatsApp” is usually the sweet spot: it keeps you in control, and you can decide what to publish.
Step 6: keep a test lane (so production automation stays calm)
When you iterate on prompts or new agents, use a test schedule or manual run first. The rule of thumb: never test in the same job that runs daily. Create a separate “test” cron job or a manual run path that delivers to a quieter channel or to webchat.
This reduces the risk of waking up to a surprise: five half-baked drafts, or a “helpful” agent spamming a channel.
Common pitfalls
- Blended responsibilities: one agent tries to draft, post, market, and monitor—results get inconsistent.
- No caps: the agent happily processes 25 items, times out, and you get partial results.
- Implicit delivery: the run succeeded but no one saw the output.
- Schedule drift: cron runs in UTC but you’re thinking in ET. Always set a timezone on cron schedules.
Verify (short)
After a scheduled run window, do two quick checks:
# 1) Confirm the scheduler sees recent executions
openclaw cron runs --job-id <JOB_ID>
# 2) Spot-check overall system state
openclaw statusNext steps
- Pick one workflow (e.g., daily drafts) and split it into two agents: “writer” and “publisher-review”.
- Add a dedicated test job for prompt changes and keep production prompts stable.
- When you’re ready, add static charts to instructional posts by generating PNGs from source-derived numeric tables.