Execution history is the complete, ordered record of everything an agent run did: every LLM call and response, every tool invocation and result, every handoff, retry, and human approval, with timestamps. It serves as the system of record — an audit trail — for how the agent reached its output.
Why execution history matters
Agents take consequential actions: they move money, file tickets, send messages, and modify records. When one of those actions is questioned — by an engineer debugging a failure, a customer disputing an outcome, or an auditor applying a compliance regime — it is not enough to say the model decided. Someone has to show what the agent saw, what it chose, and on what basis.
Conventional infrastructure cannot reliably answer that. Application logs are sampled, unstructured, and spread across processes; by the time a question arrives, the exact inputs to a given model call are usually unrecoverable. And because models are non-deterministic, the run cannot be reproduced after the fact — whatever was not recorded at execution time is gone. Regulated industries make the requirement explicit: financial and healthcare rules demand documentary evidence of the sequence of activities behind a decision, which is precisely what an audit trail is.
How it works
A runtime that owns the agent loop can record it as a side effect of executing it:
- Every model invocation is appended to a durable store with the context it received and the full response it produced, including any tool-call decisions.
- Every tool call is recorded with its arguments, its result or error, its timing, and any retries.
- Control-flow events — handoffs between agents, pauses at approval gates, the identity of the approver, resumptions, and cancellations — are recorded in order alongside them.
- The resulting event sequence is the system of record. Dashboards and APIs read from it rather than from the live process, and the same events can be streamed out as they are appended for real-time monitoring.
Because the record is written by the execution layer itself, it is complete by construction: a step cannot run without leaving a record, and nothing depends on developers remembering to instrument their code.
Execution history vs. observability
The two are closely related but not interchangeable. Execution history is the recorded system of record: complete, ordered, and persistent, existing whether or not anyone is watching. Observability is the live visibility built on top of it — the dashboards, queries, and alerts through which people inspect runs. Observability can exist without a durable history, backed by sampled telemetry, but then reconstructing any particular run is approximate. With a full history underneath, observability becomes a view over ground truth.
In practice
A durable runtime checkpoints every step of a run in order to survive crashes, and the audit trail falls out of the same mechanism: the record that lets durable execution resume a run is the record an auditor reads later. Step-level traces and deterministic replay are both views over this history. For the reasoning behind recording every step, see why a durable runtime.