OpenClaw for teams: what a real business deployment involves (not just the install)

Can OpenClaw be used by a team, or is it single-user?

It can be used by a team, but nothing about the default setup is built for one. OpenClaw ships and markets itself as a personal assistant whose state lives on your machine, and the most-watched setup video in the category (Alex Finn, ~279k views) gives the advice that follows from that: keep it personal, keep it private, don't let anyone else talk to it. That is correct guidance for one operator and exactly the opposite of what a company needs.

Businesses are running it anyway, and the good examples are unglamorous. A smart-home electronics company has its agent managing inventory and vendor purchasing: purchase orders are created in draft state inside the inventory system, and a separate cron executes those drafts only when criteria are met — the operator reports zero stock-outs so far this year. Notice what makes that work: a named system of record, draft-state writes, and a deterministic gate. None of it is agent cleverness.

The verdict: OpenClaw is not single-user by design — it is single-identity by default, and that default is the thing you have to engineer away.

What breaks when you go from one user to ten?

Four things break, and they break in a predictable order. None of them show up in a demo, which is why teams get caught by all four.

• Shared secrets. One instance means one credential set, so every user effectively holds every integration's access. A single successful prompt injection has your whole company as its blast radius rather than one person's inbox.
• Session collision and memory bleed. Agent memory is a shared surface. Once two departments write to it, one person's half-finished context starts appearing in another person's answers — and the failure is silent, because a confidently wrong answer looks like every other answer.
• Nobody owns the config. Skills get edited by whoever needed something on Tuesday. Without version control and a named owner per skill, you cannot answer "what changed?" after a bad output, which means you cannot fix it.
• Admin scope stops being acceptable. The blunt warning from that same setup video — the agent has admin access to everything you are logged into on that machine — is a reasonable trade on a personal Mac Mini. On a machine holding client data it is a breach waiting for a date.

The verdict: going from one user to ten is not a scaling problem, it is an identity problem — you are not adding seats, you are adding people who must not share credentials.

How do you isolate users — one instance per person, per department, or a container per session?

All three are valid; they answer different risks, and most companies end up running two of them. The choice is driven by what data the agent touches and where its input comes from, never by headcount.

• Per department (the default for 5–50 people). One persistent instance for sales, one for ops, one for support, each with its own service accounts scoped to that department's tools. You keep useful shared memory inside a team, and a compromise stays inside that team.
• Per person (for execs and sensitive roles). The founder, finance and anyone handling legal or HR data get their own instance. It costs more to maintain, and it is the only configuration where "my agent can read my mail" is a sentence you can say safely.
• Container per session (for anything untrusted). Inbound email, customer chat, web content and file uploads should hit a short-lived container that holds only the scopes that one task needs and is destroyed afterwards. This is the answer to the question people keep asking on r/openclaw and nobody answers: yes, companies do this, and it is the single highest-value control on the list.

What never changes across the three: credentials are per instance, not per company. If you want the infrastructure detail behind this, our OpenClaw self-hosting guide and VPS sizing guide cover the hosting side.

What does a per-department "skill" actually look like?

A skill is a narrow job with a named source of truth, a defined output, and a human owner — not a personality. The three patterns below are the ones we build most often; the shape matters more than the specifics.

• Sales follow-up skill. Reads the CRM for deals with no activity in N days, reconstructs context from the last thread and the rep's notes, and writes a follow-up as a draft. Read scope on the CRM, write scope on drafts only; the rep approves from Slack. Nothing leaves the building without a human click.
• Ops reporting skill. Pulls yesterday's numbers from the ops system and the one spreadsheet that still matters, and posts a morning brief with five numbers and two exceptions into a single channel. No write access anywhere, which makes it the safest first skill in almost every company.
• Support triage skill. Classifies inbound tickets, attaches the policy or doc excerpt that applies, and proposes a reply plus a priority. It runs in its own container because inbound customer text is untrusted input, and the human sends.

The verdict: adoption follows specificity, not capability — people use the skill that does their job, not the assistant that could do anything. If you are still deciding whether an agent is even the right tool here, our AI agents for business guide works through that first.

How do you secure a business deployment?

Start from the engineering facts rather than the fear. Internet-wide scan figures compiled in buildtolaunch's 2026 OpenClaw field review put 135,000+ exposed OpenClaw instances across 82 countries, with ~42,000 exploitable within 24 hours of discovery; the same review reports 36% of ClawHub skills containing detectable prompt injection and 1,467 malicious payloads across 3,984 skills scanned. The common cause is not exotic: default network binding plus an unvetted skill marketplace plus one over-scoped credential set.

The controls that actually work are architectural, because prompt filtering isn't one. As one practitioner put it after testing their own guardrails: the stronger the guardrails got, the dumber the attacks needed to get the same password out again. What we ship instead:

• Scoped credentials per agent — service accounts with least privilege, never one company key, never the founder's personal OAuth.
• No secrets in prompts or agent-readable config — injected at the network layer with substitution, so the model never holds a token it could be talked into repeating.
• Allow-listed egress through a proxy — the agent can reach the four domains it needs and nothing else, which turns exfiltration into a blocked request.
• Vetted skills only — reviewed before install, pinned versions, no auto-pull from a public marketplace.
• A human gate on irreversible actions. The cleanest rule we have seen stated is reversibility: money out, outbound communications and deletions get an approval; reads and undoable things run on their own.

Full configuration detail lives in our OpenClaw security hardening guide. If you already have an instance running that never got any of this, OpenClaw Rescue is the engagement for fixing a live deployment rather than starting over.

Self-host, managed, or a done-with-you deployment?

There is no universally right answer, and we lose one of these rows on purpose. If you are technical, run one business, and enjoy infrastructure, self-hosting is genuinely the correct choice and you should stop reading here.

The honest catch on self-hosting is that it is cheap in tokens and expensive in time — the community line is "I wanted an assistant, I got a DevOps side quest," and it usually shows up as suspended accounts, full disks and silent auto-update failures rather than a big dramatic outage. Our self-host vs managed comparison runs the full trade-off with numbers.

How much does a team deployment cost, and how long does it take?

Infrastructure is the cheap part and never the answer to this question. A VPS at $5–40/month runs an instance comfortably; model spend and human time are where the money is. For build pricing, the bands in our AI agent cost guide apply here too — a simple single-purpose agent lands at $1,500–$5,000, a production build from an experienced firm at $8,000–$15,000, and a multi-department transformation in the $25,000–$60,000 range.

Our own model is deliberately boring: a setup phase, then skills built per department, then training the people who will use them — roughly two months of back-and-forth end to end, with an ongoing retainer offered but not assumed. See OpenClaw setup, Hermes Agent setup or, for a full multi-department programme, agent transformation.

The verdict: budget for two months and one department, not one weekend and the whole company — every rollout that tried the second version is the one we were later called in to fix.

What happens to token costs at team scale?

They do not scale linearly, and the surprise is almost never caused by heavy users. Every published OpenClaw running-cost figure — $30–150/month in API spend, $5–20/month in hosting — is a single-operator number, and multiplying it by headcount is how budgets get set wrong. Agentic workflows are token amplifiers: a single "do this thing" becomes 50–200 model calls under the hood.

The bigger driver is idle agents. Heartbeats, polling, memory refreshes and cron loops burn tokens continuously with nobody asking anything — one 20–50 person company we worked with gave every employee a personal agent with its own budget, hit roughly $3,000–$5,000/month, and abandoned the programme inside two months. Two causes, both fixable: always-on loops nobody was using, and a flat rollout where everyone got one and few used one.

What we do now: shared departmental agents before personal ones, per-role budgets, idle loops killed by default, and cheap tasks routed to cheap models. The arithmetic is worked through in our AI agent token costs guide.

Hermes Agent vs OpenClaw for a team

For a mostly non-technical team, Hermes Agent is the lower-maintenance starting point; for a team that wants to build unusual things and has someone to maintain them, OpenClaw has more room. Hermes enforces hard memory caps (roughly 1,375 characters for USER.md and 2,200 for MEMORY.md), nudges a background memory review about every ten turns, and runs a curator that moves skills through active, stale and archive — all of which are governance features disguised as product defaults.

The framing that has held up best comes from NetworkChuck's 1.4M-view switch video: OpenClaw feels like a project, Hermes feels like a product. For a business, the only question that matters is which one is still running in month three — and that depends far more on who owns it internally than on which one you pick. Full side-by-side in our OpenClaw vs Hermes comparison.

How do you train non-technical staff to use it?

Not with documentation. The most successful individual deployment we have run was for a 65-year-old lawyer at a small practice with no technical background at all — three to five agents covering intake and client comms, drafting and document review, and billing admin. He was self-sufficient in about two weeks and saves five to ten hours a week.

Why he won is the whole lesson: deep domain expertise, plus he already knew how to manage a team of people — delegate, set expectations, review the work. Being technical is not the requirement; knowing what good work looks like is. Practically, that means training people on one skill at a time through a channel they already live in (Slack, WhatsApp, email), showing them what to reject, and keeping the terminal in the hands of whoever maintains the deployment.

Who should not do this?

Plenty of companies. We would rather say so here than three weeks into an engagement.

• Anyone whose real need is one deterministic workflow. If the job is "when a form is submitted, do these four things," that is an n8n or Make scenario with one model call, not an agent, and it will cost you a fraction of this.
• Companies with no internal owner. If nobody will own the config, review the skills and answer for a bad output, the deployment dies at month two regardless of who builds it.
• Regulated work with no appetite for gates. If every action needs a human check anyway, you have moved the work rather than automated it — start with read-only reporting skills and earn the gates back.
• Teams shopping for a headcount replacement. Roughly 30% active usage at three months is a good outcome, not a staffing plan.

If you are not sure which group you are in, the free 3-minute readiness check will tell you in less time than reading this section took, and the $499 readiness audit gives you a written build-or-don't verdict, credited in full against any build.

Frequently asked questions