The core loop
A run, step by step
In practice, a request usually moves through the workflow like this:
Input arrives
The request is normalized and stored as the initial workflow state.
Next step is selected
The system checks the current state and decides which step should run next.
A step executes
This may call a model, call a tool, transform data, or apply business logic.
The result is validated
Outputs are checked against schema, required fields, and workflow rules.
State is updated
The workflow records what succeeded, what failed, and what remains unresolved.
The workflow branches
It either proceeds to the next step, retries, falls back, hands off, or finishes.
Example: one request moving through the workflow
Imagine a request that must summarize a quarterly report and return typed metrics such as revenue, growth rate, and operating margin.
Intake + Plan
Store the document ID, requested metrics, and output schema, then choose the first extraction step.
Execute
Generate a summary, extract key metrics into typed fields, and attach both results to the run state.
Validate + Route
Check required fields and confidence thresholds. If validation fails, retry or fall back before returning the final package.
Why this example matters
If the summary is complete and the metric fields satisfy the schema, the workflow continues. If a value is missing or looks unreliable, the run can retry the extraction step or switch to a fallback path before finishing.
State is what keeps the workflow coherent
The workflow does not depend on hidden model memory alone. It keeps an explicit record of the run: completed steps, intermediate outputs, validation results, retry counts, and pending decisions.
Shared context
Each step reads from shared state instead of guessing prior context.
Durable record
Each transition writes a durable record that can be inspected later.
Resumable runs
Because progress is written into state, interrupted runs are easier to inspect, recover, or continue deliberately.
If state is the main concept you want to understand, continue with OpenClaw flow state for a focused explanation of what gets stored and how that state drives the next step.
How tools fit into the loop
In OpenClaw, a tool call is just one step inside the runtime loop. The workflow reads the current state, passes the relevant inputs into the tool, then decides whether the output is good enough to write back and continue.
Read state and shape inputs
A tool step starts from the current workflow state, and the workflow decides what structured inputs should be passed into the tool.
Write back normalized results
Accepted outputs should be turned into stable fields the rest of the workflow can read reliably.
Route failures explicitly
If the tool fails or returns weak output, the workflow can retry, switch path, or stop instead of silently accepting the result.
Where to go next
Once the execution model is clear, the next useful step is to see how it appears in actual patterns and comparisons.