OpenClaw Reasoning Loop: Context, LLM, Tools, Execute

Introduction

The agentic loop within OpenClaw: load context (memory, conversation), pass to LLM with tools list, LLM responds with text or tool call. If tool call: execute, add result to context, loop back to LLM. Repeat until final response. This "reasoning loop" enables multi-step actions — search web, read file, summarize, respond. Chatbots don't have this; agents do.

Understanding the reasoning loop is essential for debugging, optimizing, and extending OpenClaw. When the agent "gets stuck" or produces unexpected behavior, the loop is usually where the issue lies. When you want to add a new capability, you're adding a tool that the loop can invoke. The loop is the heart of the system.

The Loop

1. Load: conversation history, memory files (SOUL.md, relevant Markdown), system prompt
2. Call: LLM with context + tools
3. Parse: text response or tool_call(name, params)
4. Execute: if tool_call, run skill, get result
5. Append: result to context
6. Loop: back to step 2 until LLM produces final text

Each iteration adds to the context. The LLM sees its previous reasoning, the tool results, and the original user message. It "reasons" over this accumulated state. That's what enables multi-step tasks: the agent can plan, act, observe, and replan.

Contrast with a chatbot: one user message, one LLM call, one response. No tools. No loop. No ability to "go look something up" or "run a command." The reasoning loop is the architectural difference that makes OpenClaw an agent, not a chatbot.

Tool Calls

LLM produces structured request: execute_shell("ls -la"), search_web("openclaw 2026"). Runtime validates, executes, returns result. LLM uses result for next step. Enables: "Search for X, read the top result, summarize for me."

Tools are defined in TOOLS.md and implemented as skills. Each tool has a name, description, and parameters. The LLM receives the tool list in its system prompt and chooses when to call. The runtime enforces: only registered tools, parameter validation, sandboxing (if configured).

Example flow: User asks "What's the weather in Tokyo?" Agent has no built-in weather knowledge. It calls search_web("weather Tokyo today"). Gets results. Reads them. Calls format_response to produce a clean answer. Two tool calls, one user-facing response.

See TOOLS.md and SKILLS.md for how to define and extend tools.

Multi-Step

Complex tasks require multiple tool calls. Agent might: read file → search web → write summary → send message. Each step is a loop iteration. The agent "reasons" over accumulated context. This is what distinguishes agents from simple chatbots.

Example: "Summarize the top 3 articles about OpenClaw from the past week."

Iteration 1: Agent calls search_web("OpenClaw articles past week"). Gets URLs.

Iteration 2: Agent calls fetch_url for each URL. Gets content.

Iteration 3: Agent has the content. Calls summarize (or uses its own generation). Produces summary.

Iteration 4: Agent produces final text response. Loop terminates.

Four iterations, four tool calls, one cohesive answer. The user sees the final response. The agent did the work behind the scenes.

Multi-step also enables error recovery. If a tool fails, the agent sees the error in context. It can retry with different parameters, try an alternative tool, or explain the failure to the user. The loop supports adaptive behavior.

Context Window and Token Management

Each loop iteration adds tokens: the tool call, the result, the LLM's reasoning. Context grows. Eventually, you hit the model's context limit (e.g., 200K tokens for Claude). The runtime must manage this.

Strategies: (1) Summarize old context — compress earlier turns into a shorter summary. (2) Drop oldest messages — keep recent context, truncate history. (3) Use a sliding window — only the last N messages. OpenClaw employs a combination depending on configuration.

Implication: very long conversations or tool-heavy tasks may lose early context. The agent "forgets" the beginning of the session. For most use cases, this isn't an issue. For extended debugging or complex multi-hour tasks, be aware of the limit.

When Does the Loop Stop?

The loop stops when the LLM produces a "final" text response — one intended for the user, with no pending tool calls. The runtime detects this and returns the response to the Gateway, which delivers it to the user's messaging platform.

Guardrails: (1) Max iterations — typically 10–20. Prevents infinite loops from misbehaving models. (2) Timeout — if a single iteration takes too long, abort. (3) User interrupt — if the user sends a new message, the current loop can be cancelled. These protect against runaway agents and stuck loops.

Debugging tip: If the agent seems to loop forever, check the tool results. Is the LLM receiving usable data? Is it confused by an error message? Sometimes the fix is improving the tool's output format or error handling so the LLM can "understand" and proceed.

Wrapping Up

The reasoning loop is OpenClaw's core execution model. Load, call, parse, execute, append, loop. It's what makes OpenClaw an agent. See how it works and Gateway architecture for the full picture.