OpenClaw wants AI agents to run as always-on services, not one-off scripts

Script versus service

Most developers start building an AI agent by importing a library such as LangChain or CrewAI, chaining some prompts together and running a script. As dev.to reported, that request-and-response pattern has a built-in limit: the agent exists only while the script is running. When it ends, the agent is gone.

OpenClaw, an open-source project under the MIT license, takes the opposite approach. It runs as a background service (a daemon, in engineering terms) that manages the agents' lifecycle, memory and communication. The post calls this an "Agent OS", meaning something closer to an operating system for agents than to a toolkit you call from your own code.

The distinction is between a library, which gives you building blocks to put inside your own program, and a runtime, which is the always-on infrastructure the agents live in.

Behavior set in plain text files

OpenClaw describes agents in Markdown, ordinary text files kept in a workspace, instead of in code. One file, SOUL.md, covers the agent's identity, personality and place in an organization. AGENTS.md handles startup instructions, and USER.md stores context about the person being served.

The author's argument is that this makes agents easier to audit. Because the files are plain text, teams can keep them in Git and see exactly what changed in an agent's behavior between versions.

The post also says OpenClaw is built to work with any model. It lists OpenAI, Anthropic and local models run through Ollama, such as Llama and Mistral. Plugins and workflows are written in TypeScript.

Memory and an agent that speaks first

Chat-based AI tends to forget. To address this, the post says OpenClaw uses four layers of memory:

• Session: the current conversation.
• Daily: files named by date that record each day's decisions.
• Long-term: lasting patterns and accumulated knowledge.
• Shared: files that let a team of agents see the same context.

A second feature is a heartbeat, configured in a file called HEARTBEAT.md. On a schedule, the runtime wakes up, checks the state of things and can message a user first, without waiting to be asked. A script-based agent cannot do this, because nothing is running between executions.

The runtime can also connect to WhatsApp, Slack, Discord and Teams through one message router, so a single agent deployment can talk to people across all four. For storage it supports SQLite, PostgreSQL and Redis, and it can be installed locally, in Docker or on Kubernetes.

Where the post says it pays off

The author points to organizations that need data to stay in-house, including air-gapped setups, which are systems deliberately cut off from the internet. The biggest gains, the post says, come where the agent replaces manual data entry or works through portals that have no standard programming interface.

• Healthcare technology: up to a 65% reduction in manual entry, using locally run document search for patient records.
• Financial technology: audit cycles sped up by 40% with code-review agents running inside corporate firewalls.
• DevOps and software-as-a-service: release cycles cut by 30% through automated code review and pipeline integration.

These figures are attributed only to unnamed "industry data", and the post does not say where they come from. Treat them as claims to test in your own setting, not as results.

The security bill

The post is open about the downside. A runtime that can run shell commands and control a browser has far more ways to be attacked than a chatbot. The author names three risks.

First, a supply-chain attack called "ClawHavoc" showed that malicious add-on skills from a marketplace are a real danger. Second, default settings may store passwords in plain text, so encryption has to be switched on deliberately for production use. Third, prompt injection, where hidden text in content steers a model, can in principle manipulate an agent that acts on its own.

The suggested defenses are a dedicated security-configuration tool called the OpenClaw Skill and strict allowFrom lists that limit who can give the agent instructions.

The author's closing point is the trade-off. Treating an agent as a permanent service gives you proactive behavior and deeper memory, but you stop being only a prompt writer and become the operator of a runtime environment.