AI agent trajectory evaluation: test the path, not only the result

Trajectory evaluation checks the sequence of observations, decisions, tool calls, environment responses, approvals, and state transitions between the request and the final result. An outcome grader asks whether the task was completed; a trajectory grader asks whether the agent used permitted sources and tools, respected policy, avoided duplicate side effects, and reacted correctly to failures. A read-only question may sometimes need only an outcome check. A payment, customer message, repository change, or PII workflow requires path safety as a separate release condition.

Do not require one canonical chain of steps: strong agents can legitimately complete the same task through different routes. Define invariants, allowed action classes, prohibited events, and the authoritative terminal state instead. A good grader permits multiple safe trajectories but fails a secret leak, unauthorized write, hidden error, duplicate action, or final answer without evidence regardless of how convincing the output looks.

A minimum trace records the task ID, tenant or user context, model and agent revision, policy version, initial-state fingerprint, observation, decision event, tool name and version, arguments or a safe hash, authorization verdict, tool-result status, retry or idempotency key, approval event, side-effect receipt, final answer, and terminal state. Timestamps and parent-child IDs let you reconstruct causal order across parallel steps. Sensitive payloads should not be copied indiscriminately: keep redacted evidence and a separately protected raw artifact only when justified.

The trace must come from orchestration and tool boundaries rather than model self-report. A statement such as “I checked the CRM” does not prove a CRM call; polished chain-of-thought is not an audit log and is not required to verify external actions. Log observable events, versions, and postconditions. If telemetry is missing for a consequential run, the verdict is INCONCLUSIVE rather than PASS.

Split the verdict into planning relevance, tool correctness, authority, state integrity, and recovery. Planning relevance catches purposeless loops and missing required checks. Tool correctness verifies tool selection, schema-valid arguments, and response handling. Authority maps every action to identity, scope, approval, and current state. State integrity compares the claimed outcome with the system of record. Recovery covers timeout, partial commit, rate limit, stale approval, and dependency failure.

Evaluate efficiency only after correctness and safety. Fewer steps are not better if the agent skipped an identity check; more steps are not worse if they provide required confirmation. Useful measures include task success, critical invariant failures, invalid or unauthorized call rate, duplicate side effects, unnecessary calls, recovery success, evidence coverage, latency, and cost per safely completed task. Do not collapse a critical failure and token savings into one average score.

• Outcome → authoritative terminal state satisfies the task contract.
• Trajectory → every step is permitted, relevant, and evidenced.
• Policy → no hard invariant is violated.
• Recovery → uncertain state is reconciled before retry.
• Efficiency → evaluated only among safe successful runs.

Deterministic graders should check schema, allowlists, identity and scope, approval freshness, idempotency, prohibited events, and authoritative postconditions first. A model grader is useful for semantic plan relevance, evidence sufficiency, or escalation quality, but it should receive a structured trace and rubric rather than an uncontrolled transcript. Keep human review for high-risk ambiguous cases and grader calibration.

Validate the grader on a labeled set containing positive, negative, and boundary cases. Measure disagreement by risk slice rather than only aggregate agreement. Version the prompt, rubric, grader model, and threshold together with the agent bundle. A model grader must not override a deterministic security failure; a confident explanation cannot turn an unauthorized write into an acceptable action.

The evaluation set should include tool timeout before a write and after a partial commit, malformed results, 429 responses, stale data, schema drift, revoked permission, expired approval, a cross-tenant object, prompt injection in tool output, duplicate events, conflicting sources, an unavailable oracle, and tasks where abstention is the correct action. For every fixture define the initial state, injected fault, allowed transitions, prohibited events, and terminal oracle.

“Reconcile before retry” is especially important: after an uncertain write, the agent reads the system of record using the operation key and only then decides whether to repeat the action or finish. Test compensation as well. If a workflow created a draft but failed to attach it to the case, does an orphan remain or is an owner task opened? Partial success is exactly what separates production trajectory evaluation from a tool-calling demo.

Run a frozen regression set, held-out cases, and a fault-injection slice against pinned model, prompt, tools, policy, and environment. Promotion requires acceptable outcomes in every critical slice, zero defined hard-invariant failures, a compatible grader, and tested rollback. Start canaries with read-only or draft-only authority; expanding write scope is a separate decision, not a reward for a better average score.

After a change to the model, tool schema, permission policy, retry logic, or grader, the previous verdict becomes historical evidence. Rollback restores the full compatible bundle, stops new runs, and reconciles unfinished side effects. Reduce a production incident to a privacy-safe regression case. Evaluation then becomes a living release control rather than a one-time spreadsheet ceremonially forgotten after the pilot.