Lab Notes

OpenClaw Framework Overview

Introduction to OpenClaw — the experimental agent runtime providing the mission model, execution loop, and artifact lifecycle used throughout the lab.

Purpose

This note introduces OpenClaw, the experimental framework layer used to build and run agents in this lab. Rather than describing individual agents in isolation, this page covers the shared runtime model that gives those agents structure: how objectives become missions, how missions drive execution, and how results become artifacts.

Status: Experimental (actively developed alongside the lab agents)

Why OpenClaw exists

Building agents that perform meaningful web research or software work requires coordinating several things at once: a clear objective, a plan, access to tools and browser environments, accumulation of state, structured outputs, and a way to evaluate whether progress is being made. Without a shared runtime model, each agent becomes a bespoke script — hard to reason about, hard to extend, and hard to compare across experiments.

OpenClaw exists to provide that shared model. It defines how an agent receives an objective, how it turns that objective into a plan, how it interacts with its environment, and how it produces auditable outputs. The goal is not a general-purpose agent framework for all possible tasks, but a focused runtime shaped around the specific constraints of web-oriented and research-oriented agents.

Core idea

OpenClaw is built around a single organizing concept: the mission. A mission is a bounded unit of agent work with a defined objective, a set of constraints, and a success condition. Everything the agent does is in service of completing that mission.

Within a mission, the agent operates in an iterative loop: plan a step, act on the environment, observe results, update state, produce artifacts, evaluate progress, and repeat. This loop runs until a terminal condition is reached — the objective is fulfilled, the agent decides it cannot continue, or an evaluation step triggers a halt.

The framework's role is to manage this loop — providing the scaffolding for planning, tool dispatch, browser interaction, state persistence, artifact writing, and evaluation — so that agent experiments can focus on objectives and strategy rather than infrastructure.

Main abstractions

Mission

A Mission is the top-level unit of work. It carries an objective — a natural language description of what is to be accomplished — alongside constraints (scope limits, step budgets, allowed tools) and success criteria (conditions under which the mission is considered complete). The mission is the contract between the user and the agent runtime.

Agent

An Agent is the execution unit assigned to a mission. It holds references to the runtime, the current mission, and the active memory state. The agent does not contain domain logic directly; it operates through the planning loop and delegates to tools and the browser environment. The same agent structure is reused across different mission types.

Runtime

The Runtime is the execution host. It initializes the environment (browser session, memory store, artifact directory, logging), manages the planning loop, and handles lifecycle events — initialization, each step, artifact flush, and final evaluation. Agents are not instantiated directly; the runtime owns the lifecycle.

Planner / Reasoning Loop

The Planner is the decision component. Given the current mission objective and accumulated memory state, it produces the next action: a tool call, a browser navigation, a structured query, or a halt decision. The planner does not maintain its own state; it operates on what the runtime surfaces, which allows the reasoning strategy to be swapped independently of the infrastructure.

Tool Layer

The Tool Layer exposes callable operations to the agent: web search, content extraction, file operations, structured data queries, and external API calls. Each tool has a defined input schema, a call interface, and a typed result. The planner selects tools; the runtime dispatches them and returns results to the agent's memory.

Browser / Web Environment

For web-oriented agents, the browser environment provides access to live pages: navigation, DOM interaction, screenshot capture, and content extraction. The agent interacts with it through structured actions rather than raw scripting. The browser session is scoped to the mission and torn down on completion or failure.

State and Memory

Memory is the agent's working context: accumulated observations, partial results, and reasoning decisions made over the course of a mission. State is distinct from artifact outputs — it is the agent's internal working material during execution, not the final deliverable. Memory is scoped to a mission run and is not persisted across independent missions by default.

Artifacts

Artifacts are the structured outputs of a mission: research reports, data extracts, scraped content, decision logs, or generated files. Artifacts are written to an isolated run directory, typed by phase or purpose, and designed to be human-readable. The artifact model is what makes mission runs auditable — each phase's output can be inspected independently.

Logs and Evaluation

Each mission run produces structured logs: step-by-step records of what the agent planned, what it executed, and what it observed. Evaluation happens both within the loop — the agent assesses whether accumulated artifacts meet the mission's success criteria — and retrospectively, by reviewing the run logs and artifact directory after completion.

High-level architecture

Loading diagram…
OpenClaw high-level architecture — missions are executed through a runtime that coordinates planning, tools, web interaction, state, artifacts, and evaluation.

Agent execution lifecycle

Loading diagram…
OpenClaw agent execution lifecycle — each step updates the mission state and can produce artifacts or logs.

How this fits into the Lab

The pages in this lab describe experiments built on top of OpenClaw. Each agent note covers a specific domain — web research, code execution, information scouting, media automation — but the underlying execution model is the same. Understanding OpenClaw makes those notes easier to read: the differences between agents are primarily differences in objective domain, tool selection, and evaluation strategy, not in the fundamental execution loop.

The framework is experimental and evolves alongside the agents. Some abstractions described here reflect current implementation; others describe structure that is actively in progress. Where implementation status differs from this overview, the individual agent notes are the authoritative source.

References

→ Agentic Architecture — broader documentation for the local agent ecosystem
→ System Overview — agent roles and component topology
→ Data Flow — how requests and artifacts move through the system
→ Research Agent — web research agent built on the OpenClaw mission model
→ Research Framework — pipeline components and mission flow details