OpenClaw as an AI agent

OpenClaw is called an AI agent because of what happens between a message and a reply. The docs describe it as a serialized, per-session run: intake, context assembly, model inference, tool execution, streaming and persistence, with the tool step being the part a chatbot does not have. Around the loop sit a Gateway that owns every messaging surface, nodes that lend devices, sub-agents that run in the background, and schedules that start runs on their own. Here is the loop as the architecture pages describe it, what is assembled before the model speaks, the pieces around it, and the hooks that let you change its behaviour.

The agent loop is the serialized, per-session run that turns a message into actions and a reply: intake, context assembly, model inference, tool execution, streaming, persistence.

The loop

• An agent request validates its parameters, resolves the session, persists the session metadata and returns a run id immediately; a separate wait call blocks until the run’s lifecycle ends.
• The run resolves the model and its thinking defaults, loads the skills snapshot, builds the session, subscribes to runtime events, streams assistant and tool deltas, and enforces the run timeout.
• Runs are serialized per session key, and optionally through a global lane, so tool and session races cannot happen; a durable writer claim fences every transcript write, and a superseded run cannot commit stale data.

What is assembled before the model speaks

The workspace is resolved and created, and a sandboxed run may be redirected to a sandbox root. Skills are loaded, or reused from a snapshot, and injected into the environment and the prompt. Bootstrap context files go into the system prompt, which is built from OpenClaw’s base prompt, the skills prompt, the bootstrap context and per-run overrides, with the model’s limits and the compaction reserve enforced. Messaging channels choose a queue mode that feeds the session lane, which is why a second message during a run steers or follows rather than colliding.

Around the loop

• The Gateway: one long-lived process that owns all messaging surfaces and exposes a typed WebSocket API, with the macOS app, the CLI, the web UI and automations connecting as clients.
• Nodes: macOS, iOS, Android and headless hosts connect over the same WebSocket with the node role and expose commands such as camera, screen and location; pairing is device-based.
• Sub-agents and schedules: background runs spawned from a run, and cron or heartbeat runs, all go through the same loop and the same policy.

The OpenClaw Gateway explained explains the process that owns the channels, OpenClaw nodes and remote hands what a paired device lends, and OpenClaw sub-agents the background runs.

Hooks, and the boundary

Two hook systems live in the process: internal scripts on command and lifecycle events, and typed plugin hooks inside the loop, before the model is resolved, before the prompt is built, before the reply, after the run, around tool calls, and around compaction as observers. Webhooks are separate: they accept external requests that trigger work rather than subscribing to loop events. The boundary is the same one the security pages draw: the tool step is what makes this an agent, and tool policy, OpenClaw skills explained that describe rather than execute, and the guidance in OpenClaw and prompt injection are what keep an agent that reads the open web from being steered by it.

On Diali

On Diali the loop is the same code the docs describe; what changes is who runs the Gateway around it and who is awake when a scheduled run fails. What is OpenClaw is the plain-language introduction, and Hosted OpenClaw on Diali is the assistant.

• Intake, context, inference, tools, streaming, persistence, one session at a time.
• Gateway, nodes, sub-agents and schedules all feed the same loop.
• Hooks change the loop; policy and sandboxing bound it.