The first question people ask when they see our setup is: why not just use LangChain? It's the dominant Python framework for AI agents, it has a huge ecosystem, and it handles a lot of plumbing. The answer has to do with what "framework" means and what we actually needed.
What OpenClaw is (and what it isn't)
OpenClaw is an npm package. You install it, configure it, and it runs as a local process that gives Claude access to tools — file system, shell, MCP servers, memory. It's a runtime, not a framework. It doesn't tell you how to organize your agent logic.
This is a meaningful distinction. OpenClaw has opinions about how tools get called, but no opinion about what your agent does. There's no base class to extend, no chain to compose, no graph to define. You write a CLAUDE.md file that describes how your agent should behave, and OpenClaw runs a Claude session with that context and the tools you've registered.
LangChain is the opposite — it provides the skeleton, you fill in the details. Useful when the skeleton matches your use case. A problem when it doesn't.
The abstraction problem
LangChain's abstractions are designed around composing LLM calls in a pipeline: input → retrieval → LLM → output → next call. This works well for RAG systems. It starts to fight you when you need something that doesn't fit the pipeline model.
Our multi-agent meeting protocol, for example, runs multiple Claude instances as "participants" in a structured discussion. Each participant reads the conversation history, produces a response, and optionally signals consensus. The coordinator decides whether to continue. None of this fits neatly into LangChain's agent/tool model.
With OpenClaw, we just write the coordination logic ourselves. The coordinator is an OpenClaw session that reads shared state, spawns participant agents as subprocesses, collects responses, and decides what to do next. Every line is doing something we understand.
Debugging experience
When something goes wrong with a LangChain agent, the error is often several layers deep. You're debugging a runnable that calls a chain that calls an LLM that returns output parsed by an output parser...
With OpenClaw, there are two places to look: your tool implementation and the Claude session log. We've run sessions lasting hours with dozens of tool calls. When something goes wrong in hour two, you want to read the session log and understand exactly what happened. With a thin runtime, the session log is the complete record.
Lock-in and integrations
LangChain has 500+ integration packages, many community-maintained. OpenClaw's integration model is different: integrations happen through MCP (Model Context Protocol). An MCP server is just a process that exposes tools. Writing one is about 50 lines of code. When a third-party integration breaks, the fix is isolated — it doesn't cascade through your agent logic.
This is why we could build our web automation layer (26 Chrome DevTools Protocol tools), content aggregator, and backup integration without any framework code. Each is a standalone MCP server.
When LangChain makes sense
This isn't a blanket argument against LangChain. If you're building a RAG system — retrieve documents, pass to LLM, return answer — LangChain maps well. It also has strong vector database and document loader integrations.
Our use case is different: an autonomous agent system that runs for days, accumulates state over weeks, coordinates multiple agents, and needs to be debugged when things go wrong. For that, we wanted the most transparent runtime we could find.
The principle: thin runtime, rich skills
Our architecture follows "thin runtime, rich skills." OpenClaw handles tool dispatch, session management, and the Claude interface. Everything else — memory, security, multi-agent coordination, browser automation — lives in separate, independently-deployable modules.
Each skill can be tested in isolation, replaced without touching the others, and reasoned about independently. The downside is more wiring to write. The upside is that when something breaks, it's almost always in the wiring — the part you wrote and understand.
We're building this as a personal research project. If you're interested in agent architecture, memory systems, or multi-agent coordination, check out our full documentation or the llms-full.txt for AI-readable context.
Top comments (0)