Principles for Autonomous System Design: OpenClaw Deep Dive

ELI5/TLDR

A Berkeley networking PhD spent a month inside the OpenClaw codebase trying to figure out why this new “always-on autonomous agent” feels different from LangChain or Claude Code. His answer: three layers (connectors, gateway, runtime), two ways of handling time (heartbeat for the unscheduled, cron for the scheduled), and skills-as-markdown-files that the agent can write for itself. The code is ugly but the design is clean. Implementation abstractions don’t matter much anymore. Design abstractions do.

The Full Story

Four phases of LLM evolution

Krentsel frames the last seven years as four phases, each one wrapping a loop around the previous.

Phase zero: LLMs as next-token predictors. BERT, GPT-1 through 3. You feed in tokens, you get one token out.

Phase one: wrap a loop around the transformer so it generates a whole sentence, then a paragraph, then a story. This is what we started calling a large language model.

Phase two: fine-tune those LLMs to behave like assistants. ChatGPT, Claude, Gemini. Then add tools and orchestration on top: LangChain, AutoGen, CrewAI. He’s blunt about what these were:

Static wrappers around a call to some large language model that had a series of steps and you could orchestrate, okay, first this agent goes, then this agent goes.

Phase three is now. Same LLM under the hood, same tools, but the loop is dynamic. The agent decides which tools to call, when to call them, what to search for. Claude Code is here. OpenClaw, he argues, is one rung further out, because it can rewrite itself.

The mental image he uses is matryoshka dolls. Each phase is a doll wrapped around the previous. The interesting question is: what’s the next doll?

The two design goals

OpenClaw markets itself as “the AI that actually does things.” Krentsel reads that tagline like a forensic accountant.

“Actually doing” requires autonomy. Closed control loop. Agent observes the result of its action, decides the next action, doesn’t get stuck on surprises.

“Things” requires generality. The marketing didn’t say “does email.” It said “does things.” So the system either has to be smart enough to handle anything, or flexible enough to add new capabilities on the fly.

Most of the architecture falls out of these two requirements.

Three layers

Connectors are how the outside world reaches the agent. WhatsApp, Discord, Gmail, iMessage. He’s frank that this layer is hacky:

They’re reverse engineering human-oriented interfaces.

The WhatsApp connector pretends to be a web client. It scans the QR code on your phone, gets a token, then impersonates a browser session to fetch your messages. Same trick for everything else. You can either give the agent your real phone number and email (terrifying, maximal context) or a dedicated burner identity (safer, less context). Krentsel went with the burner.

Gateway controller is where the magic lives. Its job is routing and bookkeeping. The key abstraction here is the session — and the analogy he hammers on is the operating system:

Each session has its own separate context. It enforces isolations and its own separate permissions. You should map this idea of a session to something like a process. Inside of each session, you can spawn multiple agents. You should think about these as threads.

So: sessions are processes, agents are threads, and there are tools for inter-session communication the way Unix has IPC.

Agent runtime is the bottom layer. Constructs the context, calls the model, executes tools. If you peeked inside the box you’d just see a stream of API calls to Anthropic or OpenAI. All the cleverness is in what gets stuffed into those calls.

Configuration as plain markdown

This is where it starts feeling like a vibe rather than a framework. OpenClaw’s identity lives in four markdown files: user.md, soul.md, agents.md, tools.md. The first time you launch it, none of these exist. It runs bootstrap.md, which says, in plain English:

You just woke up. Time to figure out who you are. Don’t interrogate. Just start with something like, “Who am I and who are you?”

When Krentsel ran his, the agent asked who he was. He told it to go look him up online. It did. Pulled his publications, his lab affiliation, the fact that he plays violin and has a music degree. Wrote it all into user.md itself.

The soul.md file is the strange one. It’s the agent’s self-description — preferences, personality, “core truths.” It opens with “You’re not a chatbot. You’re becoming someone.” Krentsel finds this embarrassing on first read but defends its function:

Otherwise, its preferences or behaviors can be really governed by whatever thing it’s working on. If it’s really working on mathy things, it might act more like the text the model has seen around math. Maybe it’s working on a humanities thing, it might have a different set of values. This grounds the values of the thing you’re working with, gives it some consistency.

Personality as a stabilizer against context drift. The file ends with “this file is yours to evolve.” The agent updates its own soul over time.

Time: heartbeat plus cron

This is the part Krentsel calls the magic sauce. Most agents are reactive — you ping, they respond, they sleep. OpenClaw has two ways to act on its own.

A heartbeat session fires every thirty minutes. It runs whatever’s in heartbeat.md plus the history of past heartbeats. The agent uses this to schedule self-check-ins: “every time I wake up, see if that experiment is still running, see if the email I was waiting for arrived.” If it finds something wrong, it can ping another session to fix it.

A cron tool lets the agent schedule things at specific times. You ask it for a 9am paper digest? It writes a task description, spins up a dedicated session, schedules a cron job for 8:55, and that job downloads, summarizes, and emails. Predictable work goes through cron. Unpredictable work goes through heartbeat. Together, they give the agent a sense of time.

These two things together give Open Claw a sense of liveliness that is very human-like, very autonomous, because it can handle both scheduled things and unscheduled things.

The bridge here: think of cron like a calendar reminder for the agent, and heartbeat like a habit of checking in on yourself every half hour. One is for known appointments. The other is for “wait, did I leave the stove on?”

Tools versus skills

These are different things and the talk takes pains to keep them apart.

Tools are actual code the agent can call. The built-in set is unsurprising: read, write, edit, grep, find, process management, web search, browser automation, image generation, the cron tool, inter-session messaging. There’s also a generated set of LSP tools — language server protocol — which give the agent IDE-style smarts: go-to-definition, find-references, autocomplete. So the agent navigates code the way you navigate code in VS Code.

OpenClaw also supports MCP tools, the user-installable kind. Krentsel’s blunt about how that’s playing out:

I find myself not using these at all. Six to eight months ago people were saying MCP was everything, but I think rather people are finding that agents have gotten really good at using command line interfaces.

The agents got good enough at the shell that the elaborate MCP layer became less necessary.

Skills are not code. They’re markdown files describing how to do something. The format is an Anthropic-originated open standard. A skill has a header (name and description — that’s all that gets loaded into context up front), a body (the actual recipe, loaded only if the agent decides the skill is relevant), and optional linked files (loaded only if the body says they’re needed).

This three-tier loading is the trick. You can have hundreds of skills installed, but at any moment only the headers (~150 of them, ~30k characters) sit in context. The agent looks at headers, decides what’s relevant, pulls the body, and only fetches deeper assets if it actually starts the task.

For most users, skills are by far the easiest and most effective option for improving and personalizing your agent. So all this hype around MCP servers, adding more tools, really I think skills seem to be winning out.

Two reasons: skills are remarkably effective, and they’re trivially easy to write — just plain English instructions. No code. No server to deploy.

The actual prompt

Krentsel pulls the master prompt template out of the codebase. It’s almost embarrassingly minimal: “You’re a personal assistant. Your tools are X. You can spawn sub-agents. Don’t narrate tool use. Try to act safely. Here are your skill headers.” Plus working directory, plus heartbeat info. That’s basically it.

That is the extent of security that’s built into Open Claw. It’s not a particularly secure system.

One detail he flags: memory isn’t fetched up front. The prompt just tells the agent “if you might benefit from memory, call the memory search tool yourself.” Optional. Self-directed. The agent decides when to remember.

Self-extension

Most of the components have plug-in interfaces. New connectors, new providers, new tools, new skills. The community has filled in a lot of these. But the interesting move is that OpenClaw can extend itself. It can write skills, install skills, add new providers. Krentsel set up his Discord connector by asking the agent to do it. The agent wrote its own plugin, configured it, tested it.

This is where Hofstadter sneaks in. The agent is the interface for reconfiguring itself. Loop wraps around to itself. Strange loop.

The case studies

Three demos, ordered by how impressive each one is.

One: he asked his agent (named Ludwig) to build a website explaining attention. It did. Interactive softmax visualizations, key/query/value diagrams, the whole thing. The point isn’t the website — Claude Code could’ve done that a year ago. The point is that there was no further involvement. The agent provisioned a fresh VM through the CLI, deployed the site to a public port, and just sent him the URL. End-to-end intent-to-deployment with one prompt.

Two: research reproduction. He fed it one of his own papers, told it to try a machine-learning-based variant. The agent wrote the pipeline, ran the training remotely, babysat it, debugged, and produced a Google Doc with graphs and analysis.

Three, and the wildest one: he gave Ludwig a Google account and told it to make an educational YouTube channel. Ludwig discovered Manim (3Blue1Brown’s math animation library), wrote scripts, used OpenAI’s TTS for narration, stitched audio and animation with ffmpeg, found a skill for uploading to YouTube, and proceeded to autonomously publish 31 educational videos. Krentsel showed one to his advisor — about her own paper — and she liked the metaphor it had picked.

After his initial back-and-forth on format, Ludwig wrote itself a skill for “how to make these videos” and now just produces them on its own.

Code quality is dead

The closing observation is the one that should land hardest for anyone who’s been a working engineer for the last decade:

I want to say that code quality is dead. Looking at the code itself, it’s gross. I would get fired for writing this kind of code at Google. This would never get merged in. And I think this is a function of the new world we live in, where implementation abstractions no longer matter, but abstract design abstractions do.

The architecture is good. The code is bad. The system works because the design is good. Implementation correctness used to be load-bearing because humans had to maintain it. If the agent is the maintainer, that constraint relaxes.

The strange loop

The deeper observation: OpenClaw is mostly markdown configuring an LLM that can edit the markdown. Soul, skills, tools, providers — the agent can rewrite all of them. The next wrapping, Krentsel suspects, is malleable architecture. OpenClaw’s three layers are fixed. A future system might let the architecture itself self-evolve. He doesn’t claim to know what that looks like.

On security and ambiguity, his bet is the same: smart enough models will solve both.

A smarter assistant would notice that that’s a ridiculous scenario and it’s probably trying to be tricked. It seems like that line of progression is what’s winning out. It doesn’t feel like people are trying to provide formal security models for these systems.

Key Takeaways

Two requirements drive everything: closed-loop autonomy plus open-ended generality. The architecture falls out of those two.
Sessions are processes, agents are threads. Borrowed straight from operating systems. Use the analogy when reasoning about isolation, IPC, sandboxing.
Time is the missing dimension. Cron handles known appointments. Heartbeat handles “check in on yourself every 30 min.” Together they make an agent feel alive.
Skills beat MCP for most users. Headers in context, bodies on demand, linked files only when needed. Three-tier lazy loading is the pattern.
Configuration is markdown the agent writes itself. user.md, soul.md, bootstrap.md. The agent boots up with no identity and figures out who it is.
Soul files prevent context drift. A consistent personality file stops the agent from drifting toward whatever domain it’s currently working in.
Memory is opt-in for the agent itself. Don’t pre-load memories. Hand the agent memory-search and memory-get tools and let it decide when to use them.
CLIs beat MCP servers in practice. Modern agents are good enough at the shell that the elaborate tool layer became unnecessary.
Plug-in interfaces at every layer. Connectors, providers, tools, skills, memory. Community fills these in. The agent itself can install plugins.
Implementation quality is no longer load-bearing. Design abstractions are. Ugly code with clean architecture beats pretty code with confused architecture.
The agent is the interface for reconfiguring the agent. Strange loop. This is the seed of self-improvement.
For deployment, use a small cloud VM, not a Mac Mini. Krentsel recommends exc.dev — $20/mo for up to 50 persistent VMs with Tailscale-like access.
Discord beats WhatsApp as a frontend. Channels per project gives the agent clean context isolation per topic. WhatsApp threads pile context.

Claude’s Take

This is one of the better architectural breakdowns I’ve seen of the current agent generation, and the reason is that Krentsel is a systems person looking at agents through systems eyes — sessions/processes, threads, IPC, cron, heartbeat. That framing is a much better lens than the LangChain-era “graph of nodes” or the more recent “model + tools” formulation. It explains why Claude Code and OpenClaw feel different from CrewAI without having to invoke vibes.

The two observations that stuck for me. First, the heartbeat-plus-cron split. Once you see it, you can’t unsee it. Most “AI assistants” are reactive — they wait for a prompt. The thing that makes an agent feel like a colleague rather than a tool is that it has its own relationship with time. Cron for the scheduled stuff, heartbeat for the unscheduled. You can apply this directly to any background-agent setup — it’s the same shape as the macro-research launchd job plus a check-in loop.

Second, “code quality is dead” overstates the case but points at something real. What he means more precisely: the value of defensive engineering — the kind that protects future humans from current humans — drops as the maintainer becomes an LLM that doesn’t get tired, doesn’t forget context, and can rewrite at zero cost. The architecture still has to be coherent, because architecture constrains what the agent can reason about. But the line-by-line craftsmanship that consumed so much of the last twenty years of programming is mostly bookkeeping the agent doesn’t need.

Where I’d push back: he’s a little credulous about the security story. “Reasoning will solve it” is the kind of thing people said about adversarial robustness in computer vision in 2018, and it didn’t, and we got robust models eventually but not the way the optimists predicted. The “phishing emails work on humans too” framing is true but doesn’t engage with the actual asymmetry — agents are scalable in a way that human employees aren’t. One bad skill silently installed across thousands of agents is a much bigger blast radius than one phished employee.

Also worth noting: OpenClaw is real, just not as widely known as it became after this talk. Krentsel’s frame — that we’re in “phase three” — is a useful organizing idea even if you don’t buy the specific phases. The “next doll” question (what wraps around the current generation?) is the one to keep an eye on. His guess is malleable architecture. That seems right. The architecture-as-fixed assumption is the one that hasn’t been challenged yet.

Score: 9/10. Rare combination of taxonomic clarity, hands-on detail, and willingness to make sharp claims. The drop is for the slightly hand-wavy security take and the fact that some of this is now common knowledge among people deep in the agent space — though it remains the cleanest single explanation I’ve seen.