OpenClaw hit 200,000 GitHub stars in 84 days. Most people using it have no idea how it works.

OpenClaw is the fastest-growing software repo in history. People are running autonomous agents on old gaming PCs, posting viral TikToks, managing their entire inbox, and controlling smart homes. All through a text message to their agent on Telegram.

Andrej Karpathy just bought a new Mac mini specifically to tinker with claws over the weekend. He said the Apple Store told him they are selling like hotcakes and "everyone is confused." The biggest names in AI are spending their weekends setting these things up at home.

But most people using OpenClaw have no idea how it actually works.

That is fine if all you want is to install it and go. But if you want to build with this stuff, or even just understand what happens under the hood when your agent reads your email and drafts a reply, you need to see the architecture. Not as a dense spec sheet, but as a story.

This is the first in a five-part series where we build an AI agent from scratch, conceptually, one piece at a time. Along the way, we look at six real open-source repos that each take a different approach to implementing the same core ideas, from 500 lines of TypeScript to over 400,000.

Think of it like looking at six different cars. They all have engines, wheels, and steering. But one is a go-kart, one is a Tesla, and one is an armored truck. Same DNA, wildly different tradeoffs.

Let us start with the atom.

Step 1: The atom. An LLM that can do things

Every AI agent in the world, no matter how complex, starts with exactly one thing: a language model that can call tools.

That is it. An LLM receives a message, decides it needs to do something (not just reply), and makes a "tool call." Essentially: "hey, run this bash command" or "read this file" or "search the web for this." The tool runs, returns a result, and the LLM uses that result to figure out what to do next.

Before tool calling existed, LLMs were fancy autocomplete machines. They could talk about doing things but could not actually do them. Tool calling changed everything. It turned a chatbot into an agent.

The Claude Agent SDK, which powers several of the repos we will look at in this series, makes this straightforward. You give it one instruction ("Fix the bug in auth.py") and the SDK handles the rest. Claude reads the file, figures out what is wrong, edits the code, and runs the tests. The SDK manages the loop (reason, act, observe, repeat) until the task is done. You do not build the loop yourself. Claude does.

This is the atom. Everything else is built on top of it.

Step 2: Adding ears and a mouth. The messaging layer

An LLM that can call tools is powerful, but it is useless if the only way to talk to it is through a terminal. You need to give it ears (to hear your messages) and a mouth (to respond) through the platforms you already use.

This is where channels come in.

A channel is an adapter that connects your agent to a messaging platform: Telegram, WhatsApp, Discord, Slack, whatever. It translates platform-specific messages into a standard format the agent understands, and translates the agent's responses back into platform-specific output.

Between the channel and the agent, most of these repos insert a message bus, a simple queue that decouples incoming messages from the agent's processing. This matters because you do not want a slow LLM response to block new messages from coming in.

The message flow is simple:

1. Your Telegram message hits the channel adapter
2. It gets standardized and dropped on the message bus
3. The agent picks it up, reasons about it, calls tools if needed
4. It drops a response on the bus
5. The channel adapter sends it back to Telegram

Every "claw" repo implements this pattern. The difference is how many channels they support and how they manage routing. OpenClaw supports 11+ built-in channels. Nanobot supports Telegram, Discord, WhatsApp, Slack, and five more. NanoClaw is intentionally opinionated: WhatsApp only.

Step 3: The agent loop

The agent loop is what separates a chatbot from an agent. It is the core reasoning cycle that runs every time the agent gets a message:

1. Receive a message from the bus
2. Reason about what to do (this is the LLM call)
3. Act on the decision (call a tool, run a command)
4. Observe the result
5. Decide: am I done, or do I need to loop again?
6. Respond when finished

Without this loop, you just have a one-shot Q&A bot. With it, the agent can chain together multi-step tasks: read a file, find a bug, fix it, run tests, check if they pass, and report back.

Different repos handle this loop differently. Nanobot implements it explicitly in loop.py with a hard cap of 20 iterations (safety against runaway loops). NanoClaw delegates it entirely to Anthropic's Claude Agent SDK, which manages the loop internally. OpenClaw wraps it inside a Gateway orchestrator that coordinates multiple concurrent loops across different sessions.

The loop is also where safety matters most. If your agent gets stuck in an infinite loop (maybe a prompt injection told it to keep running shell commands) the iteration cap is the difference between "minor annoyance" and "unexpected $500 API bill."

Three layers, one chassis

These three pieces, tool calling, the messaging layer, and the agent loop, are the foundation of every AI agent in the "claw" ecosystem.

But a car with just a chassis and an engine is not very useful on its own. You need memory so the agent remembers who you are between sessions. You need skills so the agent can learn new capabilities without rewriting code. You need security so the agent does not accidentally expose your private data.

In the next post, we add memory and skills to our conceptual agent and see how they transform a bare-bones loop into something you would actually use daily. We look at how simple markdown files (SOUL.md, MEMORY.md, USER.md) give an agent persistent knowledge, personality, and boundaries. And we see how the skill system lets you extend your agent's capabilities by writing plain-language instructions instead of code.

The atom is simple. What you build on top of it is where things get interesting.

What this means for education

At ibl.ai, we have spent years building AI mentoring agents that operate within institutional environments. The patterns described here, tool calling, message routing, agent loops, are the same patterns that power our mentorAI platform. The difference is context.

A personal claw agent manages your inbox and posts TikToks. An institutional AI mentor navigates degree audits, surfaces relevant learning resources, and adapts its guidance to each student's academic history. Same architecture, different application.

These foundations matter whether you are building a personal agent on your Mac mini or deploying AI-powered mentoring across a university. The patterns are the same. The tradeoffs are what change.