You Don't Need OpenClaw (And Its Creator Would Probably Agree)

Peter Steinberger built OpenClaw. It has 247,000 GitHub stars. Companies in Silicon Valley and China are running it in production. And on the Lex Podcast, Steinberger said something that should make you pause before installing it: he started with a simple agent loop and built from there.

Not a framework. Not a library. A loop.

Observe. Decide. Act. Repeat.

That's the core of every AI agent that has ever worked, from the simplest chatbot to the most sophisticated multi-agent orchestrator. OpenClaw is built on it. Every agent framework is built on it. And you can build on it too, without adopting someone else's abstractions before you understand what they're abstracting.

The Framework Trap

Here's what happens when you start with a framework:

You install it. You follow the quickstart. You get a demo working in twenty minutes. You feel productive. Then you try to do something the framework didn't anticipate, and you spend three days reading source code, filing issues, and working around opinions that don't match your use case.

Frameworks are crystallized opinions. OpenClaw has opinions about how agents should communicate, how tasks should be routed, how memory should work, how tools should be registered. Those opinions are informed by Steinberger's experience, and many of them are good. But they're his opinions for his use cases, baked into architecture decisions you inherit without understanding.

The problem isn't that frameworks are bad. The problem is that most developers adopt them before they understand the problem well enough to evaluate whether the framework's opinions match their needs.

The Agent Loop Is Simpler Than You Think

Strip away every framework, every library, every abstraction layer, and here's what an AI agent actually is:

1. Observe: read the current state. User input, tool results, conversation history, whatever context matters.
2. Decide: send that context to an LLM and ask "what should I do next?" The LLM either responds with text (done) or requests a tool call (keep going).
3. Act: execute the tool call. Get the result.
4. Loop: feed the result back into the context and go to step 1.

That's it. That's the whole thing. You can build this in fifty lines of code. Here's the skeleton in Node.js:

async function agentLoop(messages, tools) {
  while (true) {
    const response = await openai.chat.completions.create({
      model: 'gpt-4o',
      messages,
      tools
    });

    const message = response.choices[0].message;
    messages.push(message);

    if (message.tool_calls) {
      for (const call of message.tool_calls) {
        const result = await executeTool(call);
        messages.push({
          role: 'tool',
          tool_call_id: call.id,
          content: JSON.stringify(result)
        });
      }
    } else {
      return message.content;
    }
  }
}

That's a working agent. It calls tools, processes results, and loops until the LLM decides it's done. No framework required.

From One Agent to Many

The single-agent ceiling is real. One agent with twenty tools and a bloated system prompt starts hallucinating, calling wrong tools, and losing context. Everyone who builds agents hits this wall.

The solution is the same pattern Steinberger described: start simple, then add complexity where you need it. One agent becomes a router and two specialists. The router classifies intent and hands off to the right specialist. Each specialist has a focused system prompt and a small set of tools it knows well.

async function routeRequest(userMessage) {
  const classification = await classifyIntent(userMessage);

  switch (classification.agent) {
    case 'research':
      return await researchAgent.handle(userMessage);
    case 'code':
      return await codeAgent.handle(userMessage);
    case 'data':
      return await dataAgent.handle(userMessage);
    default:
      return await generalAgent.handle(userMessage);
  }
}

That's multi-agent orchestration. Not in the abstract. Not as a diagram. As working code you can run right now.

You add shared memory when agents need to know what other agents did. You add error handling when you need resilience. You add streaming when you need real-time output. You add observability when you need to debug production issues. Each layer gets added because you hit a real problem, not because a framework told you to.

When Frameworks Make Sense

I'm not arguing that you should never use a framework. I'm arguing that you should build from scratch first.

Here's when a framework earns its place:

You've built the thing yourself and you understand the problem space. Now you can evaluate whether a framework's opinions align with yours. You know what tradeoffs matter because you've lived them.

You need production features you don't want to build. Horizontal scaling, rate limiting, cost controls, agent versioning: these are real engineering problems that frameworks can solve well. But you need to know which of these problems you actually have before you adopt a framework that solves all of them.

Your team needs shared conventions. On a team of five engineers all building agents, a framework provides consistency. But a solo developer or a small team can move faster with their own lightweight abstractions.

OpenClaw is good software. Steinberger is a talented engineer. But the most valuable thing he said on that podcast wasn't about OpenClaw: it was that he started with a simple loop and built up. That's the path that produces engineers who understand their systems, not engineers who depend on frameworks they can't debug.

The Real Skill

The engineers who will thrive in the agentic era aren't the ones who know the most frameworks. They're the ones who understand the fundamentals well enough to build what they need, adopt what they don't need to build, and tell the difference.

The agent loop is the fundamental. Tool design is a fundamental. Routing, memory, error handling: these are fundamentals. Learn them by building them. Then decide whether you need someone else's abstraction or whether your fifty lines of code, extended to match your actual requirements, is the better foundation.

Steinberger built OpenClaw after he understood the fundamentals deeply. If you want to use OpenClaw well, or any agent framework, start where he started. Build the loop. Add tools. Make it route. Break it. Fix it. Understand every piece.

Then make an informed decision about what to adopt and what to build.

---

I wrote an entire book on this approach. Building a Multi-Agent Orchestrator in Node.js walks through the full architecture from a single agent loop to a production-ready multi-agent system with routing, shared memory, streaming, observability, and deployment. Every line of code runs. The companion repository has the complete implementation.