AI 101: OpenClaw Explained + lightweight alternatives

There is probably no one in the AI community who hasn’t heard of OpenClaw – a project that quickly became one of the fastest-growing repositories on GitHub, surpassed 200,000 stars, and sparked a wave of new experiments and similar local agent projects.

In a matter of days, OpenClaw’s founder, Peter Steinberger, was interviewed by Lex Fridman (over 600k views) and hired by OpenAI (who even knows for how many millions) – a sign that this was more than just another incremental agent project.

What distinguished OpenClaw was its relatively light safety scaffolding, which made the underlying capabilities more visible and easier to experiment with. In that sense, Steinberger’s trajectory loosely echoes OpenAI’s early ChatGPT moment: a decision to release something imperfect but powerful, and let the consequences reshape the conversation. And the whole world of personal assistants.

And what a blunder by Anthropic. Initially, the project was called Clawdbot – a literal homophone of Claude. Instead of embracing the momentum around it – by backing the project, hiring Peter, or integrating it into their coding-agent ecosystem – they sent lawyers and forced a rename. Facepalm.

In any case, today, we want to dedicate some time to unpack why OpenClaw matters and how it works under the hood, because the architecture shapes what this system can and cannot do. There are a few very clever ideas. We’ll also suggest a few lightweight alternatives and cut through the noise to understand what the OpenClaw debate is really about.

Whether you’ve played with it or not, there’s plenty to discover. Let’s go!

In today’s episode, we will cover:

Quick Overview OpenClaw is an open-source framework for building a personal AI assistant that can act across messaging apps and workflows. You can deploy an agent that connects to channels like WhatsApp, Telegram, Discord, Microsoft Teams, and web chat, then automate tasks on your behalf. Its core advantage is personalization: the assistant can be configured to your personality, your tools, preferences, and operating context.

OpenClaw’s rise did not come from a massive corporate launch or a carefully staged rollout. As Peter Steinberger describes it, he built the initial prototype – a WhatsApp relay connected to Anthropic’s Claude – in about an hour. And that revealed that instead of switching between apps, you could simply message an agent and have it act on your behalf.

Peter could never have imagined that this small experiment would soon disrupt the entire AI industry.

This marks a broader shift in how we interact with software. Peter Steinberger points out that many apps exist mainly to gatekeep interfaces. Once an agent has unified context – your location, sleep, calendar, preferences – it can reason and act across domains in ways no siloed app ever could.

Some apps will shrink into backend APIs; others will simply disappear. OpenClaw is the clearest embodiment of the practical, context-aware automation people have wanted for years.

The project has unleashed a surge of builder energy. California’s scene went through the roof: San Francisco’s Claw’s event drew 700+ developers, with follow-up meetups in the Bay Area and LA still selling out overnight and turning away hundreds. Vienna’s ClawCon packed 500 people who came to demo what they’d built. As Peter said: “The lobster is taking over the world.”

Beyond the tech itself, Peter’s personal story has become a major source of inspiration. After more than a decade scaling PSPDFKit, a commercial toolkit for working with PDF documents inside apps, he hit burnout and lost the joy of coding. He stepped back, traveled, and only rediscovered the fun through hands-on experiments with AI agents. Because he was financially secure, he could afford to run OpenClaw at a personal infrastructure cost of $10–20K per month — a tradeoff he was okay with because he believed deeply in the direction of personal agents. That mix of playful experimentation and genuine generosity, without the usual money-first pressure, is exactly what many builders say has been missing.

It all lands perfectly in this new era of open exploration and the renewed power of open source.

And then another big thing happened: Peter was hired by OpenAI while moving OpenClaw to an independent open-source foundation that OpenAI will continue to support. This is far more than a big company hiring talent. (Stay tuned to the end to see exactly why it matters so much.)

The single biggest design decision in OpenClaw is this: it treats the agent itself as a collection of files on disk rather than as code you have to write or prompts you have to keep re-injecting.
Identity, memory, skills, heartbeat rules, tool policies – everything lives in a workspace directory as ordinary Markdown files and folders. That one shift turns the agent from a disposable script into durable, versionable, inspectable infrastructure.

Since in every AI101 episode we break down the behind-the-scenes stuff and how AI actually works, that’s where we’ll kick things off with OpenClaw explanation.

Basically, when you send a message in a messenger (like Telegram or WhatsApp), the channel adapter forwards it to OpenClaw’s central Gateway. The Gateway checks who you are, figures out which agent and session should handle it, loads the conversation history and memory, applies tool and sandbox rules, and then runs the AI agent. The agent may call tools, search memory, or execute actions, and the final response is sent back through the same messenger, all coordinated by that single Gateway process.

That’s the simple explanation. Now let’s go one level deeper and look at how OpenClaw actually works.

What’s important to understand is that OpenClaw is not just a chatbot, even if it may appear that way at first glance. It is a self-hosted AI gateway — a control plane that sits between language models, messaging platforms, tools, devices, and long-term memory.

At the center of the system is a single long-running process called, you got it, the Gateway. Everything flows through it. The Gateway is a WebSocket server that exposes a typed JSON-RPC protocol. Clients, channels, device nodes – all connect to it. Agents are executed through it. Configuration changes are applied through it. Nothing can bypass it. So if OpenClaw is running, the Gateway is the authority over sessions, routing, tool invocation, and state.

Messaging platforms, such as WhatsApp, Telegram, Discord, Slack, Signal and others, are like adapters. Each one translates a platform-specific protocol into a normalized internal envelope. When a message arrives, the channel adapter extracts identity, thread or group context, attachments, and metadata, then forwards a structured event into the Gateway. From that moment all messages look the same inside the system.

Then routing happens. The Gateway resolves a session key that encodes:

A Slack thread, a Telegram group, and a WhatsApp DM all become different session scopes. These keys determine which transcript is loaded, which memory applies, and how isolation is enforced.

Sessions here are persisted JSONL transcripts stored under the agent’s directory. They track history, model overrides, tool results, and runtime flags. OpenClaw can process sessions sequentially, concurrently or in a batched “collect” mode depending on routing configuration. Sessions can reset on idle time, daily schedules, or manual triggers.

Agents are execution runtimes. Each agent has its own identity, workspace directory, model configuration, and tool policy. Multiple agents can coexist within a single Gateway instance without sharing memory or context unless explicitly configured to do so.

The workspace is where the agent's identity becomes concrete. Files like AGENTS.md, SOUL.md, TOOLS.md, and other Markdown documents are read during system prompt construction. Skills inside the workspace/skills/ directory are automatically discovered and injected into the prompt bootstrap process. A skill is a bundle containing a SKILL.md and metadata; its documentation becomes part of the agent’s awareness. The model figures out capabilities, assembled from real files on disk.

In general, OpenClaw is built on the idea that agents should continuously acquire and use structured skills to expand what they can actually do.

Tool execution is filtered through a layered policy chain:

Tool groups expand into concrete capabilities, and the resulting tool registry is constructed deterministically before the agent runs. By default, tools run on the Gateway host. But OpenClaw can sandbox tool execution inside Docker containers with configurable isolation scopes: per session, per agent, or shared. Workspace access can be read-only, read-write, or disabled. Execution can also be routed to device nodes like companion apps running on macOS, iOS, or Android that expose capabilities like camera access, notifications, shell commands, or system queries. In that case, the Gateway moves from a local process runner role to a coordinator for distributed execution.

You might have noticed among the files the one that stands out: SOUL.md

If AGENTS.md defines capabilities and TOOLS.md defines access, SOUL.md defines identity. Thanks to that file, your agent becomes unique, and truly yours. It shapes tone, personality, long-term behavioral traits, and persistent preferences. No more temporary system prompts, it becomes a durable layer of character. Most agent frameworks treat personality as a runtime parameter or a prompt string. OpenClaw externalizes it into a file that lives inside the workspace, versioned like code, editable like documentation, and persistent across sessions.

That is super cool. Because once identity is file-backed, it becomes:

It turns “personality” from prompt engineering into infrastructure. You are no longer injecting vibes into a request. You are maintaining a structured, durable layer of self-definition. Whether that becomes a dominant pattern remains to be seen. But it is a meaningful shift from ephemeral prompting toward persistent agent identity as part of the system’s architecture.

One lesser-known but structurally important file is HEARTBEAT.md.

Unlike reactive chatbots that respond only when prompted, OpenClaw can be configured to trigger periodic agent turns. At a defined interval, the Gateway initiates a background session event. The model then reads HEARTBEAT.md – if present – and evaluates whether any action is required.

If nothing qualifies as important under the defined rules, the agent returns a no-op response (often HEARTBEAT_OK), and the event is discarded silently. If something does require attention, the agent sends a concise notification through the configured channel, such as WhatsApp or Telegram.

A typical HEARTBEAT.md file is intentionally simple. It might include:

The file can be edited at any time, and in some setups the agent can update its own checklist when it detects drift between intended behavior and actual usage.

Scheduling parameters – interval, active hours, preferred channel, and even which model to use for background evaluation – are defined in the system configuration.

Technically, this resembles scheduled automation. Conceptually, it shifts the agent from purely reactive to periodically evaluative. The agent does not wait to be addressed; it reviews context and decides whether intervention is justified.

This mechanism does not replace cron systems or workflow engines. It embeds periodic reasoning directly into the agent’s operational loop. For personal agent systems, that distinction matters.

It is also interesting how memory works in OpenClaw. It is grounded in files, and the source of truth is Markdown – MEMORY.md, daily logs, and workspace notes. On top of that, a hybrid search engine indexes both memory files and session transcripts. Text is chunked into overlapping segments, embedded via configurable providers, and ranked using a weighted combination of semantic similarity and keyword scoring. So retrieval is a deterministic hybrid search over concrete documents.

Configuration itself is treated like infrastructure. The entire system is driven by a schema-validated JSON file, which behaves like a real service configuration layer. Invalid configurations prevent the Gateway from running. Changes can be reloaded depending on mode: safe changes apply instantly, while network-level changes trigger controlled restarts.

Overall, the Gateway orchestrates everything through a single JSON-RPC WebSocket protocol. All components – agents, sessions, config, channels, UI, CLI, and device nodes – communicate through the same unified control plane. From end to end, the flow is consistent:

So architecturally, OpenClaw is a stateful AI operating system built around a central control plane. Channels are transport edges. Sessions define continuity, and scheduled turns such as those configured through HEARTBEAT.md extend that continuity beyond reactive messaging. Agents define execution boundaries, workspaces – identity, and tools – capability. Sandbox is responsible for safety, while memory – for persistence. Nodes define embodiment. And the Gateway sits at the center, enforcing order across all of it.

At a high level, OpenClaw’s workflow is similar to other local agent frameworks, but structurally, it is more “infrastructure-like” than many of them. Most local agents, such as LangChain, CrewAI, AutoGen, and AutoGPT, are application-level frameworks: developers write code to define chains or agent graphs, connect tools, and orchestrate execution inside their own runtime.

OpenClaw follows the same core reasoning loop – message → context → prompt → tool decision → model call → tool execution → response → persistence – but moves that loop into a centralized control plane.

In most local agents, routing logic, memory handling, and tool policies are typically defined within the developer’s application code. The orchestration loop runs inside the same process that the developer builds and controls. In contrast, OpenClaw moves those responsibilities into a centralized control plane and behaves more like a small AI operating system that runs as a background service.

Another difference is multi-channel integration. OpenClaw treats messaging platforms as first-class inputs, normalizing them into one internal pipeline. Many other local agent frameworks primarily expose a CLI, web interface, or API by default, with messaging integrations typically implemented separately if needed. In practice, this lowers the barrier to use. You can work with your agent directly from WhatsApp or Telegram instead of opening a terminal. And if the Gateway and model are running locally, it can still function under a weak internet connection, since only lightweight message transport depends on the network.

The memory system is also more infrastructure-oriented. Vector databases are classics for local agents’ memory, while OpenClaw treats Markdown files as the canonical source of truth and builds a hybrid semantic index on top, giving memory explicit file-backed semantics. Clean and clever.

Returning to the “boom” moment around OpenClaw: we’re now seeing a wave of new open-source agents inspired by its core idea. Many of them are lighter and, as a result, often easier to apply in practice. Let’s look at a few of them.

Here are a few practical starting points if you haven’t tried OpenClaw yet – and perhaps a couple of new ideas for those already using it.

OpenClaw becomes useful anywhere you feel friction between apps, tabs, and repetitive tasks. Daily responses in messengers apps connected together, digests from Reddit or YouTube, inbox cleanup, research summaries, strategy analysis for your market, project coordination, newsletters summaries, family calendars, your Twitter/X analysis, and even lightweight DevOps.

People also use OpenClaw to run autonomous goal systems, letting this agent generate, schedule, and execute tasks. You can stack multiple agents researching, drafting, and even preparing thumbnails for your working content pipelines. Working with memory is also an option, because you can build your own library (a knowledge base) dropping in useful sources via links.

OpenClaw can act as an automation layer over your existing systems, as well:

This video gives you a good idea what to use it for:

In general, whenever a repetitive task pops up, turn it into a small automation experiment, and over time, this may become a useful habit.

If you don’t want to install anything locally, there are now browser-based environments where you can spin up a full OpenClaw runtime in seconds. Some run entirely client-side (when your API key stays in your browser session), others let you connect to a live Gateway instance and manage sessions, skills, logs, and files visually.

Despite all the excitement, it is impossible not to point out the concerns about OpenClaw that are also lingering in the air.

But these limitations do not negate the innovation, they point out where the future upgrade of OpenClaw should focus.

OpenClaw is best understood as emerging infrastructure – powerful, experimental, and still maturing. For many years, frontier labs focused on scaling models that were like endpoints of development, but now, with the appearance of OpenClaw, we once again see that the main role is moving to orchestration: agents interacting with each other, coordinating tasks, managing context, operating across tools and services. In this new setup, personal agents are becoming the product layer.

Now let’s turn back to the news that Peter Steinberger joined OpenAI to work on personal agents. This underlines three main ideas for the AI community:

The OpenClaw moment makes something visible: open source is becoming part of AI’s core infrastructure, and personal agents are moving from demos to durable systems. The questions now center on infrastructure design, coordination, and trust.

Sources and further reading

Resources from Turing Post