How OpenClaw Turns a Single Message into a Full Agent Execution Pipeline

OpenClaw Execution Flow

When a user sends a message, OpenClaw does not simply forward it to a large language model; it runs the message through a complete, engineered execution chain.

Five‑Layer Architecture

The system can be abstracted into five layers:

User Interface Layer

Provides CLI, Web UI, mobile app, and WebSocket API entry points and normalizes all inputs into a unified internal request model.

Gateway Core Layer

Manages connection handling, request admission, hot configuration loading, and health monitoring—essentially keeping the runtime resident and ready.

Message Processing Layer

Contains the core business logic, including the agent executor, routing system, session management, media handling, outbound delivery, and other extensions.

Extension & Plugin Layer

All pluggable extensions live here: channel adapters for DingTalk, Feishu, Telegram, WhatsApp, Slack, etc.; skill‑tool system; and sub‑agent mechanisms.

Infrastructure Layer

Provides common capabilities such as configuration & secret management, structured logging, scheduled tasks, event bus, memory retrieval, and sandbox security.

Message Ingress

External platforms send messages in different formats. Each platform has a dedicated adapter that normalizes the raw payload into a MsgContext object:

interface MsgContext {
  Body: string;
  BodyForAgent?: string;
  BodyForCommands?: string;
  RawBody?: string;
  SessionKey: string;
  Provider: string;
  Surface?: string;
  ChatType?: "direct" | "group";
  SenderId?: string;
  SenderName?: string;
  SenderUsername?: string;
  OriginatingChannel?: string;
  OriginatingTo?: string;
  AccountId?: string;
  MessageThreadId?: string;
  CommandAuthorized?: boolean;
  MessageSid?: string;
  GatewayClientScopes?: string[];
}

This unified abstraction isolates platform differences from the rest of the system.

De‑duplication & Interception

OpenClaw generates an idempotency key for each incoming message (e.g.,

{provider}|{accountId}|{sessionKey}|{peerId}|{threadId}|{messageId}

) and checks a cache to avoid processing duplicates. It also intercepts control commands such as /stop to abort running agents.

Routing System

The router decides which agent should handle the message based on binding rules that match channel, account, peer, Discord server, team, and role. Matching proceeds from most specific (exact peer) to least specific (default agent).

Session Key Generation

Once an agent is selected, a session key of the form {agentId}:{scope} (e.g., assistant:main or assistant:whatsapp:direct:+1234567890) is created to isolate the conversation and control concurrency.

Lane Mechanism

Two lane levels prevent context corruption:

Session‑level lane ensures that messages belonging to the same session are processed serially.

Global lane caps overall concurrency, queuing excess messages.

Context Assembly

Before invoking the model, OpenClaw assembles a full prompt in the order: system prompt → skill prompt → conversation history → current message. System prompts are built from bootstrap files (AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md, BOOTSTRAP.md, MEMORY.md) located in ~/.openclaw/workspace.

Memory Recall Rule (example)

## Memory Recall
Before answering anything about prior work, decisions, dates, people, preferences, or todos:
run memory_search on MEMORY.md + memory/*.md; then use memory_get to pull only needed lines.
If low confidence after search, say you checked.

The system enforces token budgets by limiting the number of historical rounds, truncating large tool results, and automatically compressing older history into summaries when the context window approaches the model limit.

Skill Loading

Skills are discovered from workspace, user global, built‑in, and plugin directories, then filtered by platform, channel, sender permissions, and whitelist/blacklist settings. A three‑layer security pipeline (profile filter, sandbox isolation, sub‑agent inheritance) determines whether a skill can be invoked.

Memory System

OpenClaw maintains two types of memory:

Long‑term memory stored in MEMORY.md files, injected into system prompts at startup.

Daily memory stored as memory/YYYY‑MM‑DD.md, accessed on demand via a memory‑search tool with time‑decay weighting.

Memory indexes reside in ~/.openclaw/memory/index.db and support file metadata, chunking, vector retrieval, full‑text search, and embedding caching. The index stays in sync via file watchers, periodic scans, and incremental updates, with a full rebuild option when needed.

Multi‑Agent Collaboration

For complex tasks, the main agent can spawn sub‑agents using the sessions_spawn tool. Sub‑agents receive a dedicated system prompt that emphasizes their limited scope and ephemerality. Results flow back to the parent agent through an internal event queue, allowing hierarchical task decomposition.

Execution Completion

After the agent finishes, OpenClaw:

Delivers the response via the appropriate outbound adapter.

Persists the session metadata in sessions.json and appends the full interaction to a JSONL transcript.

Releases lane locks, global concurrency slots, and idempotency keys.

Performs cleanup such as archiving old transcripts and rotating large files.

Key Strengths

OpenClaw distinguishes itself by providing a layered, runtime‑oriented architecture that handles de‑duplication, session isolation, context compression, error fallback, and multi‑agent orchestration—turning a single user message into a fully governed, traceable, and recoverable task pipeline.