OpenClaw Multi-Agent Coordination Plugin Design

Create a public OpenClaw plugin that turns OpenClaw from a personal assistant runtime into a parallel multi-agent work system.

OpenClaw already has strong distribution, channels, tools, sessions, subagents, cron, webhooks, background tasks, and local-first UX. The missing primitive is a shared coordination layer that lets multiple independent agents pull from the same ordered queue, claim work safely, hand off outputs, wait on dependencies, and advance repeatable workflows without sharing one chat context.

The product frame is:

``text OpenClaw gives agents tools. RedKey gives agents a shared queue they can pull from in parallel. ``

The public plugin should make this feel native to OpenClaw. The paid RedKey layer provides the real verified coordination bus.

The power is not "one agent delegates to five agents."

The power is:

``text five agents can all pull from the same queue ``

That is what creates scale.

In a delegation model, the parent agent remains the bottleneck. It has to decide what to send, who to send it to, when to check back, and how to merge results. That works for small jobs, but it still behaves like one busy manager.

In a pull-based coordination model, work is published once. Any eligible agent can see it. The first valid claim wins. As soon as one task completes, dependent tasks open. More agents can join the queue without rewriting the workflow.

Scale comes from queue depth and agent availability, not from a single model deciding every handoff.

This should be the lead use case:

OpenClaw already has a real concept of multiple agents. It is not only one giant agent doing different things.

OpenClaw supports:

• Isolated agents: each agentId can have its own workspace, persona files, auth profiles, model config, and session store.
• Channel/account routing: inbound messages can route to different agents based on channel, account, peer, team, guild, or thread bindings.
• Subagents: an agent can spawn isolated child sessions for background work through sessions_spawn.
• Background task tracking: subagent, ACP, cron, and CLI runs create task records with status.
• Task Flow: durable multi-step flow tracking above background tasks.

That is useful, but it is not the same as a shared multi-agent operating queue.

OpenClaw's current multi-agent model is mainly:

``text route this message to the right isolated agent or let this agent spawn a child run for a delegated task ``

The RedKey plugin adds:

``text publish work to a shared queue let multiple eligible agents pull work in parallel order competing claims record handoffs open dependent tasks advance workflow state make task receipt visible outside any one chat/session ``

Public name:

``text OpenClaw Multi-Agent Coordination ``

Possible repo names:

``text openclaw-coordination openclaw-multi-agent openclaw-workflows ``

Recommended repo name:

``text openclaw-coordination ``

Public description:

> Parallel multi-agent coordination for OpenClaw. Give independent OpenClaw agents a shared queue where they can pull work, claim tasks, hand off outputs, and advance workflows together.

The product has two layers.

The public plugin provides:

• Agent-facing coordination tools.
• Workflow and task template definitions.
• Local simulator mode for development and demos.
• RedKey bus adapter for verified coordination.
• CLI commands for status, start, approve, and inspect.
• Minimal status UI if OpenClaw plugin surfaces make that practical.

The public plugin does not expose HCS implementation details.

RedKey provides:

• Hosted claim bus.
• Verified event ordering.
• RedKey-managed HCS topics and operator account for hosted plans.
• Customer-owned HCS account/topics for enterprise.
• Metering, billing, usage limits, and receipts.
• Team cockpit, approval inbox, analytics, template marketplace, and support.

Internal truth:

``text HCS is the claim and queue mechanism. ``

Public language:

``text RedKey Verified Coordination provides a hosted coordination bus with ordered task claims and durable handoffs. ``

A user has multiple OpenClaw agents:

• researcher
• writer
• reviewer
• producer

They start a workflow:

``text Podcast prep -> script -> approval -> clips -> publish checklist ``

Each task is published to a shared bus. Eligible agents see work for their role. Several agents can pull from the same workflow at once. The bus resolves claim order, so only one agent owns each task. Completion opens the next task. The user can see the current workflow state and approve gates.

The user does not need to manually copy context between agents.

Scale example:

``text One podcast workflow creates 12 tasks. Five eligible agents watch the same queue. Three independent tasks open after guest intake. Researcher, writer, and producer claim different tasks at the same time. The workflow moves faster because work is pulled in parallel. ``

The cleanest use cases are ones where multiple agents can own different roles, but the work needs shared state.

A solo OpenClaw user has several specialist agents:

• research agent
• writing agent
• coding agent
• QA agent
• admin agent

Today, the user can talk to each agent or ask one agent to spawn subagents. With coordination, the user can start a workflow and let each specialist pull the next eligible task from the shared queue.

Example:

``text research -> write brief -> user approval -> generate assets -> publish checklist ``

Podcast production needs repeated handoffs:

``text guest intake -> research -> episode script -> host approval -> clips -> show notes ``

Each step can be owned by a different agent. The queue makes it clear what is waiting, who claimed it, what output was produced, and what opens next.

Software work needs role separation:

``text intake -> product spec -> implementation plan -> build -> QA -> approval ``

OpenClaw can run the agents. RedKey coordination gives the agents shared task state and ordered handoffs.