OpenClaw has been having a moment. When Peter Steinberger first published it in November 2025, it went viral fast, reaching 247,000 GitHub stars within weeks. The pitch was concrete: a persistent AI agent that lives in your Slack or WhatsApp, and actually does things rather than just answering questions.
If you're a company leader thinking about rolling this out to your whole team, read this first. Enterprises that tried company-wide OpenClaw deployments ran into documented security incidents, supply chain contamination, and structural mismatches that were entirely predictable. What you actually want, a persistent always-on agent system running inside your existing tools, is achievable. Just not this way.
This post covers:
OpenClaw is a free, open-source, model-agnostic autonomous AI agent. It runs on a machine you control and connects to the chat apps your team already uses. You message it in Slack or Telegram, it executes tasks across your connected systems, and it runs on a schedule without anyone pressing a button.
Supported messaging platforms: Discord, Google Chat, iMessage, Slack, Telegram, WhatsApp, Signal, and Microsoft Teams.
| Capability | What it does |
|---|---|
| Messaging channels | Connects to 8+ platforms through a single gateway. No new app required. |
| Tool execution | Runs shell commands, controls a browser, reads and writes files. |
| Calendar and email | Creates events, sends emails, and manages scheduling without manual input. |
| Scheduling | Cron jobs and heartbeats trigger any workflow on a defined cadence. |
| Model flexibility | Works with 35+ providers. Not locked to any single AI. |
| Extensibility | Skills marketplace adds CRM, research, and file management capabilities. |
Two things matter most for company adoption. It runs inside the messaging tools your team already uses, so there is no new interface to learn. And it keeps running whether or not anyone is at a keyboard. That combination, familiar channels plus continuous background execution, is what separates an always-on agent from a tool someone has to remember to open.
OpenClaw was built by a developer for developers. One of OpenClaw's own maintainers warned publicly that "if you can't understand how to run a command line, this is far too dangerous of a project for you to use safely." That's not a critic. That's someone building the project.
The structural mismatch is real. OpenClaw was designed for individual exploration. When deployed company-wide, it connects to your email, calendar, Slack workspace, CRM, and internal files with the permissions of whoever installed it. There is no role-based access control, no audit trail, and no kill switch in the default setup.
The security incidents from enterprise deployments are documented:
| Incident | What happened |
|---|---|
| Data exfiltration | Cisco's AI security team found a third-party skill performing unauthorized data extraction and prompt injection, with no adequate vetting in the skill repository. |
| CVE-2026-25253 | One-click remote code execution affecting 770,000 deployed agent instances. |
| Marketplace contamination | Roughly 20% of skills in the official marketplace were found to be malicious. |
| Legal action | Anthropic issued a cease-and-desist to the original creator. |
| Government restriction | China banned it for state agencies and banks. |
The skills marketplace adds another layer of risk. Those malicious skills included ones that performed semantic prompt injection through ordinary text files, installed payloads that bypassed macOS Gatekeeper, and used bot voting campaigns to surface themselves at the top of the charts. Our review of high-profile AI failures covers how these patterns play out when companies skip the security thinking.
None of this means the concept is wrong. A persistent, always-on agent that runs in your existing messaging tools and handles multi-step workflows without manual prompting belongs in your company. OpenClaw proved the demand is real. The problem is the implementation, not the idea.
For companies, the value the concept demonstrates sits in two places.
A persistent operations agent runs continuously, pulls from your internal sources of truth, and handles structured tasks that repeat daily. The team does not prompt it. It runs.
Common tasks it handles:
The efficiency gain scales with team size. One employee reclaiming 30 minutes of record entry per day is a marginal win. A 50-person team doing the same adds up fast.
The second use case is multi-tool workflows that currently live in someone's head, get skipped when that person is out, and resist documentation because they feel too complex to write down. A well-configured agent executes them consistently, on schedule, every time.
Examples of what it automates:
The quality of the agent's output depends directly on the quality of the data it reads. We've written about why data preparation is the prerequisite for every AI system that works in production, and it holds here.
What you want is the same set of capabilities with a different foundation. Persistent, always-on, multi-tool, running in Slack and whatever else your team uses, but built on owned intelligence: your architecture, your data, your security controls, your governance. Here's the six-step process.
| Step | What you're doing | Why it matters |
|---|---|---|
| 1. Define the perimeter | Map what the agent can and cannot access | Shapes every security decision downstream |
| 2. Scope agent identities | Create separate agents by function | Limits blast radius; improves accuracy |
| 3. Set interaction windows | Define where and how employees can give instructions | Prevents ungoverned usage |
| 4. Connect verified tools | Build and review each MCP connector before connecting | Eliminates supply chain risk |
| 5. Add governance | Structured logging, alerts, and a kill switch | Required for production and compliance |
| 6. Pilot first | Start with two workflows for 4 to 6 weeks | Catches problems before they scale |
Before connecting anything, map what the agent can access and what it cannot. This decision shapes everything that follows.
Three questions to answer before you start:
For most companies, the read scope starts with documents in Google Drive or SharePoint, project data from tools like Jira or Notion, and conversation history from Slack or Teams. The write scope is usually narrower: updating CRM fields, creating calendar events, posting to specific Slack channels, sending emails on behalf of defined senders. Anything outside that perimeter, the agent doesn't touch.
For company-wide ai workflow automation services, you build a set of agents, each scoped to a specific function with access only to what it needs. This scoping limits the blast radius if something goes wrong and makes each agent more accurate, because a narrowly defined agent consistently outperforms one trying to work across everything.
| Agent | Read access | Write access |
|---|---|---|
| Customer operations | CRM, support tickets, customer channels | CRM field updates, ticket status changes |
| Content operations | CMS, publishing queue, brand guidelines | Draft creation, status updates |
| Sales support | CRM, proposal library, calendar | Calendar events, CRM notes |
The connectors between agents and tools are built using Model Context Protocol (MCP). We covered how MCP works in practice in our comparison of Claude Cowork and Claude Code.
Enterprise conversational ai deployments fail when any employee can instruct the agent through any channel at any time without governance. Interaction windows solve this by defining exactly where and how employees can give instructions: a dedicated Slack channel for each agent scope, a defined command set, and an explicit list of what the agent will always decline.
Human checkpoint design by workflow type:
| Workflow type | Checkpoint behavior |
|---|---|
| Routine tasks with defined outputs | Auto-approve within set parameters |
| External communication | Human review required before sending |
| Financial data | Human review required |
| Irreversible actions | Human review required, no exceptions |
Every MCP server in an enterprise deployment comes from a verified source or is built and reviewed internally. Unlike the OpenClaw skills marketplace, each connector is reviewed before it touches your systems and scoped to the minimum permissions the agent actually needs.
Common connectors and how they're scoped:
A persistent agent running continuously with access to your tools needs observability infrastructure. You need to see what it did, when, and why, and you need to be able to stop it within seconds.
The minimum observability stack for any serious enterprise ai strategy:
| Industry | Additional compliance requirement |
|---|---|
| Healthcare | HIPAA-compliant audit trail |
| Financial services | SOC 2 or equivalent logging |
| Legal | Privilege-aware access controls |
| General enterprise | Structured logs plus incident response playbook |
The baseline requirement across all industries is a complete, auditable record of what any autonomous system did on your behalf.
The smoothest workflow automation services rollouts start with two workflows and run them for 4 to 6 weeks before expanding.
| Workflow type | Selection criteria |
|---|---|
| High-frequency, low-stakes | Runs daily, well-defined output, reversible if something goes wrong |
| Medium-frequency, higher-stakes | Time savings are obvious, human still owns the final decision |
After running both, measure output quality, collect employee feedback, and refine prompts, permissions, and interaction windows before you expand. Companies that launch agents across six workflows at once end up with systems that are hard to debug and employees who don't trust them.
This is not a guide for deploying OpenClaw. And it is not a guide for rolling out OpenAI, Claude, or any other vendor's platform across your team.
What I'm describing is a custom, persistent, always-on agent system grounded in your owned intelligence. Your architecture. Your data. Your security controls. Your governance. The model underneath can be any major provider or a self-hosted one if your compliance requirements call for it. The capability doesn't belong to any vendor. It belongs to you.
What this system looks like in practice:
If this is what you're trying to build, one of our product managers and one of our AI engineers will meet with you, understand your specific use case, and give you a clear picture of what it takes to deploy this in weeks with the security guardrails, governance infrastructure, and interaction windows your team needs.
