OpenClaw went viral. Engineers sharing setups, people building workflows on top of it, the community growing fast. I watched it for a while — then set it up for myself.

Daily brief in the morning. Tech, AI, and market trends. Engineering tasks on the side. It started working almost immediately, which made me want to push it further. A lot of things I want to build.

The more I used it, the more I wanted to understand what was actually happening inside. So I went deep. What I found changed how I think about what I can build — and how I work every single day.

There’s a project called claw0 — an open-source study guide that teaches you how to build an AI agent gateway from scratch. Ten sections, one new concept each. The README says: “After all 10, you can read OpenClaw’s production codebase with confidence.”

That’s exactly what I wanted. Not to re-build OpenClaw. Just to understand why it’s designed the way it is — so when something happens, I know what’s actually going on.

What I found: there’s no magic here.

Three Things That Changed How I Think

The surprise wasn’t complexity — it was familiarity. The patterns inside an AI agent gateway are ones you’d recognize from any well-designed backend. What changes is what they manage: LLM context instead of database rows.

Three of them stuck with me.

The loop is simpler than you think.

Every agent, no matter how many features, runs this at its core:

  messages[]
      │
      ▼
 Claude API
      │
  stop_reason?
     /       \
end_turn   tool_use
   │           │
Respond    run tool
               │
        append result
               │
          messages[] ──► (loop again)

That’s it. Everything else — reliability, features, routing — is just layered on top.

Context is always appended. Never replaced.

Every message — user, assistant, tool result — gets appended to messages[]. The API receives the full conversation history on every call.

turn 1  │ [user]        "analyze this dataset"
        │ [assistant]   "I'll run the query"
        │ [tool_use]    query("SELECT ...")
        │ [tool_result] "col1: 42, col2: ..."
        │ [assistant]   "Here's what I found..."
        ▼
turn 2  │ [user]        "now summarize it"
        │ [assistant]   (has full context above)
        ▼
turn N  │ ...context keeps growing

Context growing is the point — the more history the agent has, the better it understands what you’re working on. But it comes with tradeoffs: Claude’s context window has a limit, and every token costs money. Which is why Context Guard exists — it compresses history before it hits the limit.

Knowing this changed how I think about session design. When to keep the context, when to start fresh, when to summarize — it’s not random anymore.

Everything shares the same memory.

This one surprised me the most.

Background agents run while you’re away — monitoring, processing, doing their work. When you open a chat session hours later, it already knows what happened. Both read from and write to the same memory store.

        ┌─────────────────────┐
        │     memory store    │
        └────────┬────────────┘
                 │
       ┌─────────┴──────────┐
       │                    │
  ┌────▼────┐          ┌────▼────┐
  │  cron   │          │  chat   │
  │  jobs   │          │ session │
  └────┬────┘          └────┬────┘
       │                    │
  enriches memory       reads memory
  (while you're away)   (when you talk)

The longer OpenClaw runs, the more context it builds. Background agents keep enriching it. Every session reads from it. The two reinforce each other — and over time, the system just gets better at knowing what you’re working on.

I Wrote Everything Down

I wanted to be able to come back to this. So I turned my notes into a proper series — ten chapters, one concern each.

 1. Agent Loop      → for + stop_reason
 2. Tool Use        → schema + handler map
 3. Sessions        → JSONL + Context Guard
 4. Channels        → Channel interface
 5. Routing         → binding table + priority
 6. Intelligence    → 8-layer prompt + recall
 7. Autonomy        → heartbeat + cron
 8. Delivery        → write-ahead queue
 9. Resilience      → 3-layer retry
10. Concurrency     → named lanes + future

The series is at /learn/ai-agent-gateway. My study notes from claw0, made public — if you want to go deeper on any of these.

This Is Just the Beginning

Understanding how it works changed how I use it — and what I think I can do with it.

The things I want to build feel achievable in a way they didn’t before. Not because the tools changed. Because I understand what I’m building on.

There’s a lot I’m excited to learn — and even more I want to build.

Curious what a virtual engineering team actually looks like? Next: PM, Architect, Software Engineer, QA, DevOps — each one an agent, all running on OpenClaw.