The planner passes its benchmark. The tool wrapper rejects malformed calls. The policy layer blocks a prohibited action. The final answer matches the expected answer.
Then imagine the assembled agent failing anyway.
In this composite scenario, it retrieves evidence before a policy update, carries that stale result into a later step, delegates work under broader authority than the original task allowed, and reaches the right final answer through a path no operator should accept.
Every component can look healthy while the run is not.
This is the gap between component evidence and deployment evidence. Unit, integration, regression, and benchmark tests still matter. They prove local properties and catch a large class of defects cheaply. But an agent is not only a set of callable parts. It is a system that moves through state, acts over time, uses tools, reads memory, hands work to other agents, and changes the environment along the way.
A green component suite proves local properties. A deployable agent also needs a receipt for the path it actually took.
The final answer hides the system that produced it
Most evaluation collapses a run into an endpoint:
- Was the answer correct?
- Did the task complete?
- Was the tool call valid?
- Did the model refuse the prohibited request?
- Did the benchmark score improve?
Those are useful questions. They are not the whole review.
Two agents can produce the same answer under materially different conditions. One may use current evidence, stay inside its authority, preserve reversibility, and escalate at the right moment. The other may use stale memory, cross an authority boundary, recover from an unsafe intermediate state, and happen to land on the expected output.
Outcome-only evaluation calls those runs equivalent. An operator cannot.
The missing object is the trajectory: the ordered path from initial conditions through actions, state changes, external interventions, and the final outcome.
Mirto et al. define a trajectory as a finite, temporally ordered sequence of relevant system-environment states, selected actions, and minimal execution annotations. Those annotations can include tool calls, retrieved evidence, delegation, and human handoffs. They only need to be rich enough to reconstruct why a step occurred and what external intervention it triggered.[^mirto]
That definition is intentionally lightweight. For deployment review, I would extend it to include the policy, authority, memory, coordination, and outcome context needed to decide whether the path was acceptable—not merely successful.
What a new survey found—and where its claims stop
A July 31, 2026 arXiv v1 survey by Mirto and six coauthors gives this problem a useful structure.[^mirto] The authors report a PRISMA-inspired review spanning five databases and two search passes, with a March 2026 coverage cutoff. They screened 7,197 unique records and included 257 papers.
The survey organizes agentic-system validation into five dimensions:
- Behavioral: Did the system pursue and complete the intended task under the conditions that matter?
- Safety: Did its decisions and actions remain inside acceptable risk boundaries?
- Temporal: Did evidence, policies, dependencies, and behavior remain valid as conditions changed?
- Regulatory: Can a reviewer reconstruct the evidence and accountability behind the run?
- Multi-agent: Did coordination, delegation, communication, and joint behavior remain acceptable?
This is the survey’s taxonomy, not a universal standard.
The authors describe behavioral evaluation as the most developed dimension, although its guarantees remain limited. They describe safety work as active but fragmented, temporal validation as the least consolidated, regulatory legibility and lifecycle evidence as underdeveloped, and open-ended multi-agent assurance as immature and under-covered.[^mirto]
Those are directional findings across different bodies of literature, not scores on one common maturity index.
The paper also uses medical care, industrial operations, and smart mobility to illustrate how trajectory failures can appear in consequential settings. These are literature-grounded illustrations paired with constructed traces. They are not incident reports, controlled evaluations, or production proof.
The limitations matter. The authors identify unstable terminology, a March 2026 cutoff, metadata inconsistencies in preprint-heavy venues, and retrieval skew toward IEEE Xplore that may underrepresent some machine-learning venues. One reviewer performed the selection process. A second reviewer independently checked classification of the 257 included papers, but that does not remove selection-bias risk from the earlier screening stage.[^mirto]
So the paper does not establish a consensus standard or validate a production method. It does support a narrower conclusion: component results alone cannot describe whether an agent’s complete path remained acceptable across context, time, and interaction.
Why component tests are not enough for AI agents
The practical shift is not “stop testing components.” It is “stop treating component passes as sufficient evidence for the assembled system.”
Keep the existing layers:
- deterministic unit tests for wrappers, validators, and policy code;
- integration tests for interfaces and dependencies;
- regression suites for known failures;
- benchmarks for bounded capabilities;
- security tests for individual tools and entry points.
Then add trajectory review around them.
A trajectory test asks different questions:
- Was the initial scenario represented correctly?
- Which plan did the system form, revise, or abandon?
- Which policy version applied at each consequential step?
- Did tool authority narrow or widen during the run?
- What memory or retrieved evidence influenced the decision?
- Which state transitions occurred, including recovered failures?
- Did another agent alter the plan, evidence, or authority chain?
- Was the outcome acceptable for the right reasons?
- Where was human verification required, and did it happen?
This catches failures that disappear when a run is reduced to a final answer.
Consider a hypothetical refund workflow. An agent is authorized to prepare a refund but not issue one. The planner generates a valid plan. The refund tool correctly enforces its schema. A delegated sub-agent inherits a stale authority snapshot and executes the refund. The customer receives the expected outcome.
Planner test: pass. Tool-schema test: pass. Outcome test: pass. Trajectory review: fail.
The defect lives in the transition between authority states, not in any isolated component.
Preserve a Trajectory Evidence Ledger
I would make that path reviewable with a Trajectory Evidence Ledger.
This name and schema are my operator framework, not an artifact validated by Mirto et al. The survey supports reconstructable annotations and reviewable evidence chains. The exact fields below are an implementation pattern for turning that direction into release evidence.
Before the run
- Scenario — The task, environment, risk tier, expected boundaries, and success conditions.
- Policy version — The policy set that governs the run, including effective time and applicable exceptions.
- Plan — The initial plan and any criteria that require replanning, escalation, or termination.
- Tool authority — Which tools and actions are allowed, denied, conditional, reversible, or human-gated.
- Memory state — The versions, timestamps, and provenance of memory or retrieved evidence that may affect behavior.
During the run
- State transitions — The consequential before-and-after states, selected actions, tool results, policy checks, and recovery attempts.
- Coordination — Delegations, messages, responsibility transfers, authority changes, and joint decisions across agents and humans.
After the run
- Outcome — The result, side effects, unresolved uncertainty, and whether success criteria were met.
- Human verification — The required review point, reviewer role, evidence inspected, decision, and any exception or rollback receipt.
The ledger should preserve enough references, versions, and receipts to reconstruct the run. It should not become an excuse to retain every prompt, memory item, tool payload, or sensitive datum.
Reconstructability and indiscriminate collection are not the same thing.
A strong ledger can point to restricted evidence by immutable reference, record a redacted decision summary, preserve policy and artifact versions, and apply retention rules by risk class. The question is whether an authorized reviewer can understand the path—not whether the organization can accumulate the maximum amount of data.
Test one path across five dimensions
The five dimensions are most useful when they are applied to the same trajectory instead of split into five disconnected dashboards.
Behavioral
Ask whether the agent completed the intended task under representative and adversarial conditions. Review plan quality, recovery behavior, tool selection, and whether the final result came from an acceptable sequence.
A correct outcome reached through luck is weak evidence. A failed outcome with a clean escalation may be acceptable behavior under the scenario.
Safety
Ask whether the trajectory entered prohibited or unsafe states, even temporarily. Review irreversible actions, privilege changes, sensitive-data exposure, escalation boundaries, and recovery attempts.
“Recovered before the final answer” is not the same as “never crossed the boundary.”
Temporal
Ask whether the evidence and controls remained valid for the duration of the run. Record the age of retrieved information, policy effective times, dependency versions, credential or authority changes, and drift signals.
This matters most in long-running workflows. A source that was current when planning began can be stale when the action executes.
Regulatory
Ask whether the evidence is legible to the person accountable for the decision. Can that reviewer connect the scenario, policy, action, outcome, and human intervention without reconstructing the system from scattered logs?
Legibility does not guarantee compliance. It makes review, challenge, and accountability possible.
Multi-agent
Ask whether the joint trajectory remained acceptable. Review task allocation, message loss, conflicting plans, duplicated action, responsibility ambiguity, and authority inheritance.
Testing each agent separately does not establish that their composition is safe. The failure can exist only in the handoff.
Make validation lifecycle-shaped
Mirto et al. propose four cumulative research directions: bounded-autonomy specifications, adversarial trajectory generation, temporal runtime monitoring, and human oversight plus evidence legibility. The paper’s conclusion summarizes the fourth direction as human-verified evidence chains.[^mirto]
The proposal is a research agenda, not a production-proven stack. But its shape is right for operators because it follows the system across time.
Specify bounds before testing. Define what the agent may do, what it must never do, when authority changes, and which states require escalation. A test cannot prove conformance to a boundary nobody wrote down.
Generate difficult trajectories before release. Test more than prompts and final answers. Vary evidence freshness, tool order, partial failures, memory conflicts, authority transitions, human delays, and other-agent behavior. Look for unacceptable paths that still end in plausible outputs.
Monitor trajectories after release. Production changes the evidence. Policies age. Tools change. Models drift. Users combine capabilities in ways the test suite did not anticipate. Monitor the same trajectory properties used at release, with explicit thresholds for investigation, degradation, rollback, or escalation.
Keep oversight attached to evidence. A human approval checkbox is weak if the reviewer cannot see the relevant path. The review surface should expose the scenario, material state transitions, authority boundaries, uncertainty, outcome, and rollback option.
Turn the ledger into a release gate
My release rule would be simple:
An agent release needs both component passes and acceptable trajectory evidence.
A practical gate can ask:
- Did required component, integration, regression, and security checks pass?
- Did representative and adversarial trajectories stay within behavioral and safety bounds?
- Was the evidence current for the decision and execution window?
- Did policy, tool, and delegation authority remain valid at each consequential transition?
- Were multi-agent handoffs and shared state reviewed where applicable?
- Can an authorized reviewer reconstruct the path from the ledger without collecting unnecessary sensitive data?
- Did every required human-verification point produce a decision receipt?
- Are drift signals, rollback conditions, and escalation owners defined?
This gate is my adaptation of the survey’s ingredients. It has not been validated by that survey, and it is not a safety or compliance guarantee.
It is still a stronger deployment question than “Did the benchmark go up?”
The goal is not to log everything or turn every run into a forensic investigation. The goal is to preserve the minimum evidence that distinguishes a good answer from a good system.
If a team cannot reconstruct which policy applied, what authority the agent held, what evidence it used, how state changed, who else acted, and why a human approved the result, then the team does not yet have a deployment receipt.
It has an output.
[^mirto]: Alessandro Mirto et al., “Beyond Component Testing: Validating Agentic AI Systems”, arXiv:2607.29405v1, July 31, 2026. This article treats it as a survey preprint with the authors’ stated corpus and methodological limitations—not as peer-reviewed consensus or a regulatory standard.