Can you run multiple OpenClaw agents on one machine?
Yes: one Gateway hosts many agents with separate workspaces, routed by channel bindings. What stays shared, when docs say to run separate gateways instead, and how far the isolation goes.
Yes: one OpenClaw Gateway can run several agents, each with its own workspace, state directory, and session history, with channel bindings deciding who answers where. A work agent on the business WhatsApp, a home agent on your personal one, same machine, same process. The docs put no hard ceiling on it (“dozens or even hundreds are fine”). The fine print: all of them share one process and one host, so this is organization, not isolation. For agents that shouldn’t be able to touch each other’s world, OpenClaw’s own answer is separate gateways, and ours is separate machines.
How multi-agent works
Three config pieces do all of it. Agents are declared under agents.entries: per-agent workspace (its identity and memory files), per-agent agentDir (auth and session state), optionally per-agent model defaults. Channel accounts are declared per channel. Then a bindings array routes traffic:
agents: { entries: {
home: { default: true, workspace: "~/.openclaw/workspace-home" },
work: { workspace: "~/.openclaw/workspace-work" },
}}
bindings: [
{ agentId: "home", match: { channel: "whatsapp", accountId: "personal" } },
{ agentId: "work", match: { channel: "whatsapp", accountId: "biz" } },
]A binding maps a (channel, account, peer) tuple to an agent, so “the biz WhatsApp goes to the work agent” is one line. openclaw agents list shows what you’ve built. One rule the docs bold for good reason: never reuse an agentDir across agents: shared state directories collide.
What’s actually separate, and what isn’t
Separate per agent: workspace files, session history, auth profiles, model configuration. Shared by everyone: the Gateway process itself, the host machine, and by default the filesystem: each agent’s workspace is “the default cwd, not a hard sandbox,” so an agent handed absolute paths can reach outside it unless you enable sandboxing. Per-agent tool policy and sandbox settings exist, DM scoping can keep conversation contexts apart, and config-reading tools stay owner-only, but these are policies layered on a shared process, not walls. Multiple agents is a superb way to give one operator several personas: a family assistant and a work assistant that don’t share memory, or a scheduled reader agent with no shell access chewing through an untrusted inbox next to your full-tools daily driver.
When one gateway isn’t enough
OpenClaw’s docs draw the line themselves: most setups need one Gateway, and you run separate ones “only when you need stronger isolation or redundancy.” Separate gateways on one machine are supported: the --profile flag gives each instance its own state dir, config, port, and service name, with real footguns documented (unique ports spaced widely so derived browser/CDP ports never collide; the startup guard even makes you set OPENCLAW_ALLOW_MULTI_GATEWAY=1). That buys process separation. It still doesn’t buy machine separation: every profile’s credentials sit on the same disk, readable by anything with host access.
The question behind the question
Often “can I run multiple agents on one machine?” really asks “can I put agents for different people on one box?” Technically yes: the docs describe multiple people sharing a Gateway with per-agent policies. Whether you should depends on what a breach costs: agents hold chat history, credentials, and standing tool access, and on a shared host a compromise of the process (or the machine) is a compromise of every resident at once. That’s why our safe-hosting checklist puts one operator’s agents per machine, and why Everpod’s managed OpenClaw hosting gives every customer a private machine of their own rather than a tenancy on a shared gateway: multi-agent is a feature for organizing your agents, not a substitute for a trust boundary between strangers. If the question is instead “how do I make my own agents work as a team,” that is a mission control, and it has its own page.