build-your-own-openclaw: an 18-step Python path from a chat loop to an agent runtime
A step-by-step guide to build your own AI agent.
At a glance
- What is it?
- This MIT-licensed tutorial walks through 18 progressive Python steps, each with its own README and runnable codebase, from a bare chat loop to a scaled-down OpenClaw. The value is the step boundaries, not the finished agent: the later steps assume you have the earlier ones working.
- Who is it for?
- Adopt this if you want to understand agent plumbing by writing it, and you are willing to work through the steps in order rather than lifting the final directory. Skip it if you need a supported framework with versioned releases, or if you cannot supply your own LiteLLM-compatible provider credentials.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 70 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What the tutorial is actually for
Most material about AI agents arrives as a framework: you install a package, register tools through a decorator, and the interesting decisions happen inside someone else's source tree. This repository takes the opposite position. It is a sequence of 18 directories, numbered 00-chat-loop through 17-memory, where each directory holds a README explaining the design decisions for that step plus a runnable codebase. The stated goal is a minimal version of OpenClaw, and the README names pickle-bot as the reference implementation. The audience is a Python developer who wants to see where session state, tool dispatch and scheduling actually live. It is not a library. There is no package to install, no API surface to depend on, and no release history retrieved for the project. You are meant to read a step, run it, and move to the next one.
The four phases and why the ordering matters
The steps are grouped into four phases, and the grouping is the most informative part of the README. Phase 1, steps 0 to 6, builds a single capable agent: chat loop, tools, skills via SKILL.md, persistence, slash commands, compaction, web tools. Phase 2, steps 7 to 10, is a refactor rather than a feature addition. The event-driven step comes before config hot reload, channels and websocket, which means the tutorial deliberately makes you restructure working code instead of writing the event loop from scratch. That is a real design choice and it costs you rework. Phase 3, steps 11 to 15, adds multi-agent routing, a cron heartbeat, multi-layer prompts, post-message-back and agent dispatch. Phase 4 covers concurrency control and memory. The phase boundaries tell you what the author considers separable: a single agent is one problem, multi-platform delivery is another, autonomy is a third.
Mechanisms visible in the step list
Several concrete mechanisms can be read off the directory names without running anything. Step 02 extends the agent through a SKILL.md file, so skills are declarative documents rather than Python classes. Step 05 is compaction, which implies the conversation history is being summarized or truncated to fit a context window, and that this happens as an explicit step rather than as a hidden behaviour of a client library. Step 08 is config hot reload, meaning the agent reads configuration at runtime and reacts to edits without a restart. Step 12 pairs cron with a heartbeat, so scheduled work and liveness checks share a step. Step 16 is concurrency control, which only becomes a problem once step 15 has agents dispatching work to other agents. The chain is coherent: each problem is introduced by the previous solution. What the README does not give is the mechanism inside any of these steps. For that you have to open the directory.
Getting a step running
The README gives one setup path for all steps. Copy the example configuration, then edit it with your credentials. The two commands are: cp default_workspace/config.example.yaml default_workspace/config.user.yaml, followed by editing config.user.yaml. The README points at the LiteLLM providers documentation for the full list of supported providers and at PROVIDER_EXAMPLES.md in the repository for worked examples. That is the entire documented setup. Note the shape of it: the config lives in a workspace directory rather than at the repository root, and the user file is a copy of the example rather than a file you create from nothing. The README instructs you to follow each step, read it, and try it out, which means the run command for an individual step is not documented in the top-level README. You will find it in that step's own README. Treat the missing per-step invocation as a documentation gap you should check before adopting the tutorial for a team.
Where the tutorial model breaks down
The structure that makes this good for learning makes it poor for reuse. Each step is implemented in a separate session, per the contributing note, so there is no shared library and no compatibility guarantee between directories. If you copy code from step 12 into a project, you inherit whatever the author wrote for step 12 and nothing else. There are no retrieved releases, so there is no version to pin and no changelog describing what changed between revisions of a step. The tutorial is also cumulative by design: the later steps assume the earlier ones, which means a reader who only wants event-driven architecture has to either accept the prior steps or reverse-engineer the refactor from step 07 alone. And because the provider layer is LiteLLM, the tutorial's behaviour depends on a third-party abstraction whose own documentation you are told to consult. That is a reasonable choice for breadth, but it means provider-specific quirks are outside this repository's scope.
How this differs from an agent framework
The obvious alternative is to skip the tutorial and build on an existing Python agent framework, where tools, memory and scheduling are library features you configure. The difference in approach is not quality, it is where the abstraction sits. A framework hands you an agent object and hides the loop; this repository hands you the loop and hides nothing, at the cost of you maintaining it. A second alternative is to read the OpenClaw source directly, which the README links to as the thing being miniaturized. That gives you the real architecture, but it also gives you production concerns, scale and the full surface area at once. The tutorial's contribution is the intermediate: a working agent small enough to hold in your head, split at points where the design changes. If you already know how tool dispatch and session persistence work, the early steps will read as review, and the later phases are where the material becomes worth the time.
Maintenance, licence and what to verify
The licence is MIT, which permits use, modification and redistribution with the licence and copyright notice retained. This is a statement about the repository's terms, not advice about your situation, and the tutorial bundles no dependencies of its own beyond what each step imports. Maintenance cost is the part to think about carefully. Because the steps are independent sessions rather than a versioned package, there is no upgrade path: a change to a provider's API or to LiteLLM surfaces as breakage in whichever step you are running, and you fix it yourself. The repository is not archived and the last push recorded is 2026-07-08, so it is active, but activity on a tutorial is not the same as a support commitment. If you build on a later step, budget for owning that code. The first thing to verify is whether the step you need has a README that stands alone, because a step that only makes sense after reading its predecessor is a step you cannot hand to a colleague.
Editorial conclusion
Adopt this if you want to understand agent plumbing by writing it, and you are willing to work through the steps in order rather than lifting the final directory. Skip it if you need a supported framework with versioned releases, or if you cannot supply your own LiteLLM-compatible provider credentials. Before committing, open the step you actually need, check whether its README stands alone or refers back to earlier steps, and confirm that default_workspace/config.example.yaml exposes the provider keys your environment requires.
Community notes