# OpenClaw Architecture: How the Gateway and Agents Work

> URL: https://www.atlantic.net/cloud-platform/how-openclaw-works/ | Published: 2026-10-09 | Author: Hitesh Jethva

Understanding OpenClaw’s architecture helps you trace a request from an incoming message to the model, tools, and final response. It also explains where conversation state lives and which parts of the system can execute actions.

OpenClaw architecture centers on a long-running Gateway, a per-session agent loop, model providers, tools, memory, skills, sessions, plugins, nodes, and external channels. The Gateway receives work, resolves the correct session, prepares execution, starts the agent runtime, routes events, and returns the result to the original interface.

The large language model (LLM) handles model inference. OpenClaw handles routing, context, session state, tool access, memory, execution policy, persistence, and delivery around each model turn.

# What Is OpenClaw?

OpenClaw is an open-source AI assistant designed to run on your own infrastructure and connect to messaging platforms, apps, devices, models, and tools. One Gateway acts as the central coordination process for these interfaces.

Its capabilities include persistent conversations, external actions, memory retrieval, reusable skills, device nodes, automations, sub-agents, and policy-controlled tool access.

This makes OpenClaw useful when your workflow extends beyond a single prompt and response. An agent might inspect files, execute commands, search stored memory, use a browser, call an external service, send a message, or delegate work to another agent session.

## How Does OpenClaw Work?

OpenClaw receives a request through the Gateway, maps the request to a session, builds the required context, then starts the agent loop against the configured model. If the model requests an action, OpenClaw applies the relevant tool and execution policies, runs the permitted operation, and returns its result to the model.

The model may produce a response directly or continue through several tool calls. OpenClaw records state as the run progresses and delivers the final response through the original channel.

## OpenClaw Architecture At A Glance

OpenClaw uses a layered architecture that separates communication, context, inference, actions, and persistent state.

Interfaces such as WebChat, the command-line interface (CLI), Slack, Telegram, native apps, and automations provide entry points. Requests move through the Gateway and session/context layer before reaching the agent runtime.

Inside the runtime, the selected LLM produces a response or requests a tool available to the session. Tool results return to the model-and-tool loop until the task finishes or the run stops.

## OpenClaw Architecture Components

Each major component has a separate responsibility in the request lifecycle.

| **Component** | **Main Responsibility** | **Role in the Workflow** |
| --- | --- | --- |
| Gateway | Routing, connections, authentication, events | Receives work and coordinates the system |
| Session | Conversation identity and runtime state | Tracks a conversation’s identity, history, and runtime state |
| Agent runtime | Model and tool loop | Runs the prepared agent turn |
| Model provider | Model access and authentication | Connects OpenClaw to the selected LLM |
| Context layer | Builds model input | Supplies history, instructions, tools, skills, and relevant state |
| Tools | External actions | Run commands, file operations, browser tasks, messaging, and other operations |
| Memory | Durable recall | Stores and retrieves information across turns |
| Skills | Reusable instructions | Teach the agent how to perform specific classes of work |
| Plugins | Runtime extensions | Add tools, providers, channels, hooks, and other capabilities |
| Nodes | Remote device capabilities | Expose device-specific commands through the Gateway |
| Sub-agents | Background or delegated work | Run separate tasks in their own sessions |

The separation matters during debugging. A failed response might come from bad context, model behavior, session routing, tool policy, memory retrieval, or external execution. Treating those areas as separate layers makes the failure easier to trace.

For example, if a message reaches the correct session but a command is denied, inspect the effective tool and execution policies before changing the model or channel configuration.

## OpenClaw Gateway Architecture

The Gateway is the central control process in OpenClaw. One long-running Gateway owns messaging surfaces, accepts client connections, exposes a typed WebSocket interface, validates requests, publishes events, and coordinates agent work. A regular host installation binds to loopback at 127.0.0.1:18789 by default, as described in the [Gateway architecture documentation](https://docs.openclaw.ai/concepts/architecture).

Control clients include the CLI, web interface, native apps, and automations. Nodes also connect to the same WebSocket service, but they identify themselves with a node role and advertise device capabilities.

A request enters the Gateway. The Gateway validates the request, identifies the session, and starts the corresponding agent run. Streaming agent events then travel back through the Gateway to the connected client.

For standard persistent Gateway sessions, the Gateway host owns the live session database. A remote client reads that state through the Gateway.

## How OpenClaw Sessions Work

A session gives each conversation an execution identity and history boundary. Session state tracks information such as the active session identifier, interaction time, settings, token counters, archived status, and related runtime metadata.

Current OpenClaw stores persistent session rows and transcript events in a [per-agent SQLite database](https://docs.openclaw.ai/reference/session-management-compaction/store). Transcript rows contain conversation events, tool calls, and compaction summaries used to rebuild future model context.

Older JSON and JSON Lines (JSONL) artifacts serve migration, archive, export, recovery, and related support roles. They are no longer the primary live transcript store for standard persistent Gateway sessions.

## OpenClaw Request Lifecycle

A single user message passes through several controlled stages before a response returns.

| **Stage** | **What Happens** |
| --- | --- |
| 1. Intake | A channel, client, automation, or remote procedure call (RPC) sends a request |
| 2. Session resolution | The Gateway resolves the session key and session identifier |
| 3. Runtime setup | OpenClaw resolves model settings, authentication, tools, and skills |
| 4. Context assembly | OpenClaw prepares instructions, history, workspace context, relevant memory, and tool definitions |
| 5. Model inference | The runtime sends the prepared turn to the selected model |
| 6. Tool execution, if needed | Permitted tool calls execute under the configured policies and return results |
| 7. Loop continuation | The model processes tool results and determines whether further work is needed |
| 8. Run completion | The runtime finalizes the result and associated usage information |
| 9. Delivery | The Gateway delivers the final response to the original surface |

This table summarizes the main stages. Session metadata and transcript events are recorded during the run, and supported interfaces can receive progress before the final reply.

OpenClaw serializes runs within each session and uses additional queues to control concurrency across the system. Separate sessions can therefore perform work in parallel without starting competing runs against the same conversation state.

## Inside The OpenClaw Agent Loop

The OpenClaw agent loop turns an incoming message into one or more model and tool interactions. The loop continues until the runtime reaches a final result, an error, cancellation, or a timeout condition.

## Context Assembly

Before model inference starts, OpenClaw prepares the context for the current turn.

The context might include:

- System instructions
- Conversation history
- Workspace files
- Skill metadata
- Tool definitions
- Memory results
- Runtime settings
- Current user input
- Previous tool results

Context belongs to the current model window. Memory and session storage remain outside the immediate model request and supply selected information when needed.

## Model Selection And Inference

OpenClaw separates model access from the rest of the agent system. The runtime resolves the configured model and authentication profile before inference begins.

This lets one OpenClaw installation work with different supported model providers while keeping Gateway routing, memory, sessions, and tools under the same broader architecture.

## Tool Execution

When the model requests a permitted tool, OpenClaw applies the configured execution controls. Tool results return to the same agent loop.

The model then processes those results and determines whether another tool call or a final response is needed. Human approval depends on the configured approval policy.

## How OpenClaw Tool Calling Works

OpenClaw tools provide the action layer between model reasoning and external systems. Tools cover areas such as command execution, files, browser access, messaging, search, media, session operations, and plugin-provided functionality.

Tool availability is filtered by the effective configuration. A tool might be restricted by:

- Tool profiles
- Explicit allow rules
- Explicit deny rules
- Sandbox configuration
- Agent settings
- Provider restrictions
- Channel permissions
- Plugin availability

The model proposes actions while OpenClaw controls which tool interfaces are available and applies the configured execution policy. Commands run through an allowed shell tool can still modify files wherever the execution environment permits.

## OpenClaw Memory Vs. Skills Vs. Sessions

Memory, skills, and sessions serve different purposes. Treating them as the same form of stored context makes OpenClaw architecture harder to understand.

| **Feature** | **Purpose** | **Stored Information** | **When Used** |
| --- | --- | --- | --- |
| Memory | Long-term recall | Facts, decisions, preferences, notes, and recalled history | When previous knowledge matters |
| Skills | Reusable operating instructions | SKILL.md instructions and metadata | When the agent needs a defined capability or workflow |
| Sessions | Conversation continuity | Messages, tool events, settings, and transcript state | Throughout a conversation |
| Context | Current model input | Selected history, instructions, tools, memory, and the current request | During one model turn |

## OpenClaw Memory

OpenClaw’s default Memory Core uses workspace files such as MEMORY.md, an optional USER.md, and dated memory notes. These hold curated facts, user preferences, and working observations. The optional DREAMS.md file records Dreaming activity for human review.

The built-in memory engine maintains an index in the agent’s SQLite database. It supports keyword search, plus vector and hybrid search when an embedding provider is available.

Current OpenClaw also supports bounded recall from other eligible private conversations for personal agents. This requires cross-conversation recall and Active Memory to be enabled, with a compatible memory provider. Recall stays within the same agent’s eligible private conversations; groups, channels, and other agents’ transcripts are excluded from this feature. It does not broaden ordinary session-tool access.

Dreaming provides a background memory consolidation path. Short-term signals pass through automated staging, scoring, and provenance checks before qualified information reaches durable memory in MEMORY.md.

## OpenClaw Skills

Skills are Markdown instruction packages built around a SKILL.md file. Each skill describes how and when an agent should perform a particular class of work or use tools. OpenClaw loads skills from several supported locations and applies precedence rules when names overlap.

Tool permissions continue to follow the configured policy when a skill is used.

## OpenClaw Sessions

Sessions preserve the active conversation identity, transcript events, and runtime metadata. A session provides continuity for one conversation. Memory provides selective recall beyond the immediate conversation, subject to the configured access and recall rules.

## How OpenClaw Context Management Works

The model receives selected information for the current run. Context assembly brings together the relevant instructions, history, tool definitions, and retrieved material.

As conversations grow, OpenClaw uses compaction to manage model-window limits. Compaction retains summaries and available token measurements in transcript history while keeping a recent portion of the conversation available for continued work.

Compaction changes the active model context. The underlying transcript remains available under the configured retention and maintenance policies.

Memory works alongside this system. Important information saved outside the immediate context remains available for later retrieval.

## Sub-Agents And Multi-Agent Work

OpenClaw supports sub-agents for background and parallel work. Each sub-agent runs in its own session and normally returns its result to the requesting agent.

Sub-agents fit tasks such as:

- Long research work
- Code review
- Testing
- Independent analysis
- Slow tool operations
- Parallel specialist work

Each sub-agent has separate context and token usage. Tool access follows the applicable agent policy plus an additional sub-agent restriction layer. Sandboxing, when configured, adds an execution boundary.

OpenClaw also supports multiple configured agents within one Gateway process. Each configured agent has its own workspace and agent state. Sub-agent runs provide a way to delegate work from an existing agent session.

## OpenClaw Security Architecture

OpenClaw’s [security model](https://docs.openclaw.ai/gateway/security) places controls around tool access and execution. Tool policy decides which tools the model can use. Sandbox settings decide where supported execution runs. Gateway authentication controls client access.

Sandboxing is disabled by default, but it can be enabled through agent configuration or required by the session creator’s operator role. When enabled, supported tool operations run inside the configured sandbox backend while the Gateway remains outside that tool sandbox. The backend can use a local container or a remote execution environment.

Workspace access also has separate modes. The default none setting provides a separate sandbox workspace without exposing the agent workspace. The ro setting exposes the agent workspace read-only, while rw permits changes, subject to additional role restrictions.

Sessions organize conversation state within the deployment’s wider access controls. A shared Gateway is intended for a trusted operator or a mutually trusting team. Strong isolation between mutually untrusted users requires separate Gateways and appropriate host-level separation.

For remote access, OpenClaw recommends a private network such as Tailscale or a virtual private network (VPN), with a Secure Shell (SSH) tunnel as an alternative. The configured Gateway authentication still applies.

## Plugins And External Services

Plugins extend OpenClaw without changing the core Gateway-and-agent-loop model. A plugin might add a channel, provider, tool, search capability, hook, media , or another runtime extension.

Native OpenClaw plugins execute inside the Gateway process as trusted code. Tool sandboxing does not sandbox the native plugin runtime.

OpenClaw reaches external services through providers, tools, plugins, channels, or node interfaces. Different deployments can enable the integrations appropriate to their workflows.

## OpenClaw Deployment Architecture

A typical OpenClaw deployment centers on the Gateway host, which runs the core runtime, workspace, persistent session state, memory, and configuration. User-facing channels connect to this host, while model providers and permitted tools handle inference and actions.

Ordinary sub-agent runs use separate sessions coordinated within the Gateway process. Browser control can run locally, and configured browser environments can be local, sandboxed, or remote. Supported tool operations can run on the host, inside a sandbox, or on a connected node, depending on policy and configuration.

Device nodes, remote sandbox backends, and external services extend the deployment when needed. Databases and custom services may be local or remote. The physical placement of each component follows the deployment configuration.

Developers who want a preconfigured cloud deployment also have hosted setup options. We offer [OpenClaw Hosting](https://www.atlantic.net/cloud-platform/openclaw-hosting-your-ai-assistant-always-on/) as a One-Click Application on Atlantic.Net Cloud. The application prepares the server and OpenClaw installation. You supply access to a supported model provider and manage the Gateway, channels, users, tools, and application configuration.

The Gateway still acts as the central control process, while models, channels, sessions, tools, and external integrations follow the same OpenClaw design.

## A Complete OpenClaw Workflow Example

Suppose you send OpenClaw a Slack request:

*Inspect this repository, identify why the test suite fails, fix the error, run the tests again, and report the change.*

With Slack connected, the repository accessible, and the required tools permitted, the workflow proceeds as follows:

1. The Slack channel delivers the request to the Gateway.
2. The Gateway identifies the target agent and session.
3. OpenClaw loads session metadata, relevant conversation history, skills, workspace context, tool definitions, and model settings.
4. The agent runtime sends the prepared turn to the model.
5. The model requests file or command tools.
6. OpenClaw applies tool and execution policies and runs permitted operations.
7. The test output returns to the agent loop.
8. The model inspects the failure and requests another action.
9. The cycle continues until the task completes or the run stops.
10. The Gateway returns the final result through Slack, with transcript and usage information recorded as the work progresses.

The same architecture supports requests from WebChat, native clients, the CLI, other messaging channels, or supported automation entry points.

## When OpenClaw Architecture Fits

OpenClaw architecture fits workflows where an AI agent needs persistent availability, multiple communication channels, durable sessions, memory, tools, device access, background work, and defined execution boundaries.

For developers, understanding these responsibilities provides a practical basis for deployment and troubleshooting. Choose where the Gateway will run, decide which actions the agent can perform, and establish whether those actions should execute on the host, in a sandbox, or on a connected system. Plan how you will maintain the application and preserve the state it needs between runs.

These decisions connect the architecture to the workflow you want to support. The Gateway provides continuity and coordination, while the configured models, tools, and execution environments determine what the agent can do. For a cloud deployment, follow our guide to [installing OpenClaw on an Atlantic.Net Cloud Server](https://www.atlantic.net/cloud-platform/how-to-install-openclaw-on-an-atlantic-net-cloud-server/).

## Frequently Asked Questions

**What Is The OpenClaw Gateway?**

The Gateway is the central long-running OpenClaw process. It owns messaging surfaces, client connections, routing, events, authentication, and coordination between sessions and agent runs.

**What Happens Before OpenClaw Calls The Model?**

The Gateway resolves routing and session state. OpenClaw then prepares runtime settings and context before the agent loop sends the prepared request to the selected model.

**Where Does OpenClaw Store Session History?**

For standard persistent Gateway sessions, OpenClaw stores session rows and transcript events in a per-agent SQLite database on the Gateway host. JSONL files serve legacy, archive, migration, recovery, export, and related support purposes.

**What Is The Difference Between OpenClaw Memory And Context?**

Context is the information supplied to the model for the current run. Memory stores durable information outside the immediate model window and retrieves relevant material when needed.

**How Do OpenClaw Skills Work?**

A skill is a Markdown-based instruction package centered on SKILL.md. Skills teach an agent how or when to perform a task or use tools, and OpenClaw loads eligible skills according to its discovery and precedence rules. Tool permissions remain subject to configuration.

**Does OpenClaw Support Multiple Agents?**

Yes. OpenClaw supports separate configured agents and sub-agent runs. Configured agents have their own workspaces and state. A sub-agent receives its own session and context, performs delegated work, and normally reports its result to the requester.

**Where Does OpenClaw Execute Tools?**

Tool execution depends on the configured policy and execution target. Supported operations can run on the Gateway host, in a configured sandbox, or on a connected node. Sandboxing is disabled by default unless enabled through configuration or required by an operator role. The Gateway remains outside the tool sandbox.

**Is OpenClaw Memory The Same As Chat History?**

Session transcripts preserve conversation events. Memory stores and indexes selected information for retrieval across later turns. Eligible personal-agent configurations can also recall material from other private conversations belonging to the same agent.