Skip to content

Sessions-as-Processes

The core abstraction alex-krentsel pulled out of the openclaw gateway controller: sessions map to OS processes, sub-agents map to threads. This is the mental model that makes OpenClaw's middle layer coherent to a systems audience.

The mapping

Systems concept OpenClaw equivalent
Process Session — own context, own permissions, can run in a sandbox
Thread Agent (core agent + spawned sub-agents) — share session context
Process table / scheduler Gateway controller
IPC Inter-session tools (rare in practice)
init / system processes Main session (admin, UI-exposed) + heartbeat session
cron heartbeat-and-cron

Multiple threads per process. Multiple processes running in parallel. Isolation boundaries at the session level, not the agent level. "It's not that you [spawn sub-agents], it's that the framework does this for you."

Why the analogy pays off

  • Permissioning becomes legible. A session can be sandboxed; its sub-agents inherit that sandbox. Same shape as chroot or a container.
  • Concurrency becomes legible. Sessions run in parallel; the user isn't blocked by a long-running project session.
  • Communication becomes the exception, not the rule. As in OS design, inter-session channels exist but aren't the primary design point. Most coordination happens through shared memory (openclaw's memory/wiki plug-in) or via the main session.

Implication

If you buy the analogy, every OS-design lesson maps forward: scheduling policies for long-running autonomous sessions, isolation escape vectors, resource accounting per session, fairness between user-initiated and heartbeat-initiated work. This is the research handle Krentsel is pulling on from the Berkeley systems side.

Pairs with

Cross-references