#I want to confirm the simplest supported way to build a multi-agent coordination system in OpenClaw

1 messages · Page 1 of 1 (latest)

main iron
#

I want to confirm the simplest supported way to build a multi-agent coordination system in OpenClaw.

Goal:

  • One orchestrator agent (Odin)
  • One or more worker agents (Bragi, Thor, Loki, and 5 persistent agents and Codex later)
  • Coordination happens through a shared state (database or files)
  • Agents wake up on a schedule, check for work, execute, and log results

Questions:

  1. What is the best supported pattern in OpenClaw for scheduled agent execution?

    • Should I use OpenClaw cron jobs, heartbeats, or something else?

  2. Can an OpenClaw agent reliably run a recurring loop like:

    • wake up
    • check external state (Postgres or local JSON)
    • claim a task
    • execute it
    • log result
  • Check if anything new came in and if not
  • go idle
  • then check again to see if there is new work

  1. What is the recommended way for an agent to check external state?

    • shell scripts via exec tool?
    • built-in connectors?
    • something else?

  2. For task locking / avoiding duplicate work:

    • is there a recommended pattern in OpenClaw?
    • or should I handle that entirely in Postgres (atomic update)?

  3. For multi-agent setups:

    • is it better to use multiple OpenClaw profiles (separate agents)
    • or sessions / sub-agents

  4. Is there an example or recommended architecture for:

    • orchestrator → worker task delegation
    • without direct agent-to-agent messaging

Constraints:

  • I want the simplest working system first
  • No Discord routing layer
  • No UI yet
  • No Codex dependency initially

What is the cleanest, most reliable minimal setup you would recommend?

crisp waveBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

glad hawkBOT
mossy mortarBOT
#

Let me verify this against the actual docs/source so I don’t hand-wave the config bits.

#

Short answer: use cron + separate agents + Postgres locking.

That’s the cleanest supported v1.

1) Best pattern for scheduled execution

Cron, not heartbeat.

Why:

  • Docs position cron for exact timing and isolated execution
  • heartbeat is for approximate, main-session, batched checks
  • Cron runs also create task records, heartbeat does not

2) Can it run that recurring loop reliably?

Yes, but not as one forever-running in-process loop.

Recommended shape:

#
  • cron wakes agent
  • agent checks shared state
  • claims one task
  • executes
  • logs result
  • exits

“Idle” should mean the run ends, then the next cron tick wakes it again.

Avoid sleep loops / polling loops inside exec or inside one long-lived agent turn.

3) Best way to check external state

For your use case, simplest reliable option is:

  • tiny wrapper scripts called via exec
  • backed by Postgres
#

Example wrappers:

  • claim-task <worker>
  • complete-task <task-id>
  • fail-task <task-id>
  • enqueue-tasks

I would not let the model freestyle raw SQL if you can avoid it.

Also, if an external system can push events, /hooks/agent is cleaner than polling later. But for v1, cron polling is fine.

4) Locking / duplicate avoidance

Handle that entirely in Postgres.

Recommended:

  • atomic claim
  • FOR UPDATE SKIP LOCKED or UPDATE ... RETURNING
  • claimed_by, claimed_at, lease_expires_at
#
  • retries / failure state in DB

I would not rely on OpenClaw for distributed work locking.

5) Multiple profiles vs sessions / subagents

For Odin, Bragi, Thor, Loki as durable workers, use multiple agents.

Use subagents later only when:

  • one live run wants to fan out parallel work
  • Odin needs temporary worker children inside a single orchestration turn

For scheduled independent workers, separate agents + cron is much simpler.

6) Recommended minimal architecture, no direct agent-to-agent messaging

This is the one I’d ship first:

  • 1 OpenClaw gateway
#
  • multiple agents: odin, bragi, thor, loki
  • shared Postgres as source of truth
  • one cron job per agent
  • cron jobs use --session isolated
  • agents interact with DB through small exec wrappers
  • no direct messaging between agents

Flow:

  • Odin cron enqueues work into Postgres
  • workers cron claim one task atomically
  • worker executes and writes result back to Postgres
  • next cron tick repeats

My concrete recommendation

Start even smaller:

  • odin
#
  • bragi
  • Postgres
  • 1 minute cron on each
  • isolated sessions
  • no heartbeat
  • no subagents
  • no JSON files

If you want the simplest reliable store, Postgres > JSON.
Honestly, even SQLite > JSON for concurrency, but Postgres is the right target.

Example shape

openclaw agents add odin --workspace ~/.openclaw/workspace-odin
openclaw agents add bragi --workspace ~/.openclaw/workspace-bragi
#

Then per agent:

openclaw cron add \
  --agent bragi \
  --name "Bragi worker" \
  --every "1m" \
  --session isolated \
  --message "Check shared queue, claim at most one task, execute it, log result, then exit. If no work, reply NO_REPLY." \
  --no-deliver

Upgrade path later

When you want Odin to fan out work dynamically inside one run:

  • keep Postgres as shared state
  • add subagents later for parallel execution
  • or add ACP/Codex later for coding workers