When to Intervene in an AI Agent Trajectory: Causal Evaluation Instead of a Single Benchmark Score

A practical guide to evaluating human review, verifier modules, filtering, and recovery within agent trajectories: sequential randomization, selecting a causal estimand, designing an experimental harness, safety metrics, and moving to a production intervention policy.

Two agents can each achieve a 70% task success rate yet require opposite control policies. For the first, review is useful before write operations but gets in the way of reading data. For the second, review is nearly useless early in a task but rescues trajectories after a failed tool call.

A conventional benchmark does not reveal this distinction. It answers: “How often does this agent configuration complete tasks successfully in this environment?” An operational control plane must answer something else: “Will the outcome improve if we intervene now, before this action, given what has already happened?”

This is not merely a matter of more granular analytics. It is a causal question. An intervention changes the agent’s subsequent actions, the environment state, and the opportunities for further control. As a result, comparing reviewed and unreviewed trajectories in logs will almost inevitably confound the effect of review with the difficulty of the situations in which it was enabled.

Sawarni et al. formalize this problem as dynamic causal inference and propose randomizing interventions at sequential points in a trajectory. The authors demonstrate heterogeneous effects on τ-bench Retail, ToolSandbox, and ImpossibleBench. However, at the time the research dossier was prepared, this was a preprint without confirmed independent replication. Its results are best treated as a methodological foundation and a source of hypotheses, not as universal evidence that a specific control mechanism works. This article presents a methodology and implementation protocol; it includes no original experiment or new measurements.

A benchmark evaluates a configuration, not a decision within a trajectory

Static evaluation is useful when you need to:

• compare models or agent versions;

• detect regressions;

• test baseline capabilities;

• cheaply screen out weak configurations;

• evaluate the agent, tools, instructions, and environment as a whole.

The problem starts when a team tries to turn an average score into a control rule.

Suppose a reviewer is enabled only before money transfers, data deletion, or after several failed attempts. Reviewed trajectories will inherently be harder and riskier than unreviewed ones. If their final success rate is lower, that does not mean review is harmful. Without it, the outcome may have been worse still.

The opposite error is possible as well. If an operator intervenes only in obvious cases where a correction is almost guaranteed to work, logs will show a strong positive effect. That does not imply review should be applied to every action.

At every eligible point, there is a counterfactual question:

What would have happened to this same trajectory if, with the same available history, the intervention had been assigned differently?

Both continuations cannot be observed simultaneously. A causal experiment is needed to estimate their average difference in comparable states.

It is also important to distinguish three levels of observation:

1. Static evaluation shows the outcome of a fixed configuration.

2. Log analysis helps identify recurring failure modes, formulate risk features, and define possible intervention points.

3. Causal evaluation tests whether an intervention changes an outcome rather than merely correlating with it.

Post hoc analysis remains useful, but it does not replace an experiment. Time-varying factors are especially dangerous: a state may be caused by earlier review, affect the next review decision, and predict the final outcome at the same time. This is the classic problem of time-varying confounding, addressed in work on marginal structural models, among other approaches.

The unit of decision is an eligible point within a trajectory

For causal evaluation, it is not enough to assign some agents to “control” and others to “review.” You need to define the moments at which the control plane can actually make a decision.

Such points may include:

• a proposed tool call;

• a batch of related calls;

• a failed result submission;

• a detected constraint conflict;

• exceeding a retry limit;

• a state from which a recovery procedure is permitted.

Every point must satisfy a predefined eligibility rule. It does not answer, “Should we intervene?” It answers a more fundamental question: “Can we safely and technically compare permissible alternatives here?”

For example, an irreversible funds transfer should not enter an experiment where the control branch permits a known-dangerous action. Such states require a hard safety barrier. Randomization is possible only among options that all fall within the established risk limit—for example, between two review methods, in an isolated environment, or in shadow mode.

The intervention must be specific

“Let’s evaluate the value of review” is too vague. An experiment must specify exactly what happens:

• whether the action is reviewed by a human or a model;

• whether the reviewer may only approve an action or may also replace it;

• whether the reviewer may request additional information;

• which prompt and model version are used;

• how much time is allowed for a response;

• what happens on an error or timeout;

• how control is handed back to the agent.

In the experiments by Sawarni et al., a reviewer could approve a tool call, replace it, or request additional information. The treatment being evaluated is therefore not an abstract “review,” but a particular mechanism with a particular model and the authority to alter the rest of the trajectory.

This matters for interpretation. A positive effect from a bundled mechanism does not independently prove that:

• the reviewer model itself is useful;

• the chosen invocation point is optimal;

• the additional delay does not affect behavior;

• the same result would hold for human review;

• the ability to replace an action is better than simply blocking it.

Separating these components requires additional experimental arms. Otherwise, the conclusion must apply to the mechanism as a whole.

Four methods answer different questions

A session-level A/B test remains appropriate when the entire orchestrator or agent configuration changes. For example, Agent Arena randomly assigns configurations to complete real-world sessions and estimates causal effects from observed signals. This is a useful production analogue, but it does not determine which specific action within a trajectory should trigger review.

A micro-randomized experiment brings repeated assignment into the internal states of a session. In the original micro-randomized trials methodology, treatment or control is assigned at every available decision point. In an agent system:

• the participant becomes the trajectory or session;

• availability becomes a safe opportunity to intervene;

• treatment becomes review, filtering, corrective feedback, or recovery;

• a proximal outcome becomes the next tool result, a safety event, or recovery cost;

• a distal outcome becomes final task quality.

Choose the causal question before choosing the estimation method

Even with correct randomization, the phrase “effect of an intervention” is ambiguous. In a dynamic system, you must define not only the current assignment but also what happens after it.

Local effect under continued randomized control

The first option compares intervention and no intervention now, after which future decisions continue to be assigned under the experimental policy.

This effect answers:

Is review useful at the current point if the system continues operating under the same randomized regime afterward?

This estimand is useful for identifying states and action types with positive or negative effects. The main paper uses cross-fitted augmented inverse-probability weighting with known assignment probabilities for this purpose.

But it is not necessarily the effect of a one-off intervention in normal operation. Future reviews may compensate for a current error or, conversely, intervene in a trajectory that has already been corrected.

Effect of the current intervention with no further interventions

The second option compares two continuations in which no additional control is applied after the current decision.

It is closer to the question:

What does correcting the situation now achieve if the agent must then complete the task on its own?

This effect is useful for systems where review is expensive, allowed only once, or permanently returns control to the agent afterward. However, estimating it requires assumptions about a continuation that the experiment may have observed only rarely.

Gain from an entire policy

The third metric is the difference in final outcome between two complete policies. For example:

• always execute calls directly;

• review every call;

• review only write operations;

• enable recovery after the second error;

• route states with risk scores above a threshold to review.

This is closest to the production question:

What changes if we deploy the selected routing rule instead of the current one?

In general, policy gain cannot be obtained by summing local effects. An intervention changes future states and therefore the set of points at which a policy can act. To estimate alternative continuations and policies, Sawarni et al. use additional parametric assumptions from a structural nested mean model and explicitly identify this as a limitation.

How to design an experimental harness

1. Freeze the experimental configuration

For the duration of data collection, lock down:

• the agent version and system instructions;

• reviewer models and prompts;

• tool versions and API schemas;

• the environment state or version;

• decision-point eligibility criteria;

• the meaning of the control and treatment branches;

• timeout and error-handling rules;

• definitions of terminal outcomes.

If these components change during an experiment, the result estimates a mixture of different mechanisms. Changes are acceptable as separate phases, but they need their own versions and analysis boundaries.

2. Record state before assignment

At a minimum, the pre-randomization record should include:

• an immutable session and trajectory ID;

• the task and environment version;

• the ordinal number of the decision point;

• the reason the point was deemed eligible;

• the history available at that point and computed features;

• the proposed action or batch of calls;

• the agent, tool, and reviewer versions;

• the assignment probability for each branch;

• the random-number generator or randomization seed.

The key principle is that router features must exist before treatment assignment. You cannot train or evaluate a rule on information that appeared as a result of review.

3. Randomize only among permissible alternatives

At every eligible point, the harness randomly assigns intervention or control with a known probability. Randomization provides sequential exchangeability for the assigned intervention: given the same prior history, the branches are comparable on average with respect to pre-assignment state.

Identification also requires other conditions:

• Consistency: the observed outcome corresponds to the option actually implemented.

• Positivity: in relevant states, every compared intervention or policy has a nonzero probability of being assigned.

• No interference: one trajectory does not alter another trajectory’s outcome.

Timeouts and other deviations of actual execution from assignment are a separate issue. It is safer to estimate the primary effect by assignment; estimating the effect of the intervention actually received requires a separately specified method and additional assumptions.

Positivity is a practical constraint, not a mathematical formality. If the logging policy never allowed direct execution for a certain class of actions, those data cannot reliably evaluate a policy that always allows direct execution. Likewise, a near-zero probability for one branch produces unstable weights and wide intervals.

4. Record actual execution and outcomes

After assignment, record at least:

• the reviewer or recovery-procedure response;

• the action actually executed;

• the tool result;

• deviations of actual execution from assignment;

• the final task outcome;

• labels for violations that actually occurred;

• the number of retries and steps;

• waiting time and total latency;

• token usage and monetary cost for both the agent and reviewer;

• the amount of human work, if human review was used.

Separately recording assignment and execution is necessary to monitor treatment fidelity. If the “review” branch regularly times out and effectively becomes direct execution, the experiment is estimating a different mechanism.

5. Treat a session as a connected system of observations

Multiple points within a trajectory are not independent experiments. They share a history, and early decisions alter later states. Therefore, data splitting for cross-fitting and statistical inference should be organized by trajectory rather than by randomly mixing individual points across samples.

6. Separate policy discovery from policy confirmation

A practical process has three stages:

1. Exploratory collection: a sufficiently broad randomized policy creates coverage of relevant states.

2. Offline selection: logs are used to compare candidate selective policies.

3. Confirmation: the preselected policy undergoes a direct randomized comparison with the baseline.

Evaluating a new policy from old data saves runs, but it does not eliminate uncertainty. Over long horizons, standard importance weights can have rapidly increasing variance. Doubly robust and model-assisted methods can reduce mean squared error, but they do not create missing coverage or rescue a misspecified model. The limitations of these methods are discussed in work on off-policy evaluation.

One success rate is not enough

An intervention may improve task completion while increasing latency, reducing dangerous actions, and damaging some otherwise-correct trajectories. Collapsing these outcomes into one number hides the trade-offs.

Results should be presented as a vector:

• terminal task success or quality;

• actual policy violations;

• estimated causal effect on violation risk, including prevented violations;

• estimated number of rescued failing trajectories;

• estimated number of disrupted correct trajectories;

• retries, steps, and recovery burden;

• total latency and reviewer time;

• token consumption and monetary cost;

• human-review workload.

Rescue and harm must be estimated separately

A recovery procedure may raise the probability of success for trajectories that would otherwise fail. The same procedure may reduce the probability of success for trajectories that would have reached the correct result on their own. These quantities are counterfactual: both continuations cannot be directly observed for one trajectory, so they are estimated using predefined causal contrasts between assignments or policies.

The preprint by Xiao et al. treats recovery as a causal decision and separates rescue from harm. The authors report a selective policy that did not disrupt trajectories estimated to be correct without intervention. This is a preliminary result, but the framing matters: a router should optimize not only the estimated number of rescues, but also the risk of unnecessary intervention. For details, see When Harnesses Lose the Signal.

Scalar utility requires predefined rules

Sometimes a system still needs a single metric for policy selection. In that case, define before analysis:

• weights for quality, latency, and cost;

• a minimum acceptable level of task completion;

• hard safety constraints;

• events that automatically prohibit policy deployment.

Without predefined weights, a team can tune the formula after the experiment so that its preferred option appears better. Safety in particular requires veto rules: higher task completion must not offset an unacceptable increase in severe violations.

Rare catastrophic events create a separate statistical-power problem. The available sources provide no universal sample-size recipe for such risks. Before launch, define a minimally meaningful risk level, an allowable exposure budget, and an escalation rule. The absence of an observed catastrophe in a small sample is not evidence of safety.

What three task types demonstrate

τ-bench Retail: reviewing everything and reviewing selectively are different policies

In τ-bench Retail, review or direct execution of a proposed call was assigned with probability 1/2. The reviewer could approve the call, replace it, or request information.

The authors found heterogeneous effects across tool groups. For GPT-5 nano, positive effects were estimated for several read and write operations. For Claude Haiku 5.5, the aggregate effect across read operations was close to zero, although a positive effect was estimated for retrieving account details.

This is not a universal rule about particular models or tools. The results depend on the agent version, reviewer, prompts, and environment. In addition, the paper reports pointwise confidence intervals for many subgroups without an explicit correction for multiple comparisons. These findings are best used to select candidates for confirmatory experiments, not as a ready-made production policy.

The case demonstrates the central point: “always review” and “review only a particular family of calls” are different dynamic policies. An average benchmark score does not say which is preferable.

ToolSandbox: environment state makes a local error long-term

ToolSandbox models a conversational environment with state-changing tools. Evaluation uses milestones—required events—and minefields—prohibited events. Its primary score allows partial completion, but may be set to zero for a benchmark-defined violation. Turn count is measured separately and reflects efficiency rather than task quality.

This environment is useful for testing the consequences of interventions. Replacing a single call can change the phone’s state, the subsequent actions available, and the ability to reach later milestones. A reviewer therefore cannot be evaluated solely on whether it corrected the immediate call. The evaluation must account for the final outcome, prohibited events, added turns, latency, and recovery cost.

ImpossibleBench: passing may mean violating the specification

ImpossibleBench creates tasks where the natural-language specification conflicts with unit tests. Passing such a task is possible only through a workaround that violates the specification.

In the Sawarni et al. experiment, the Qwen3.5 Flash agent received adversarial or neutral feedback before its subsequent actions. This example shows why completion cannot automatically be treated as a beneficial outcome. A higher test-passing rate here may indicate a greater willingness to exploit tests contrary to requirements.

A correct system must have an acceptable path to stop and report the conflict. The outcome vector must separately represent formal task passing, compliance with the specification, and the choice to refuse an unsafe continuation.

Limitations of a causal experiment

Sequential randomization addresses an important problem, but it does not turn an experiment into a safety certificate.

Limited transferability

A result applies to a particular combination of:

• task distribution;

• agent and reviewer versions;

• prompts;

• tools;

• environment semantics;

• eligibility criteria;

• permissions granted to the intervention mechanism.

A simulated user and tool can differ from a production system. Even an experiment on real sessions does not guarantee transferability after changing the model or router.

Weak state coverage

Offline evaluation cannot reliably extrapolate into regions that are nearly absent from logs. If a new policy differs substantially from the logging policy, new data collection or a direct experiment is required.

Multiple subgroup searches

The more tool types, states, and features a team analyzes, the more likely it is to find a convincing-looking effect by chance. Exploratory slices should generate hypotheses; key routing rules should be confirmed on new data.

Semantic triggers still require separate validation

Features such as “unjustified confidence,” user persuasion, or formation of a harmful plan may look like attractive intervention criteria. But detector error affects both the composition of eligible points and causal interpretation. The main paper identifies such triggers as future work, not as a ready-to-use solution.

Replay is not the same as actual randomization

Replay and causal attribution may help analyze failures, but they require strong structural assumptions. They should not automatically be treated as substitutes for an experiment. This is especially true for early preprints whose transferability has not yet been confirmed.

A practical implementation protocol

A team that wants to move from an overall benchmark score to an intervention policy does not need to build a complex causal-inference system immediately. It can start with a sequential protocol.

1. Describe the control-plane decision. Not “Is a verifier useful?” but “Before write operations, should a reviewer be allowed to approve, replace, or stop the proposed call?”

2. Define safe points. Exclude irreversible and unacceptably risky actions, or move them to an isolated environment.

3. Specify the treatment. Model versions, prompts, reviewer permissions, timeouts, and error handling must all be part of the specification.

4. Choose a causal estimand. Decide whether you need a local effect, an effect without subsequent interventions, or the gain of a full policy.

5. Define outcomes before launch. Separate quality, safety, estimated rescue and intervention-induced harm, latency, cost, and human workload.

6. Log history before assignment. The proposed action and every routing feature must be saved before randomization.

7. Ensure nonzero coverage. The logging policy must actually generate the alternatives you plan to compare.

8. Analyze by trajectory. Do not treat sequential points in one session as independent observations.

9. Use subgroups to select hypotheses. Do not deploy a discovered rule simply because it produced one positive local effect.

10. Confirm the selected policy directly. Offline evaluation should end with a randomized comparison of the final rule against the current baseline policy.

11. Constrain deployment. Start with a small exposure budget, monitor version changes, and define stop conditions in advance.

12. Continue static testing. Causal evaluation does not replace regression and capability testing; it complements them by determining where control actually changes outcomes.

The architectural shift is not about abandoning benchmarks. It is about no longer expecting a benchmark to answer a question it was not designed to answer. A benchmark measures a configuration. A sequential causal experiment evaluates a decision. And a production policy emerges only when a team has defined acceptable intervention points, the required counterfactual effect, and separate constraints for quality, safety, latency, and cost.