OpenClaw's Agent Gateway: Sessions, Persistent Work, and Optional Isolation

Most terminal agent harnesses begin with a person sitting in front of the process. OpenClaw starts from the opposite assumption: messages arrive from channels such as WhatsApp, Telegram, and Discord, while the agent remains available between conversations. Once that is the product boundary, routing, background work, and risk controls become part of the harness rather than optional extras.

This is the fifth article in the Agent Harness series. I reviewed OpenClaw version 2026.8.1 at upstream revision 888c8422013e. It follows Pi's deliberately small core and is followed by Hermes's durability-first loop.

The Pi-shaped loop adds preemptive steering

OpenClaw retains visible Pi ancestry: some code was adapted from Pi and its TUI still uses pi-tui. Its built-in runtime and agent-core, however, are maintained by OpenClaw. Calling the current system a direct reuse of Pi would hide the work that now belongs to OpenClaw itself.

The core loop still has nested loops for tool calls, pending messages, and post-stop follow-ups. Its notable addition is steering preemption. When a user message arrives during a batch of tool calls, tools that already began continue. Tool calls that have not started are replaced with synthetic skipped results, and the next model step sees the user's new instruction.

That makes a correction such as "wait, do not install that package" actionable during a batch without pretending that a started side effect can be undone safely.

Session keys turn messages into conversations

A terminal process has an obvious session boundary. A multi-channel gateway has to calculate one. OpenClaw makes the session key the central abstraction, deriving it from the agent, channel, chat kind, and remote peer. A representative direct-message key has this shape:

agent:<agent-id>:<channel>:direct:<peer-id>

Direct-message scope can be configured from one shared main session through increasingly specific peer, channel, and account combinations. Identity links can merge identities across channels.

The key supports the rest of the session lifecycle:

• Reset policies can be disabled, daily, or idle-based, with separate handling for direct chats, groups, and threads. The default is no automatic reset.
• A serialized lane per key prevents two runs from operating on the same conversation at once. New messages arriving during a run enter the steering or follow-up queue.
• An active writer run ID fences transcript writes across runs.

Current canonical storage is one SQLite database per agent. It combines mutable session rows with append-only, tree-shaped transcript events. Older JSON session files and hot JSONL transcripts serve migration or archival roles rather than the normal runtime read path.

The context threshold remains related to Pi's approach: compaction begins when context use exceeds the window after reserving response capacity. The agent-core reserve starts at 16,384 tokens, while OpenClaw's embedding layer raises the effective floor to 20,000 tokens when possible and keeps 20,000 recent tokens by default.

Sandboxing is optional and scoped to tool execution

OpenClaw offers docker, podman, ssh, and openshell sandbox backends, yet sandbox mode defaults to off. When enabled, it can apply to non-main sessions or all sessions. Docker is the default backend, and the default scope is one environment per agent.

This setting has an important boundary: the Gateway, native plugins, control-plane RPC, and elevated execution remain outside the sandbox. The feature reduces the blast radius of tool execution; it does not contain the entire OpenClaw product.

The Docker backend starts from a restrictive configuration, including no network access, a read-only root filesystem, and dropped Linux capabilities. Workspace access is configured separately. These defaults are meaningful, though an internal derived security="deny" state should not be read as a blanket claim that all implicit sandbox execution is denied. Explicit user configuration is what creates that hard denial.

Execution policy is a second layer. OpenClaw supports deny, allowlist, ask, auto, and full policies. An ask decision can be forwarded to the same chat surface where the user is already talking to the agent. That is a practical approval path, but it is not a substitute for selecting an appropriate sandbox boundary.

Persistent behavior is part of the product

An assistant that stays online needs a definition of useful work when nobody has sent a message. OpenClaw supplies three pieces:

• A heartbeat wakes the agent every 30 minutes by default. Its protocol permits the agent to return HEARTBEAT_OK when nothing needs attention, and an empty scratch file can avoid an API call entirely.
• Cron provides scheduled work with its own execution lane.
• File-backed memory uses MEMORY.md and memory/*.md as material for a vector index. The agent receives memory_search and memory_get, and its tool contract tells it to search before answering questions about previous work, decisions, dates, or preferences. SOUL.md, USER.md, and IDENTITY.md provide related identity context.

This is why the loop alone does not describe OpenClaw. Its persistent semantics define when it wakes, how it identifies a conversation, and what information survives a session boundary.

A gateway needs more defensive plumbing

OpenClaw also tracks whether a turn has consumed network content, detects and recovers from repeated critical tool loops, and exposes before/after hooks that can block or rewrite tool results. Schema quarantine, environment sanitization, and read-only workspace mounting fill out the same defensive posture.

The cost is real. A Gateway process and many channel integrations are more complex to reason about than a terminal harness. The architecture is optimized for a single operator connecting an agent to existing communication habits, with optional controls for the risks that come from work continuing out of view.

Source scope

The details here refer to OpenClaw 2026.8.1 at upstream revision 888c8422013e, including its agent runtime architecture, session management, sandboxing, heartbeat, and memory contracts. Continue with Hermes and its persistence-before-side-effects ordering.