A new piece from The Agent Stack — posted today and currently sitting at 4 points on Hacker News — does something that most OpenClaw write-ups skip: it explains why the architecture is designed the way it is, not just what the parts are. Part 1 covers the control plane, session model, and the event loop that makes an agent feel "alive." It is worth reading in full, but here is a distillation of the key ideas.
One Central Control Plane
The Gateway is not just a proxy. It is the source of truth for all session state, all client connections, and all event routing. Whether a message arrives from a WhatsApp DM, a Discord group, a webhook, or a cron timer — it flows into the Gateway first.
The article puts it cleanly: "All session state is owned by the Gateway. UI clients should query the Gateway rather than reading local session files directly."
This single-writer design is what allows OpenClaw to support multiple surfaces (CLI, web UI, desktop app, iOS/Android nodes) without coordination hell. Clients do not compete over session files; they make requests to a single authority.
The Session Model and Secure DM Mode
Sessions are not just conversation threads — they are the isolation unit. OpenClaw maps each source (DM, group, channel, thread) to a session key, and uses those keys to ensure context does not leak across users or contexts.
The article highlights a configuration detail that many new users miss: secure DM mode. By default, OpenClaw may share the same session context across DMs from different people for continuity. In a multi-user household or a shared-access setup, that leaks context. Secure DM mode isolates sessions per sender/channel/account.
Session transcripts live on disk as JSONL files at ~/.openclaw/agents/<name>/sessions/<id>.jsonl. That is durable across restarts, but it also means those files contain sensitive content and should be treated accordingly.
The Lane-Aware FIFO Queue
Here is the part that trips up most first-timers: OpenClaw feels concurrent, but it enforces sequential writes per session. If a Slack DM, a heartbeat, and a webhook all arrive within seconds of each other, they do not race. They queue.
The queue is lane-aware — multiple sessions can run in parallel (up to configured caps), but within a single session, only one run is active at a time. This prevents the class of bugs where concurrent agent runs corrupt shared tool state or produce contradictory replies.
The queue also supports three modes:
- collect (default): coalesces multiple rapid messages into one follow-up turn
- followup: always waits for the current run to complete before starting the next
- steer: injects input into the current run at tool boundaries, enabling mid-task redirection
Why Agents Feel "Alive"
The article addresses the most common question people ask about OpenClaw: why does it seem to do things on its own?
The answer is mundane but important. OpenClaw does not run a continuous reasoning loop. It runs a normal agent turn — load context, call model, execute tools, persist, reply — whenever an input event arrives. The reason it feels proactive is that it responds to more kinds of inputs than just your messages:
- Heartbeats (default: every 30 minutes)
- Cron schedules (configured via YAML or the cron plugin)
- Webhooks (inbound HTTP triggers from external services)
- Hooks (internal event triggers from the workspace)
When your agent "decided" to do something at 3 AM, one of those four things created an event. The agent ran a turn. That is all.
The Agent Turn Loop
Once the Gateway routes an event to the right session, the agent runtime executes a compact loop:
- Load context (session history + workspace memory)
- Call the LLM
- Execute tool calls (browser, filesystem, shell, nodes, plugins)
- Persist state updates
- Respond — or stay silent if nothing warrants a reply
Continuity works by re-injecting state into this loop, not by changing model weights. The workspace is the agent's long-term memory. What is on disk is what the agent knows. That framing makes the system auditable: if an agent is behaving unexpectedly, you can read the session transcript and the workspace files to understand exactly what it knew and what it decided.
Security Implications
The article does not shy away from the security dimension. OpenClaw's combination of capabilities — untrusted text from many channels, local file access, web browsing, shell execution, skill installation — creates real risk surface:
- Prompt injection via web pages, documents, or emails the agent reads
- Skill supply-chain risk (a malicious skill on ClawHub is runnable code)
- Credential exposure (tokens and API keys live in the workspace)
The practical hardening checklist recommended in the piece aligns with what the OpenClaw team has published in their own security docs: require a Gateway token for non-local access, enable secure DM mode for shared deployments, treat skills as untrusted code and review before installing, and run OpenClaw on a dedicated machine rather than your primary laptop.
The Bigger Picture
The article's closing observation is worth quoting directly: "When people ask whether agents are 'alive,' they're asking the wrong question. The real question is: what events wake them? What state do they own? What invariants do they enforce? What tools can they execute?"
OpenClaw answers those questions with a legible architecture. That is the actual source of its power — not magic, not emergent behavior, but a disciplined event-driven system that developers can reason about, audit, and extend.
Part 2 of the series from The Agent Stack is expected to cover the plugin system and tool execution model. It is worth bookmarking theagentstack.substack.com if you want the follow-up.
Source: OpenClaw Architecture – Part 1: Control Plane, Sessions, and the Event Loop by 0xchamin, via Hacker News.