A tweet showed up in my feed this week that perfectly captures a problem I keep seeing in the agent community:

For those with multiple OpenClaw agents on one machine, what's your setup to allow them to work together?
— Matt Shumer (@mattshumer_) March 2, 2026

This isn’t some niche edge case. Multi-agent collaboration — where specialized agents coordinate work across a shared objective — is the entire point of building agent systems at scale. And the fact that this question needs to be asked tells you something important about the architecture underneath.

The Problem Is Architectural, Not Operational

The replies to Matt’s tweet are full of creative workarounds: shared filesystems, message queues bolted on top, custom orchestration layers, inter-process communication hacks. People are building infrastructure around OpenClaw to get agents to talk to each other.

That’s backwards.

OpenClaw was designed as a single-agent runtime. It uses session write locks that serialize all requests per session key. One agent, one session, one task at a time. Sub-agents give you partial parallelism within that constraint, but at its core the execution model is sequential. There is no native concept of multiple independent agents operating concurrently within the same runtime, let alone communicating with each other.

When you want multiple OpenClaw agents to collaborate, you’re fighting the architecture. You end up building a multi-agent orchestration layer on top of a framework that explicitly wasn’t designed for one.

SpaceBot Was Designed for This

SpaceBot is the framework I use for all my production agent work — SEO automation, automated bug fixing, and more. Multi-agent collaboration isn’t a feature that was bolted on later. It’s the architecture.

Agents are isolated by default

Each agent in a SpaceBot deployment is a self-contained unit with its own databases (SQLite, LanceDB, redb), its own workspace with identity files, its own Cortex process for system-level monitoring, and its own set of channels and workers. They share the same binary, the same tokio runtime, and the same API keys — but data isolation is absolute. One agent can’t accidentally read another’s memory or corrupt another’s state.

This is different from running multiple OpenClaw processes that happen to be on the same machine. SpaceBot agents are first-class entities within a single runtime that understands they exist and manages their lifecycle.

Communication is explicit, not improvised

By default, SpaceBot agents can’t talk to each other. Communication is enabled through a topology graph — a set of directed links that define who can talk to whom and in what capacity.

Each link has three properties:

Property	Options	What it means
Direction	one-way, two-way	Can both sides initiate, or only one?
Kind	hierarchical, peer	Is this a manager/report relationship or a collaboration between equals?
Nodes	agent → agent, human → agent	Who are the endpoints?

When a link exists between two agents, both gain a send_agent_message tool. Bidirectional conversation channels are created automatically. Full conversation history is maintained on each side. When the conversation concludes, summaries are injected back into the originating channel. There’s even a safety valve: 20-turn auto-stop if neither agent wraps up.

You don’t build this infrastructure yourself. You declare a link in config.toml and the framework handles the rest.

Org context is automatic

Here’s a detail that matters more than it sounds: when links exist, every agent’s system prompt is automatically injected with its organizational context — who it reports to, who reports to it, and who its peers are. The agent understands its role in the topology before it processes a single message.

This means an agent with a hierarchical link to a manager agent knows to escalate certain decisions upward. A peer-linked agent knows to consult laterally. This isn’t behavior you have to prompt-engineer into existence — it’s derived from the topology graph and injected by the runtime.

Real humans fit into the graph

SpaceBot models real organization members as topology nodes too. You can link a human to an agent (or multiple agents) with the same directed, typed links. An admin human exists by default. This means your approval workflows, escalation paths, and human-in-the-loop checkpoints are all part of the same topology — not a separate concern you have to wire up.

What This Looks Like in Practice

In my deployment, I have agents handling SEO and bug detection. Each operates independently with its own memory, tools, and scheduled jobs. But they share an organizational context through the topology graph.

If I wanted my bug detection agent to inform my SEO agent when a fix might affect site structure, I’d add a one-way peer link between them. The bug agent would gain the ability to message the SEO agent directly. The SEO agent would receive that message in its own channel, with full context, and decide how to act on it. No shared filesystem. No message queue. No custom glue code.

That’s the difference between a framework designed for multi-agent collaboration and one where you’re asking Twitter how to make it work.

The Deeper Issue

Matt Shumer’s question isn’t really about OpenClaw. It’s about a pattern I see constantly: people choosing a framework because it’s popular, hitting an architectural ceiling, and then building workarounds instead of reconsidering the foundation.

OpenClaw is a good tool for what it was designed to do — single-agent interaction loops, personal assistants, chat-to-tool bridges. But when you need multiple specialized agents working together on complex objectives, you need a runtime that treats multi-agent coordination as a first-class architectural concern. Not something you improvise with shared files and custom scripts.

SpaceBot gets this right. The topology graph, explicit communication links, organizational context injection, and per-agent isolation aren’t features — they’re the architecture. Everything else is built on top of them.

If you’re trying to make multiple agents work together and finding yourself building infrastructure to do it, it might be time to look at a framework that was designed for the problem you’re actually solving.

If you’re building multi-agent systems and want to talk through architecture choices — or figure out whether you need agents at all — I’m happy to have that conversation. See more about how I work or read the full framework comparison.