Klaus
· by Robbie

OpenClaw for Teams: What Changes When Multiple People Share an Agent

I’ve watched enough teams go from one person using OpenClaw to five, and the pattern is consistent.

OpenClaw works well for one person. You set up your agent, configure your bootstrap files, connect your integrations, and everything hums along. The problems start when a second person needs access. Not because the software breaks, but because assumptions you never thought about become visible. Whose memory is the agent using? Whose API keys? What happens when your coworker tells the agent something that contradicts what you told it yesterday?

These aren’t hypothetical questions. They come up in nearly every team deployment we see at Klaus. The answers depend on how you architect your setup, and there are real tradeoffs between simplicity, isolation, and cost.

If you’re running OpenClaw for a small business and it’s just you, none of this matters yet. But the moment you’re thinking about adding a second user, the decisions you make early will save you from reworking everything later.

What OpenClaw Assumes About Its Users

OpenClaw’s security model is built around a single trusted operator per gateway. The OpenClaw security documentation is explicit about this: it is “not a hostile multi-tenant security boundary for multiple adversarial users sharing one agent/gateway.”

That’s not a limitation they’re embarrassed about. It’s a design choice. OpenClaw is a personal AI agent. It assumes the person messaging the agent is the same person who configured it, owns the API keys, and set up the integrations.

In practice, this means every person who can message your agent can steer the same permission set. If the agent has access to your CRM through Apollo, everyone who can DM that agent has access to Apollo. If you connected Google Workspace, everyone who messages the agent can ask it to read your calendar or send emails on your behalf.

The same applies to workspace files. OpenClaw loads bootstrap files (AGENTS.md, SOUL.md, USER.md, and others) into every conversation (OpenClaw workspace docs). These files define how the agent behaves, what it remembers, and how it communicates. When one person edits SOUL.md to tune the agent for research, that change affects every conversation the agent has with anyone.

The OpenClaw community has been vocal about this. A feature request for role-based access control documents the gap: all users with access to the system can view and modify sensitive information like API keys, credentials, and configurations. One commenter put it simply: “Once we start sharing OpenClaw across a team, security becomes a real concern pretty quickly.”

None of this is a reason to avoid using OpenClaw with a team. It’s a reason to be deliberate about how you set it up.

Three Ways Teams Actually Deploy OpenClaw

There are three deployment models, each trading simplicity for isolation. The right choice depends on your team size, trust level, and how much operational overhead you’re willing to accept.

ModelIsolation LevelComplexityBest For
One agent, multiple usersConversation history onlyLow2-3 people, same role, high trust
Multiple agents, one gatewayFull agent isolation, shared infrastructureMediumI don’t recommend this
Separate gatewaysComplete separationHighMost users

One agent, multiple users (simplest)

Everyone messages the same agent. You set session.dmScope to "per-channel-peer" so each person gets their own conversation history (OpenClaw security docs). This means your messages stay separate from your coworker’s messages.

What you get: isolated conversation threads. What you don’t get: separate permissions, separate tools, or separate memory. The agent’s MEMORY.md, bootstrap files, API keys, and tool access are shared across everyone.

This works for small teams of two or three people doing similar work, where everyone trusts everyone with the same level of access. It stops working when someone on the team should have access to different tools, or when two people need the agent configured differently for their workflows.

Multiple agents, one gateway (isolated)

Each team member gets their own agent with a separate workspace, state directory, and session store. The OpenClaw multi-agent documentation describes this as “multiple isolated agents” operating within a single gateway instance.

Channel bindings route messages to the right agent based on sender identity. Each agent has its own SOUL.md, its own AGENTS.md, its own API keys, and its own tool permissions. If your sales lead needs Apollo access and your operations person doesn’t, you configure that per agent.

Agents can optionally share memory. If you want your research agent to search transcripts from your outreach agent, you configure extraCollections in the QMD memory settings (OpenClaw multi-agent docs). Shared memory is opt-in, not the default.

In theory, this gives you real isolation without running separate infrastructure. In practice, someone needs to maintain the routing configuration and manage per-agent settings, and the complexity rarely pays off compared to just running separate gateways. I don’t recommend this for most teams.

Separate gateways (full isolation)

Each person or sub-team runs their own gateway on their own VM. The OpenClaw security documentation recommends this approach when you need separate trust boundaries: “split trust boundaries with separate gateways” using distinct OS users, hosts, or VPS instances (OpenClaw security docs).

This gives you complete separation. Separate credentials, separate memory, separate network access, separate everything. One person’s agent has zero visibility into another person’s agent.

This is what I recommend for most teams. The operational overhead of separate VMs is lower than the headache of debugging shared-state issues, and the cost difference is smaller than people expect. Compliance requirements, external contractors, and cross-department boundaries make it essential, but even without those, full separation is the cleanest path.

Where Teams Actually Get Stuck

The deployment model is the easy part. The hard part is what happens after everyone starts using their agents.

Memory collisions

Two people give the agent conflicting instructions. One person tells it “always format reports as bullet points.” The other tells it “use narrative paragraphs for reports.” With per-peer sessions, these instructions stay isolated in conversation history. But shared workspace files (SOUL.md, AGENTS.md, MEMORY.md) reflect whoever edited last.

The result: the agent’s behavior drifts unpredictably. Someone notices the agent stopped formatting things the way they expected, traces it back to a workspace file edit, and now the team is having a conversation about who “owns” the agent’s personality. This isn’t a technical problem. It’s an organizational one.

Credential sprawl

Without role-based access control, every user with system access can view and modify API keys and configurations (GitHub issue #8081). For a solo user, this is fine. For a team with Apollo, Hunter.io, Google Workspace, and Slack integrations, that’s a lot of credentials visible to everyone.

The concern isn’t that your teammates are malicious. It’s that if any single account gets compromised, all connected services are exposed. Rotating one key is annoying. Rotating all of them because they were stored in the same place is a bad afternoon.

Bootstrap file conflicts

AGENTS.md defines how the agent uses memory and tools. SOUL.md defines its persona and communication style. These files are loaded into every conversation, with a default limit of 20,000 characters per file (OpenClaw workspace docs).

When one person optimizes AGENTS.md for research workflows and another needs it tuned for outreach, the last edit wins. There’s no merge, no versioning, no conflict resolution. The file is a single source of truth, and on a shared instance, “truth” is whatever was saved most recently.

Cost attribution

KPMG’s AI Quarterly Pulse Survey found that system complexity is the number one deployment challenge for AI agents, with organizations actively deploying agents jumping from 11% to 26% through 2025. For teams, one dimension of that complexity is simple: who used how many tokens?

OpenClaw doesn’t track per-user token consumption natively. When five people share an instance and the monthly AI bill spikes, figuring out which workflow or which person drove the increase requires digging through session logs manually.

What to Think About Before Adding Team Members

These aren’t prescriptions. Every team’s situation is different. But teams that think through these questions early tend to avoid the most common rework.

Isolation reflects trust. The three deployment models aren’t just technical choices. They reflect how much your team trusts each other with shared tool access. If everyone on your team has the same role and the same access requirements, a shared agent is fine. If roles differ, or if there’s any sensitivity about credential access, multi-agent or separate gateways save you from having an uncomfortable conversation later.

Separate credentials early. Even if you start with a shared agent, use separate API keys per person where possible. Rotating one compromised key is manageable. Rotating all of them because they lived in the same configuration file is the kind of problem that eats an entire day.

Decide who owns the bootstrap files. If multiple people will shape the agent’s behavior, decide upfront who has authority over SOUL.md and AGENTS.md. Some teams version-control their workspace directory with git, which creates an audit trail and lets you roll back changes. Others designate one person as the “agent admin.” Either approach works. Having no approach is what creates friction.

Budget for governance. Deloitte’s State of AI in the Enterprise report (surveying 3,235 senior leaders) found that only one in five companies has mature governance for autonomous AI agents. For a five-person team, governance doesn’t need to be formal. It means answering: who approves new tool access? Who reviews what the agent did last week? Who handles it when the agent sends an email it shouldn’t have?

Start small, then expand. Most teams we see at Klaus start with one person running OpenClaw solo, prove the value, then add teammates. The ones who have the smoothest transitions are the ones who chose their isolation model before adding the second user, not after the third user ran into a memory collision.

How Klaus Handles Team Deployments

I’m biased here, obviously. But this is what we built the Managed Rollout plan for.

Klaus’s Managed Rollout ($1,000+/month) is designed for teams of five to fifty. We set up dedicated VMs per person or team, pre-configure integrations, and run Clawbert (our monitoring agent) across all instances. Billing is consolidated. Updates are coordinated so one team member’s instance doesn’t fall behind.

The parts that matter most for teams: credential isolation across team members so API keys aren’t shared, instance-level monitoring so we catch problems before your team does, and a single point of contact when something goes wrong. The individual plans (Starter at $19/month, Plus at $49/month, Pro at $200/month) work well for solo users, but they aren’t designed for team coordination.

That said, not every team needs managed hosting. If you have someone comfortable with server administration and your team is two or three engineers, self-hosting with separate gateways works fine. The calculus shifts when the team grows past five people, when the users aren’t technical, or when nobody wants to be on call for the agent infrastructure.

Frequently Asked Questions

Can multiple people share one OpenClaw agent safely?

Yes, with caveats. Setting session.dmScope to "per-channel-peer" isolates conversation history by sender. But tool permissions, API keys, and bootstrap files are shared. Everyone who can message the agent has the same access level. For trusted teams of two or three, this is often sufficient. For larger teams or sensitive workflows, use multi-agent or separate gateway deployments.

How do you prevent one team member from seeing another’s API keys?

As of now, OpenClaw does not have role-based access control. All users with system access can view credentials stored in the configuration (GitHub issue #8081). The workaround is running separate agents (each with its own state directory and credentials) or separate gateways. Managed hosting services like Klaus handle credential isolation at the infrastructure level.

What happens to the agent’s memory when multiple people give it instructions?

With per-peer sessions, conversation history stays isolated per user. But shared workspace files (MEMORY.md, SOUL.md, AGENTS.md) reflect the most recent edit from any user. Two people giving conflicting instructions through workspace files will create inconsistent agent behavior. The solution is either designating one person to manage workspace files or running separate agents.

How much does OpenClaw cost for a team of five?

It depends on the deployment model. Five separate Starter instances on Klaus cost $95/month ($19 each) but lack team coordination features. Five Pro instances cost $1,000/month. The Managed Rollout plan starts at $1,000+/month with consolidated billing, dedicated setup, and infrastructure management. Self-hosting costs vary by provider. See the full pricing breakdown for details.

Do I need separate VMs for each team member?

I strongly recommend separate VMs for each user. If you do this, you should share any relevant skills or files using GitHub, Google Drive, AgentDrive.co, or another file sharing service. The pros and cons of these different services are a whole separate post.

Key Takeaways

  • OpenClaw is designed as a personal agent with a single-operator trust model. Adding team members requires intentional architecture decisions.
  • Three deployment models exist, but separate gateways (one VM per person) is the right default. Shared agents work for tiny trusted teams; multi-agent per gateway adds complexity without enough payoff.
  • The real friction points for teams are memory collisions, credential visibility, bootstrap file ownership, and cost attribution, not the initial technical setup.
  • OpenClaw does not currently have role-based access control. All users with system access share the same credential visibility (GitHub issue #8081).
  • Only 20% of organizations have mature governance for AI agents (Deloitte, 2026). For teams, governance means deciding who owns agent behavior, reviews logs, and approves tool access.
  • Start with your isolation model before adding the second user, not after the third one runs into problems.

Want to try Klaus? Sign up at klausai.com.

If you’re not ready for a team deployment and just want to see what OpenClaw can do for you personally, start with OpenClaw for Small Business.

Sources