Share:
I spent the last week and a half moving between three cities with one question in my bag: how do we run agents better in the real world?
Not "can we build an agent" — that question is settled, and the answer is that anyone with a weekend and an API key can build one. I mean the unglamorous operational version of the question. What happens to an agent's memory when the process dies mid-write? Who decides what an agent is allowed to delete? Where do its credentials live at 3am when no human is at the keyboard? What wakes it up when the world changes?
I run a team of AI agents doing real software development every day, so these aren't thought experiments for me. They're my Tuesday. And after Las Vegas, Berkeley, and finally ClawCon Seattle this week, I came home with a conviction I've been circling for months:
The interesting question is no longer whether we can build another agent loop. The leverage is in making the shared runtime better.
For me, that runtime is OpenClaw. This is the story of how three very different rooms — an enterprise AI mega-conference, a hacker summer camp, a university full of harness-builders, and finally a lobster-themed meetup at Amazon's Seattle campus — all pointed at the same short list of hard problems: memory, skills, permissions, credentials, eventing, execution boundaries, and recovery.
Las Vegas: security is not a bolt-on
Vegas was two conferences wearing one city. Ai4 was the market — twelve thousand people, enterprise adoption, governance booths as far as the eye could see. Down the Strip, Black Hat and DEF CON were running the same week, and I wrote already about how instructive that contrast was as a matter of community. What I didn't write about was what the security crowd did to my thinking about agents.
Spend a day around people whose entire profession is breaking assumptions and you start seeing your own infrastructure differently. The DEF CON mindset is simple: every capability you give a system will eventually be exercised in the way you least intended. Agents are capabilities with a planning loop attached. If an agent can read your email, assume something will one day convince it to read the wrong email out loud. If it can spend money, assume something will try to redirect where that money goes.
Between sessions I had conversations with builders from Stripe, 1Password, and a handful of other companies whose products sit exactly where agents meet the real world — money and secrets. Different companies, same underlying theme: everyone can feel agents arriving at their front door, and everyone serious knows the answer is not "trust the model more." It's better boundaries.
The Vegas takeaway, compressed: if agents are going to act continuously, security cannot be bolted on later. It has to live in the runtime — in what the agent is structurally able to do — not in the prompt, and not in a hope.
Berkeley: why I'm not building another harness
Berkeley was a different species of room. At the Agentic AI Summit earlier this summer and in conversations since, I keep meeting extremely capable builders who have rolled their own agent stack end to end: their own loop, their own memory, their own tool layer, their own scheduler. The conversations are excellent. The engineering is often genuinely impressive.
And I keep leaving with the same conclusion: unless your runtime model is fundamentally different, there is very little reason to rebuild the framework. A custom harness means you now own a memory subsystem, a permissions story, a credential story, a crash-recovery story — forever, with a team of one. I'd rather spend that effort operating agents hard on a runtime thousands of people are hardening, and contribute the sharp edges back.
The conversation that shaped this trip most, though, was a personal one. I got to talk with Peter Steinberger — OpenClaw's creator — about memory, the part of the stack I care about most, because it's where my own agent team feels the most friction. I won't put words in his mouth from a hallway conversation. But the practical effect of his advice was: don't ask me, read the repo. Go look at what's actually landing on
main.So I did. More on that in a minute, because it turned out to be the best homework assignment of the summer.
Seattle: the lobster tank
ClawCon Seattle 2026 happened this Tuesday, August 11, at Amazon's downtown campus, co-hosted by AWS and AuthZed. I flew up early enough to do the obligatory Pike Place walk — fish throwing remains an underrated demonstration of low-latency distributed coordination — and then spent the day in a room full of people who run agents the way I do: continuously, for real work, with all the scars that implies.
Day one at ClawCon Seattle 2026 — that's me in front of the welcome screen at the Amazon campus venue. Co-hosted by AWS and AuthZed. Photo: Lance Ennen.
The venue: Amazon's downtown Seattle campus. A fitting host for a conversation about running agents in production. Photo: Lance Ennen.
The energy was closer to the DEF CON end of my week than the Ai4 end — laptops open, people comparing gateway configs in the hallway, lobster cookies at the back of the room. But the content is why I'm writing this.
The slide I photographed
Patrick Erichsen — Member of Technical Staff at the OpenClaw Foundation, and someone whose name you'll find all over the repo — gave the talk I'd flown up for: what the project shipped this summer. One slide did the organizing work for the whole day, and I photographed it because I knew it would organize this post too.
The slide that became my table of contents: iOS & Android apps, Skill Workshop, Control UI Pages/Widgets, Workboard, Goals, Event-Triggered Automations, and Buzz support. From Patrick Erichsen's ClawCon Seattle talk. Photo: Lance Ennen.
Seven items: iOS & Android Apps. Skill Workshop. Control UI Pages/Widgets. Workboard. Goals. Event-Triggered Automations. Buzz Support.
When I got back to my hotel I did what Peter told me to do in Berkeley: I read
main. Every item on that slide traces to real, reviewable work — though not always one feature to one PR; several are families of changes that landed over months. What follows is my read of the code and the release history, filtered through the question I brought on the trip.Memory is the center of gravity
If you only look at one part of OpenClaw this year, look at the memory work. It's almost all Peter, it spans the summer, and read in sequence it's not a feature list — it's an architecture being corrected in public.
The sequence, as I read it:
First, identity. #117334 moved transcripts to SQLite-backed identities. That sounds like plumbing until you've operated agents for a year: everything memory does — indexing, recall, consolidation — is only as trustworthy as its notion of which conversation is which. One canonical, durable identity for every transcript is the foundation everything else sits on.
Second, one engine. #120936 removed the QMD backend entirely; the builtin engine is now the only memory engine. Deleting an entire backend is one of the most underrated moves in infrastructure. Two retrieval paths means two sets of bugs, two performance profiles, and endless "which one are you on?" support threads. One recommended path means the whole community hardens the same code.
Third, crash safety. OpenClaw's background consolidation process — Dreaming, in the project's vocabulary — got a lifecycle overhaul. #115986 taught the system to adopt and reconcile legacy Dreaming cron jobs instead of orphaning them. #117885 cleans up Dreaming sessions that were interrupted when the Gateway restarts, instead of leaving zombies. And #122343 makes Dreaming publish its artifacts atomically — no more torn writes if the process dies at the wrong moment. Anyone who has run long-lived agents knows exactly which incidents motivate commits like these. They're the difference between a demo and a system.
Fourth, continuity as a default. #110597 made cross-conversation recall the default for personal installs. Your agent now remembers you across sessions out of the box — while shared and multi-user deployments keep more conservative defaults, which is exactly the right split. Recall also got a dedicated fast path (#108043), because memory that's too slow to consult is memory that doesn't exist.
Fifth, the on-ramp and the surface. Onboarding now detects and offers to import your existing Claude Code, Codex, and Hermes memories (#108977) — an acknowledgment that people arrive at OpenClaw with years of accumulated agent context, and that history has gravity. And memory finally got a first-class settings page (#114037): a product surface, not hidden plumbing. When something gets a settings page, the project is telling you it expects normal humans to reason about it.
Put the sequence together and the direction is unmistakable:
OpenClaw memory is moving toward one canonical transcript identity, one recommended retrieval path, and increasingly crash-safe lifecycle semantics.
That's not a feature. That's a maturity curve — and it's the one I'd prioritize too, because memory is where agent trust is won or lost. An agent that forgets is annoying. An agent that half-remembers because a background job died mid-write is worse than useless.
Skill Workshop and the approval gate
The item on the slide I'd been most skeptical about going in was Skill Workshop, because "the agent improves its own skills" is a sentence that should raise every hair on a security-minded neck. The actual design is better than the elevator pitch.
Skill Workshop is a proposal/review boundary. When an agent notices it keeps doing the same kind of work, it doesn't rewrite its own skill files — it drafts a proposal instead of writing directly to
SKILL.md. The proposals land in a queue you inspect, evaluate, and apply from the CLI. The docs put the constraint in one line: you review and approve before anything changes.That gate is the whole point. Self-modifying agent behavior is genuinely powerful — repeated work should become reusable capability — and genuinely dangerous if the modification loop closes without a human in it. A system that learns from its own history needs exactly this shape: the agent proposes, the operator disposes. The follow-up work in the repo pushes further down this road — reviewer-controlled self-improvement, skill repair, reconciling learned skills, scanning history for skill-shaped patterns — and all of it keeps the review boundary intact. After a week that started at Black Hat, I notice when a project gets this right.
The rest of the slide, briefly
Goals. #100468 keeps an agent's active goals in per-turn context. Small change, big operational meaning: goals stop being a stale artifact of whatever prompt started the session and become a runtime continuity primitive — the agent is re-anchored to what it's supposed to be doing on every single turn. Anyone whose agent has wandered off-task four hours into a session understands why this matters.
Workboard. Workboard began life as an optional plugin (#85367) and has grown into a genuine dispatch surface: kanban-style cards for work items, running state on each card, and follow-up work on dispatch and concurrency. It's the answer to a question every multi-agent operator eventually asks: where do I look to see what my agents are actually doing?
Control UI Pages/Widgets. Bounded interactive pages and widgets, tools and resources exposed through plugins, pinnable dashboards. Individually these are small. Collectively they're a tell: OpenClaw is growing operator control surfaces — the kind of durable, glanceable UI you build when agents run for weeks, not minutes. This is a chat loop becoming a control plane.
Event-Triggered Automations. The progression here is from cron to causation: durable automation sources, hooks, heartbeat-to-task conversion, dynamic cadence, automation controls from mobile, and event-driven wakeups scoped to the specific agent or session that should care. The principle underneath is one I'd tattoo on every agent framework: the world should wake the agent when state changes — not only when a human opens a chat window.
iOS & Android. The easy summary is "mobile apps shipped," and it undersells what's there. These are command-and-control surfaces: manage your agents, drive automations, and behave sanely offline, with voice-wake companion usage and multi-gateway support in the mix. The phone isn't where agents run; it's where their operator lives. Treating mobile as an operator console rather than a chat skin is the correct architectural read of what agents need.
Buzz support. #113419 — primary author: Patrick Erichsen, the same person presenting the slide — added
@openclaw/buzz, a full channel plugin for the Buzz protocol: authenticated room discovery, room-to-agent bindings, threaded inbound and outbound messaging, profile and presence handling, reconnect containment so a flapping connection doesn't cascade, roster-based authorization, and a dedicated Nostr bot identity for the agent. The details matter less than the pattern: every new channel an agent speaks is a new identity, authorization, and containment problem, and this implementation treats it that way.When the answer is simply "no"
AuthZed co-hosted, and Sam Kim — a software engineer there — gave the talk that connected directly to my Vegas notes. AuthZed builds SpiceDB, an open-source authorization system inspired by Google's Zanzibar model — the relationship-based permissions architecture that decides, at Google scale, who can touch what.
The demo I keep replaying, from my own notes of the day: an agent decides a file looks like a temp file and tries to delete it. The deletion doesn't fail because the model reconsidered, or because a prompt said "please be careful." It fails because an external authorization layer checked the relationship graph and said no — nothing grants you delete on that resource. The model's intent and the system's authority are two different layers, and the second one doesn't negotiate.
That separation is the entire game. Least privilege for agents can't live in the prompt, because the prompt is exactly the thing an attacker — or the model's own confusion — gets to influence. It has to live outside the loop, in policy that holds even when the model is wrong about what it's looking at.
It also sharpened an idea I've been carrying around, and I'll flag clearly that this is my idea, not something OpenClaw ships: run agents under their own OS users, and install a restrictive policy layer at the admin level — so the agent's account structurally cannot exceed its intended authority, even if the model one day decides to try. Between SpiceDB-style relationship checks above and OS-level boundaries below, "the agent decided to" stops being a scary sentence.
An agent bought a flight
The AWS side of the co-hosting brought Peter Jiang, an AgentCore engineer, and a demo that would have sounded like science fiction two years ago and got knowing nods this week: agentic payments. An OpenClaw skill connects the agent to payment services; in the demonstration, the agent paid with USDC from a wallet flow — the x402 line of agent-payment work — and bought a flight. (That description is from my notes in the room; treat the specifics as one attendee's account.)
Here's what I want to say carefully, because the crypto framing buries the lede. The interesting thing is not that an agent can move money. It's what letting an agent move money forces you to solve:
Payments are a forcing function. To let an agent spend, you must solve identity, authority, spend limits, auditability, and credentials — the exact problems every serious agent deployment has anyway.
Who is this agent? (Identity.) What is it allowed to buy, and up to how much? (Authority, limits.) Can I reconstruct every decision that led to the charge? (Audit.) What secret did it use, and could that secret do anything else? (Credentials.) Get those five right for payments and you've gotten them right for everything. That's why I pay attention to this work even though my agents don't buy flights: the payment people are being forced to build the general-purpose trust infrastructure first.
The Gateway question
One more thread from the day, and I want to label it precisely. In conversation, another Foundation-community participant — not Patrick, and I didn't confirm the attribution well enough to name anyone — described work to separate the harness from the Gateway as part of making OpenClaw enterprise-ready.
I can't verify that a complete split has shipped, and I'm not claiming it has. What I can say is that the public record is consistent with the direction: external Gateway supervision, cloud workers and remote execution, session placement and dispatch, paired-node execution, MCP and session isolation. The architectural inference is straightforward:
The component that receives, routes, schedules, and supervises work does not have to be the same component that executes every agent turn.
Every serious runtime eventually makes this separation — control plane and data plane, supervisor and worker. If OpenClaw completes it, the enterprise conversation changes: execution can be placed where the data and compliance boundaries demand, while supervision stays where the operator lives. Watch this space; I certainly am.
The password manager problem
Now the section where my Vegas conversations and my own operational pain collide.
Password managers are built around an assumption so deep it's almost invisible: a human is present. Unlock with a fingerprint. Confirm on your phone. Re-authenticate after idle. Every one of those design decisions is correct for humans and catastrophic for unattended agents. My agents work while I sleep. If a desktop vault client locks or closes at 2am, the agent doesn't feel friction — it hits a wall, and work stops until a human shows up.
The tempting fix is to make the agent better at pretending to be me — drive the UI, type the master password, click the confirmation. That is the wrong architecture, full stop. It doesn't just fail operationally; it dissolves the security boundary the vault exists to provide, by putting the crown jewels in the hands of the most manipulable component in the system.
The right patterns are duller and better, and my 1Password-adjacent conversations in Vegas were aligned on the direction: give each agent its own credentials, scoped to the minimum it needs. Use service identities where the platform offers them. Prefer short-lived tokens that expire on their own over long-lived secrets that must be revoked. Resolve secrets at tool-invocation time — the moment of use — instead of parking them in the agent's context. And never, under any circumstances, expose an entire personal vault to a model. An agent should hold the key to one door for five minutes, not the master ring forever.
Credentials for non-human actors is about to be one of the defining infrastructure problems of this era. Nobody has fully solved it. The vendors know it, the agent frameworks know it, and the gap between "what my agents need at 3am" and "what today's tools assume" is where a lot of the next two years of security engineering will happen.
The Foundation and the people in the room
A word about the institution behind all of this, because it's part of why I'm comfortable betting on the runtime. OpenClaw is now stewarded by the OpenClaw Foundation, a U.S. 501(c)(3) whose stated job is to keep the project MIT-licensed, open, and independent — "the Switzerland of AI," in the announcement's words. There's a full-time engineering team, and Foundation-convened councils are already running on agent identity, agent profiles, evals, and enterprise deployment. Peter, in the announcement's own phrasing, "keeps making the calls, especially the technical ones."
The Foundation's mission slide: "Bringing people closer to AI." A lobster claw and a very familiar hand. Photo: Lance Ennen.
I'll add a personal observation, offered as exactly that: Peter is remarkably accessible for someone running a project this size. A hallway conversation in Berkeley turned into the best technical reading list of my summer. That accessibility shows up in the project's culture too — Patrick's closing slide was a contribution pitch, and the framing made the room laugh and then actually consider it.
"Welcome to the lobster tank" — thousands of contributors, and an open invitation to become one. Photo: Lance Ennen.
Community, in cookie form. They were gone within the hour. Photo: Lance Ennen.
What I'm changing when I get home
I want to be honest about what this trip was, because it's the core of how I operate: I travel to find the people who can make me change my mind or improve how we run our agents. Most conversations validate what we've already learned by operating them hard. Every so often, one person or one commit changes the way I think about the system. This trip delivered several of both.
Concretely, here's what changes in how I run my own agent team:
Memory hygiene, immediately. I'm auditing our memory setup against the new architecture — canonical transcript identities, the builtin engine, the crash-safe Dreaming lifecycle — and importing the historical agent memory we have scattered across older tools, now that onboarding supports it. Continuity is a feature you configure, not a vibe.
An external permissions layer. The AuthZed demo settled it: model intent and system authority get separated this quarter. Agents move to their own OS users with restrictive policy at the admin level, and I'm prototyping relationship-based authorization for the resources they touch most. The prompt stops being a security boundary because it never was one.
Credential re-scoping. Every long-lived secret in an agent's reach gets replaced with the narrowest, shortest-lived equivalent I can construct, resolved at invocation time. No agent sees a vault. This is the least fun item on the list and probably the most important.
Event-driven operation. Less polling, fewer cron hacks, more of the world waking the right agent at the right moment through durable automations and scoped wakeups. My agents should be idle by default and precise when triggered.
And skills through the gate. Repeated work becomes proposed skills; proposed skills go through review; nothing self-modifies silently. The Workshop pattern is how capability should accumulate.
Vegas taught me that the adversary is patient. Berkeley taught me that building another harness is a distraction from operating the one we share. Seattle showed me a runtime growing, in public and under an independent foundation, exactly the organs that production agents need: durable memory, gated self-improvement, external authority, real credentials, and recovery that survives a restart.
That's what OpenClaw is becoming. Not a better chat loop — an operating environment for agents that work. The leverage is in making it better, and the lobster tank is open.
Technical references
The verified anchors behind this post, for readers who want the primary sources:
- Memory: #108043 (recall fast mode), #108977 (memory imports), #110597 (cross-conversation recall default), #114037 (Memory settings page), #115986 (adopt legacy Dreaming crons), #117334 (SQLite transcript identities), #117885 (Dreaming restart cleanup), #120936 (QMD removal), #122343 (atomic Dreaming artifacts)
- Features: #100468 (Goals in per-turn context), #85367 (Workboard plugin), #113419 (Buzz channel plugin), Skill Workshop docs
- Context: OpenClaw Foundation announcement, SpiceDB, ClawCon Seattle event page
This essay is firsthand reflection and opinion from ClawCon Seattle 2026 and the conference run that preceded it. All photos are my own, including the banner — that's me at the AWS venue. Demo descriptions and hallway conversations are labeled as my recollections where they aren't backed by a public source; repository claims were verified against GitHub before publication. Names of private conversations are omitted by design. See the editorial policy for how this site distinguishes reporting from opinion.
Written by
Lance Ennen
CTO & Technical Advisor helping startups and Fortune 100 companies build innovative digital products. Passionate about blockchain, AI, and scalable architecture.
Enjoyed this article? Share it with others