The History of OpenClaw: From Clawdbot to the Framework Everyone's Using

The story of OpenClaw starts, like a lot of the best software, as a personal tool. Peter Steinberger — the engineer and entrepreneur best known for building PSPDFKit, a PDF rendering SDK used by thousands of iOS developers — had a simple problem: he wanted an AI agent that could actually do things on his computer without sending his data to a cloud service he didn't control.

What he built to solve that problem eventually became the framework that DenchClaw runs on. This is that story.

Clawdbot: The First Experiment#

The earliest form of what would become OpenClaw was called Clawdbot. It was modest in scope — essentially a persistent terminal agent that could read files, run shell commands, and maintain a conversation history. The key innovation wasn't the capabilities; it was the architecture.

Most AI tools of that era (late 2023, early 2024) were cloud-first by default. You sent your data to an API, the API sent back a response, you got your answer. This worked fine for stateless queries. It fell apart the moment you wanted an agent that had context about your actual environment — your filesystem, your running processes, your local databases.

Clawdbot ran locally. The agent's context window could include the actual output of ls -la and cat commands. It could read your config files without those files leaving your machine. For someone like Steinberger, who spent years building software that handled sensitive document data, this wasn't a nice-to-have — it was a requirement.

The name Clawdbot was replaced fairly quickly with Clawd — a cleaner moniker that dropped the "bot" suffix. "Bot" carried connotations of automation scripts and IRC chatbots. "Clawd" was more agent-like, more deliberate. Something you worked with, not something that just ran.

The Skill System: From One-Off to Framework#

The pivotal moment in Clawd's evolution was the introduction of skills.

In the early versions, extending the agent's capabilities meant modifying code. You'd write a new tool, update the agent's context about available tools, redeploy. This was fine for a solo developer, but it didn't scale. Every new capability was a development cycle.

The insight that changed everything: what if capabilities were documentation rather than code?

An LLM doesn't need an API contract. It needs instructions. Clear, unambiguous instructions in plain text, combined with the right tools available in the environment. If you write a skill that says "when asked to send an email, use the himalaya CLI with these flags," the agent can follow those instructions as reliably as any compiled plugin — and you can update the instructions without touching a line of code.

This realization turned Clawd from a personal tool into a platform. Once capabilities were documentation, anyone could write capabilities. A finance person could write a skill for their expense reporting workflow. A salesperson could write a skill for their lead qualification process. They didn't need an engineer.

The skill format that emerged — a structured SKILL.md file at the root of a skill directory, with optional references/ and scripts/ subdirectories — became the stable API for the framework. It's remained essentially unchanged because it's right. Markdown is human-readable, LLM-readable, versionable in Git, and requires no tooling to create.

The Rename to OpenClaw#

Clawd became OpenClaw when it became a framework rather than an application.

The semantic shift mattered. Clawd was something you ran. OpenClaw was something you built on. The rename signaled that the primary user was no longer just someone who wanted an agent — it was a developer who wanted to build agent-powered applications.

This is the React/Next.js analogy again. React started as a way to build UIs more efficiently. As it stabilized, it became infrastructure. OpenClaw followed the same arc: personal tool → shared tool → framework infrastructure.

The open-source release accelerated adoption. Developers who had built their own Clawd-like systems recognized the architecture immediately. The local-first model, the skill system, the session management — these weren't novel in isolation, but the combination was coherent in a way that other agent frameworks weren't. Most alternatives either required cloud infrastructure or sacrificed extensibility for simplicity.

OpenClaw threaded the needle: run locally, extend via plain text, compose via subagents.

Subagents: The Orchestration Revolution#

The subagent system deserves its own section because it was a conceptual leap, not an incremental improvement.

The insight that spawned it: a single agent with a complex context doesn't outperform multiple focused agents with clean contexts. When you ask one agent to research a competitor, analyze your internal data, and draft a proposal simultaneously, you get mediocre output from each. When you give each task to a fresh agent with a specific brief, the output quality improves dramatically.

OpenClaw's subagent architecture made this model practical. The parent session (orchestrator) could decompose a task, write clear briefs for each component, spawn isolated agents, and synthesize results. The depth limit (maximum 2 levels deep) prevented runaway recursion while enabling real parallelism.

This turned out to be the right level of complexity. Unlimited nesting would be undebuggable. Zero nesting would miss the key use case. Two levels — orchestrator and workers — maps cleanly onto how humans actually delegate: you give a clear brief to someone who executes it, not a brief to someone who gives briefs to someone who gives briefs to someone.

The orchestrator model also clarified the value proposition for building on OpenClaw. The framework didn't just give you a better chat interface — it gave you a way to structure workflows where AI was a first-class participant.

DenchClaw: The YC Bet#

By mid-2024, OpenClaw had attracted enough developer attention to be worth building a commercial product on. The question was: what kind of product?

The answer was CRM. Not because CRM is the most exciting space — it isn't, and anyone who tells you otherwise is selling something — but because CRM is where the OpenClaw architecture's advantages are most acute.

CRM data is sensitive. It should stay on your machine. CRM workflows are repetitive. They benefit from automation. CRM needs change constantly. The skill system makes them adaptable. And most importantly: CRM tools are universally mediocre in the same way, and the mediocrity has a clear cause — they're built around the vendor's needs (lock-in, upsell, data collection) rather than the user's needs.

DenchClaw went into Y Combinator's Summer 2024 batch as a bet that local-first AI CRM was the right wedge. The vision was straightforward: give people an AI workspace where their data stays local, the agent understands their business context through skills, and the whole thing runs on their machine with npx denchclaw.

The YC experience sharpened the product in the ways YC always does — faster iteration, cleaner positioning, more ruthless prioritization. The core architecture was already right. The work was execution.

What This History Means for the Future#

Software frameworks are durable when they find the right level of abstraction. React found it with components. Rails found it with convention over configuration. OpenClaw found it with the skills-and-sessions model.

The thing that makes a framework last isn't features — it's making the right set of decisions about what to decide for you and what to leave open. OpenClaw decides: agents run locally, skills are markdown, subagents are the concurrency model, DuckDB is the data layer. Everything else is yours to configure.

The local-first bet looks increasingly correct as awareness of data privacy concerns grows. The skills-as-documentation bet looks correct as the ecosystem of community-written skills expands. The orchestration model looks correct as tasks get more complex and context management becomes the binding constraint.

DenchClaw exists to take those bets and build the most useful product possible on top of them. We're not neutral about the architecture — we're all-in on it. And the setup guide is where you can see exactly what that commitment looks like in practice.

Clawdbot to OpenClaw: A Timeline#

FAQ#

Is Peter Steinberger still involved with OpenClaw? Peter Steinberger created the original Clawdbot/Clawd/OpenClaw foundation. The project has evolved through community contribution and the DenchClaw team's development. For the current maintainer structure, check the GitHub repository.

Why was DuckDB chosen as the local data layer? DuckDB offers SQL semantics without requiring a running server process. It's a single file, runs in-process, and supports complex analytical queries natively. For a local-first workspace, it's the correct choice.

Is OpenClaw related to PSPDFKit? OpenClaw and PSPDFKit are separate products. Steinberger's background informed some architectural choices (local-first, privacy-conscious), but they share no code or infrastructure.

How does DenchClaw contribute back to OpenClaw? DenchClaw's skill improvements, bug reports, and architectural patterns flow back into OpenClaw. The MIT license ensures the open-source commons remains healthy.

Where can I find OpenClaw's current documentation? The setup guide covers DenchClaw specifically. OpenClaw's docs are at the GitHub repository. ClawHub at clawhub.ai is the skills marketplace.

Ready to try DenchClaw? Install in one command: npx denchclaw. Full setup guide →