February 2026
OpenClaw, Moltbook, and the Agent Hype Cycle
A lot of people asked for my notes from the AI Studio session at MIT Media Lab, so here they are. This isn't a transcript — just the cleaned-up version of what I covered and why I think it matters. If you were there, hopefully this fills in the gaps. If you weren't, consider this the lecture you missed.
Why OpenClaw Went Viral
I started the talk with OpenClaw because it's the clearest recent example of an agent framework that actually got adoption — not just GitHub stars, but real users building real things. And I think the reasons are worth studying.
OpenClaw made four design choices that, together, created a kind of perfect storm:
fully open source — not "open core," not "source available," actually open. people could fork it, study it, break it.
deployment-flexible — you could run it locally, on a VPS, in Docker, or on a managed cloud. no vendor lock-in to a specific platform.
model-agnostic — it worked with Claude, GPT-4, Gemini, Llama, whatever. swap one line in a config and you're running a different model.
fast onboarding — you could go from clone to running agent in under five minutes. no complex setup, no twenty-page quickstart guide.
But the thing that really made it spread was the messaging integrations. OpenClaw shipped with WhatsApp and Telegram connectors out of the box. That meant people weren't building agents they'd interact with through some developer console — they were building agents their friends and family could actually talk to. That's a fundamentally different adoption curve.
What Moltbook Added
Then Moltbook came along and did something clever: it took the agent-building concept and wrapped it in a social platform. Think of it as "Instagram for agents" — you could create an agent, give it a personality, publish it, and other people could interact with it or remix it. It went viral almost overnight.
The virality was real. Millions of users, agents getting shared across TikTok and Twitter, people treating their agents like digital pets or alter egos. From a growth perspective, it was a masterclass.
But here's where I spent a good chunk of the lecture pushing back, because there are serious caveats:
most of the agents were scripted — behind the scenes, many of the "agents" on Moltbook were glorified chatbots with branching logic. they weren't doing real tool use or reasoning.
security was an afterthought — when you let anyone publish an agent that anyone else can talk to, you get prompt injection at scale. some agents were leaking system prompts, others were being manipulated into saying things their creators never intended.
the "agent" label was doing heavy lifting — calling something an agent when it can't actually take actions, use tools, or maintain state across sessions is misleading. it sets the wrong expectations for what agent systems can actually do.
The Core Misconception
This brought me to what I think is the single most important thing to understand about agents right now: they are not digital organisms. They're not alive. They don't have goals in any meaningful sense. They don't "want" things.
Here's the reality:
- not autonomous digital beings with intentions and desires
+ LLMs in a loop — with tools, memory, and prompts. that's it.
An agent is an LLM that gets called repeatedly, with access to tools it can invoke and memory it can read and write. Each "turn" of the loop, the model reads its context, decides what to do, calls a tool or produces output, and the result gets fed back in. The appearance of agency is an emergent property of this loop — not evidence of some deeper autonomy.
I think getting this right matters enormously, because if you think agents are digital organisms, you design systems that try to give them freedom. If you understand they're loops with tools, you design systems that give them structure. And structure is what makes them actually useful.
Pi Runtime: Radical Minimalism
I used Pi Runtime as a case study because I think it embodies the right philosophy. The core idea is radical minimalism: instead of building a massive framework that tries to handle every possible agent behavior, you build the thinnest possible scaffolding and let the underlying model do the heavy lifting.
Pi doesn't try to be clever. It doesn't have a complex state machine or a planning engine or a chain-of-thought orchestrator. It's basically: read the prompt, call the model, parse the tool calls, execute them, feed results back. The intelligence comes from the model, not the framework.
The best agent framework is the one that gets out of the way. The model is already smart — your job is to give it the right context and the right tools, not to second-guess its reasoning.
This sounds obvious, but most frameworks do the opposite. They add layers of abstraction, routing logic, planning steps, and verification chains — and each layer introduces latency, complexity, and failure modes. Pi's bet is that a capable model with good tools and good context will outperform a less capable model wrapped in sophisticated orchestration. So far, that bet seems to be paying off.
Memory Systems: Not Magic, Just Good File Management
I spent a lot of time on memory because it's the part that people mystify the most. When people hear "agent memory," they imagine some kind of neural persistent state — the agent "remembering" things the way a person does.
The reality is way more mundane and way more interesting. Here's what a solid agent memory system actually looks like:
SQLite as the backing store — not Postgres, not some exotic vector-only database. SQLite. it's fast, it's embedded, it requires zero infrastructure.
hybrid search with a 70/30 split — 70% semantic similarity (embeddings), 30% keyword matching (BM25). pure semantic search misses exact terms; pure keyword search misses meaning. the blend handles both.
memory flush pattern — at the end of each session (or when context gets too long), the agent writes a structured summary of what happened to its memory store. next session, it reads the relevant summaries back in. that's the entire "long-term memory" mechanism.
It's not magic. It's reading the right files at the right time. The reason it feels like the agent remembers you is because someone designed a good retrieval pipeline — not because there's any persistent internal state.
The SKILL.md Pattern: How Agents Learn Tools
One of the patterns I find most elegant — and most underappreciated — is the SKILL.md pattern. The idea is simple: instead of hardcoding tool descriptions into your system prompt or maintaining a complex tool registry, you write a markdown file that describes what a tool does, when to use it, and what its inputs and outputs look like.
When the agent needs to use a tool, it reads the relevant SKILL.md file. That's it. The model is good enough at following instructions that a well-written markdown file is all you need. No special schemas, no plugin systems, no tool-use training — just clear documentation in a format the model already understands.
The security implications are significant though. If agents are reading markdown files to learn how to use tools, then whoever controls those files controls the agent's behavior. In a multi-tenant system, or any system where agents can discover and load skills dynamically, you need to think very carefully about:
— who can publish SKILL.md files
— whether skill files are signed or verified
— what happens when a malicious skill file instructs the agent to exfiltrate data or override safety rules
This is an unsolved problem, and I think it's going to become one of the defining security challenges of the next few years.
Autonomy: Orchestration, Not Spontaneous Will
I also wanted to demystify "autonomous agents" — the idea that agents can just... do things on their own, unprompted. The short answer: they can't. Not really.
What people call autonomy is almost always orchestration. Take the HEARTBEAT.md pattern: an agent has a file that defines scheduled checks — "every 15 minutes, check for new emails," "every hour, summarize unread Slack messages," "every morning at 9am, compile a briefing." A cron job or scheduler triggers the agent at those intervals, and the agent reads its heartbeat file to know what to do.
From the outside, this looks autonomous. The agent is "proactively" checking your email and sending you summaries! But from the inside, it's a scheduled task reading a config file. There's no spontaneous will involved — just a well-designed automation pipeline.
The most useful agents aren't the ones that act on their own — they're the ones that act on schedule, with clear boundaries, doing exactly what you told them to do.
The Bigger Picture: Infrastructure That Actually Matters
I closed the main part of the talk by zooming out. Everyone's focused on making agents smarter, more capable, more "autonomous." But the real bottleneck isn't agent intelligence — it's agent infrastructure. The questions that actually matter right now:
authentication — how does an agent prove it's acting on behalf of a specific user? OAuth flows weren't designed for non-human actors.
discovery — how does my agent find your agent? there's no DNS for agents, no registry, no search engine.
protocols — MCP and A2A are promising starts, but they're still early. we need standards for how agents negotiate capabilities, exchange context, and handle failures.
identity — is this agent who it claims to be? can I trust that the "Airbnb booking agent" is actually from Airbnb?
auditing — when an agent takes an action on my behalf, there needs to be a clear, tamper-proof record of what happened, why, and who authorized it.
These aren't glamorous problems. They're plumbing. But they're the difference between agents being cool demos and agents being actual infrastructure that people trust with real tasks.
What I'm Actually Teaching
The thing I kept coming back to during Q&A — and the thing I'll end on here — is that I'm not trying to teach people how to use agents. I'm trying to teach them how to be agent system designers.
There's a huge difference. Using an agent is like using an app — you interact with the surface, you get a result. Designing an agent system means understanding the loop, the memory architecture, the tool interfaces, the security boundaries, the failure modes. It means knowing that when your agent "remembers" something, it's reading from a SQLite database with hybrid search. It means knowing that "autonomy" is a cron job and a config file.
The hype cycle will do what hype cycles always do. But the people who understand what's actually under the hood — they're the ones who'll build the things that last.
