How it works
An execution trajectory forms as an agent repeatedly observes its current state, selects an action, receives a result, and updates what it will do next. It is the actual path through the run, not merely the original plan. Two runs that begin with the same prompt can follow different trajectories because tool results, retrieved context, model choices, approval decisions, or failures change the available next steps.
A typical trajectory contains:
- An initial objective, context bundle, permissions, and execution limits.
- A decision that selects a tool, delegates work, requests approval, or produces an answer.
- An observation such as a tool response, validation result, timeout, or operator intervention.
- A state transition that records completed work, remaining obligations, and newly introduced risks.
- A stop, retry, branch, rollback, or compensating action.
The harness shapes this path by constraining which transitions are legal. It may reject a tool call outside the permission scope, require an approval before an irreversible action, or stop the run when its budget is exhausted. Checkpoints make selected states durable so the run can resume without pretending that incomplete work never happened.
A useful trajectory therefore includes both model-selected actions and deterministic harness decisions. Omitting either produces an incomplete account of how the system behaved.
Why it matters in an agent harness
A final answer tells you what the agent produced. The execution trajectory tells you whether the production process stayed within its contract. That distinction matters whenever the agent can change files, invoke remote tools, spend resources, delegate authority, or leave external systems in a partially modified state.
Trajectory visibility supports control at the point where control is useful. The harness can evaluate a proposed transition before execution, inspect a result before committing the next step, and interrupt a run whose actions are diverging from its objective. Permission checks also become contextual. A tool may be allowed in general but inappropriate after an untrusted retrieval result or outside the state for which approval was granted.
Trajectories are also the right unit for diagnosing multi-step failures. An incorrect outcome may come from a bad initial assumption, weak context assembly, a misleading tool observation, an unbounded retry loop, or a correct action applied to stale state. Looking only at the output collapses these causes into the same symptom.
Recovery depends on the same structure. A harness cannot safely resume merely because it knows the last tool call. It needs to know which effects were committed, which outcomes remain unknown, which approvals are still valid, and whether repeating an action is idempotent. Otherwise, a retry can duplicate a payment, overwrite newer work, or claim success after only part of the run completed.
For evaluation, trajectories expose behavior that outcome scoring misses. A run may reach the correct answer through excessive privilege, unnecessary tools, repeated failures, or an action that happened to be reversible this time. Those are harness defects even when the final artifact looks acceptable. Conversely, a well-bounded trajectory may correctly stop without completing the task because the evidence, authority, or recovery guarantee was insufficient.
Execution trajectory vs execution trace
The trajectory is what happened during execution. The execution trace is the recorded representation used to inspect it. This distinction changes system design because recording more detail does not automatically create stronger control, and an unrecorded transition still affects the real run.
| Axis | Execution trajectory | Execution trace |
|---|---|---|
| Role | The sequence of decisions, actions, observations, and state changes | The durable or streamed record of that sequence |
| Exists when | The run progresses | Instrumentation captures and preserves events |
| Primary use | Control, recovery, and behavioral reasoning | Debugging, audit, evaluation, and replay support |
| Main failure | Unsafe or incoherent transitions | Missing, ambiguous, or misleading records |
A trace should identify consequential trajectory events with stable ordering, attribution, and state references. It does not need to preserve every internal token to be useful. It does need enough information to distinguish proposed actions from executed actions, acknowledged effects from unknown outcomes, and model decisions from harness-enforced transitions.
The Rifty take
We optimize trajectories for legibility and bounded recovery, not for the appearance of uninterrupted autonomy. We accept a stopped run when authority, evidence, or outcome state is unclear. A system is more reliable when it can explain where it is, what changed, and which transitions remain safe.
Implementation checks
- Give every run and consequential step a stable identifier so retries are not mistaken for new work.
- Record the objective, initial state, permission scope, budgets, and stop conditions before execution begins.
- Distinguish proposed, authorized, attempted, completed, failed, and unknown-outcome actions.
- Capture tool inputs and results at the level needed to explain state transitions without leaking credentials or unrelated sensitive data.
- Attribute each decision to the model, harness rule, operator, subagent, or external system that made it.
- Persist checkpoints only after defining which effects are committed and which work can be repeated safely.
- Treat approval as scoped authority tied to a particular action and state, not as permanent permission for the rest of the run.
- Test interruption between consequential steps, including the interval after an external effect but before local acknowledgement.
- Evaluate trajectories for excess privilege, redundant calls, loops, ignored failures, and invalid recovery, even when their final outputs are correct.
- Make missing trajectory records visible. An unexplained gap should not be rendered as a clean, successful path.
Frequently asked questions
What should an execution trajectory record?
An execution trajectory should record consequential decisions, attempted and completed actions, observations, state transitions, approvals, retries, and termination reasons. It should also preserve attribution and ordering. The required detail is whatever lets an operator distinguish what was proposed, what actually happened, and what can safely happen next.
Is an execution trajectory deterministic?
An execution trajectory is not necessarily deterministic. The harness may enforce deterministic boundaries while model decisions, retrieved information, timing, and tool responses vary between runs. Reliability comes from constraining legal transitions and recording actual ones, not from assuming that identical inputs will always produce an identical path.
How does trajectory evaluation differ from output evaluation?
Trajectory evaluation scores how the agent reached an outcome, while output evaluation scores the resulting artifact or answer. Trajectory checks can detect excessive permissions, unnecessary tool calls, ignored failures, unsafe retries, or invalid approvals even when the final output appears correct. Production evaluation usually needs both views.
Can an execution trace be used to replay a trajectory?
A trace can support replay only when it captures enough state, ordering, inputs, outcomes, and external-effect information. Exact replay may still be impossible when tools or environments have changed. In those cases, use the trace to reconstruct decisions or simulate transitions rather than repeating irreversible actions blindly.