Multi-agent collaboration where access matters more than intelligence.
A plugin for OpenClaw. Connects different people's OpenClaw instances across devices and networks — they delegate tasks based on who actually has the key.
MultiClaws turns a group of OpenClaw instances — sitting on different people's machines — into a coordinated team. Each OpenClaw stays on its own machine, keeping its own credentials, files, and network access, and delegates tasks to teammates whose machines have what they need.
Result: a quarterly review that requires data from your colleague's Google Sheets, your company's internal OA system, and your own git history can be assembled in a single prompt — without anyone sharing passwords, copying files, or starting a screen-share.
┌─────────────────────────┐ ┌─────────────────────────┐
│ Eric's MacBook │ ◀─────▶ │ Colleague's PC │
│ • Local git │ A2A │ • Google Workspace │
│ • Personal email │ │ • Sales spreadsheets │
│ • Telegram │ └─────────────────────────┘
└─────────────────────────┘
▲
│ A2A
▼
┌─────────────────────────┐
│ Office Server │
│ • Internal OA │
│ • Production logs │
│ • MySQL │
└─────────────────────────┘
Most multi-agent frameworks (CrewAI, AutoGen, OpenAI Swarm) assume you split work by capability: this agent is good at writing, that one is good at math. That model doesn't survive contact with reality, because in real life:
The division of labor isn't about who is smarter. It's about who has the key.
Your colleague's machine isn't smarter than yours — it just happens to be the one logged into the sales dashboard. The office server isn't a better writer than your laptop — it just happens to be the only thing inside the corporate network.
MultiClaws routes work by access, not capability. The profile bio isn't a resume; it's a declaration of what each OpenClaw can reach.
This is the difference between a single-machine multi-agent system and an actually distributed one.
1. Distributed teams without a shared cloud. Sales lives in Google Sheets on your colleague's account. Engineering metrics live on the office server. You write the QBR. Today you DM people for screenshots; with MultiClaws your OpenClaw does the asking.
2. Cross-device personal use. Photos on your iPad, finance app on your phone, codebase on your laptop, smart-home logs on your home server. Ask "summarize my last weekend" — each device contributes what only it can see, then your laptop merges the result.
3. Internal tools that have no API. Most internal SaaS dashboards expose no API, but they're already logged in inside someone's browser. MultiClaws gives them a "human-in-the-loop browser OpenClaw" that other OpenClaws can call — no integration to build.
1. Profile bio (one sentence per machine). Each OpenClaw instance has a plain-text bio: "I have access to Google Workspace and the company sales spreadsheet." No YAML, no schema, no JSON.
2. Discovery via team join. Create a team → share an invite code → teammates join. Every OpenClaw reads everyone else's bios.
3. A2A delegation at runtime. When you give your OpenClaw a task, it reads the team profile, decides who can do which sub-task, and dispatches via the A2A protocol. Replies are merged and returned to you.
You: "Generate this month's QBR."
│
▼
[Your OpenClaw reads team profiles]
├─▶ Colleague's OpenClaw → pulls sales from Google Sheets
├─▶ Office server's OpenClaw → pulls OA + production logs
└─▶ Your own machine → reads local git history
│
▼
[Merge and reply to you]
A teammate's OpenClaw can also delegate further on its own. If it needs a chart and sees from the team profiles that another OpenClaw has charting tools, it dispatches independently — no central orchestrator required.
These are the trade-offs that defined the product. Each had a rejected alternative.
1. Plain-text profile bios, not YAML manifests. A bio is what an OpenClaw reads to decide whether to delegate. A YAML manifest with formal capability fields would be more parseable but less expressive — and the LLM is already a great parser of natural language. The cost of being wrong is low (re-route on failure); the cost of friction onboarding teammates is high. Bios won.
2. Route by access, not capability. Capability is duplicative — every machine can run an LLM. Access is unique — only one machine is logged into your colleague's Google account. Routing by the unique attribute is what makes coordination meaningful instead of decorative.
3. Install via "tell your OpenClaw", not CLI. The user is already talking to an OpenClaw. Adding a CLI step breaks conversational flow and forces a context switch. The OpenClaw reads install instructions, runs them, and reports back — same affordance as anything else they'd ask. Removing the install ritual was worth more than the convenience of a one-liner.
4. Trust deferred to v1, not v0. Today, anyone with a team's invite code can delegate to any member. This is unsafe in production, intentionally. Shipping the coordination primitive first lets us learn what trust patterns people actually need — per-OpenClaw allowlists? per-task approvals? capability scopes? — before designing the security layer. Shipping a guess would have locked in the wrong abstraction.
5. Synchronous delegation in v0; async in v1. Sync is easier to reason about and easier to debug — important when everyone is forming a mental model of A2A for the first time. Async unlocks parallelism but complicates failure handling. We traded throughput for understandability in the early-adoption phase.
Tell your OpenClaw:
Run
openclaw plugins install multiclawsand tell me what it can do.
That's the entire installation. The OpenClaw handles npm, configuration, and the first profile setup.
Then, in any chat:
"Create a team called my-team."
"Join team with invite code mc:xxxxx"
"Ask Bob to pull this week's sales numbers."
"Show all OpenClaws in the team."
Where MultiClaws is heading: production-safe, parallel, multi-turn collaboration across teams of any size.
| Status | Feature |
|---|---|
| 🚧 v1 (next) | Async delegation — fan out to multiple teammates in parallel |
| 🚧 v1 (next) | Multi-turn sessions — OpenClaws can clarify and iterate between each other |
| 🚧 v1 (next) | Permission layer — per-OpenClaw allowlists, task scopes, approval gates |
| 🔭 future | Capability-aware routing — learned scheduler optimizes who-asks-whom |
| 🔭 future | Observability — timeline view of who delegated what to whom |
| What it does | How MultiClaws differs | |
|---|---|---|
| MCP (Model Context Protocol) | Standard for connecting an LLM to a single host's tools | MCP is single-machine. MultiClaws is cross-machine, cross-account, cross-network. |
| CrewAI / AutoGen | Multi-agent orchestration in a single process | Same machine, divided by capability — not actually distributed. |
| OpenAI Swarm | Lightweight handoffs between agents in one runtime | Same constraint; no cross-device. |
| Direct A2A | Raw protocol for agent-to-agent calls | Requires manual routing. MultiClaws adds discovery, profiles, and a UX layer on top. |
Full skill spec: skills/multiclaws/SKILL.md
npm install
npm run build
npm testMIT