AgentPex: AI Trace Procedural Evaluation

• AgentPex is an AI-powered, specification-driven system that assesses long execution histories (agentic traces) for adherence to prompt-derived procedural and workflow rules.
• It normalizes heterogeneous logs and extracts both policy and task-specific specifications, using multi-tier evaluators to measure compliance and detect failures.
• Empirical results reveal that outcome-correct traces often mask procedural errors, emphasizing the need for granular, trace-time evaluation beyond end-state metrics.

AgentPex is an AI-powered, specification-driven system for evaluating agentic traces: long execution histories produced by tool-using agents through multi-turn dialogue, tool invocations, intermediate decisions, and stateful workflow steps. It was introduced in “Willful Disobedience: Automatically Detecting Failures in Agentic Traces” as a response to the mismatch between outcome-only evaluation and the procedural realities of deployed agents. Rather than asking only whether a trace ends in the correct state, AgentPex asks whether the trace remained compliant with prompt-derived rules, workflow constraints, tool-usage requirements, and task-specific expectations throughout execution (Sharma et al., 25 Mar 2026).

1. Concept and problem setting

AgentPex is designed around the claim that modern agents can be outcome-correct yet procedurally unsound. In the target setting, a trace may complete a customer-service task successfully while still violating transition rules, skipping required verification, making disallowed tool calls, providing subjective recommendations forbidden by prompt policy, or performing arithmetic outside a required calculator tool. The paper groups these behaviors under the label “willful disobedience”: selective noncompliance with system-prompt rules during long trajectories (Sharma et al., 25 Mar 2026).

The motivating contrast is with outcome-oriented benchmarks such as $\tau^2$-bench. Those benchmarks primarily evaluate whether the final database state or final communication is correct. AgentPex instead evaluates whether the agent followed the specified procedure and policy across the entire trace. This includes failures such as workflow routing errors, unsafe or incorrect tool usage, and violations of prompt- or instruction-specified rules. The intended use case is large-scale validation where manual trace inspection is too costly and outcome-only scoring is too coarse.

At the input boundary, AgentPex consumes a normalized trace artifact consisting of the system prompt, tool schema, message history, and optional task metadata such as task description and initial state. At the output boundary, it produces extracted specifications, evaluator judgments and reasoning, per-metric scores on a 0–100 scale, an aggregate score, and serialized JSON for downstream inspection or analysis.

2. Trace normalization and specification extraction

AgentPex begins by normalizing heterogeneous logs into a format-agnostic trace representation. The paper states support for $\tau^2$-bench format, standard OpenAI message format, and VS Code chat logs. This stage is intentionally format-translation only; the later stages consume the normalized artifact rather than any benchmark-specific representation (Sharma et al., 25 Mar 2026).

Specification extraction is split into Policy Specifications and Task-Specific Specifications. Policy Specifications are derived from the system prompt and tool descriptions. AgentPex uses an explicit-only extraction policy: the extraction model is instructed to extract only constraints that are directly stated, not inferred. Within this family, the Output Specification captures formatting, style, refusal behavior, content constraints, mandatory confirmations, and user-facing communication rules; the Transition Specification captures ordering constraints, co-occurrence constraints, mutual exclusion, before/after conditions, and required checks before state-changing actions; Forbidden Edges identify explicitly prohibited tool-call transitions and are represented as tuples of the form $\{from, to, reason\}$; and Argument Specification is derived directly from the tool schema, covering required parameters, types, bounds, enums, patterns, and contextual schema constraints.

Task-Specific Specifications are generated for the concrete request under evaluation. The Predicted Plan is a tool-centric ordered plan of tool calls and expected outcomes required to satisfy the request. The Predicted Final State is a concise textual description of the end state expected from successful execution, constrained to literal values from init_state, the user request, and conversation history, and explicitly driven by the predicted plan. The extraction prompts instruct the model to remain procedural, to ground outputs in available tools, and to preserve exact wording where possible.

The paper’s motivating airline-domain trace illustrates the scale of this extraction stage: AgentPex derived 68 output rules and 36 transition rules from the trace context. Example output rules included “Do not provide any information, knowledge, or procedures not provided by the user or available tools” and “Do not give subjective recommendations or comments.” Example transition rules included “You should only make one tool call at a time, and if you make a tool call, you should not respond to the user simultaneously,” as well as a transfer protocol requiring a tool call to transfer_to_human_agents before sending a specific user-facing message.

3. Evaluator suite and aggregation mechanics

After extraction, AgentPex applies seven evaluators. These are Output Specification Eval, Transition Specification Eval, Forbidden Edges Specification Eval, Argument Groundedness Specification Eval, Argument Specification Eval, Predicted Plan Specification Eval, and Predicted Final State Specification Eval. Most are implemented as LLM-as-a-judge modules with standardized rubric prompts; forbidden-edge checking is programmatic; argument-spec evaluation is schema-based but still implemented with an LLM prompt over matched schemas and calls (Sharma et al., 25 Mar 2026).

The evaluation granularity is mixed by design. Output rules are checked at the level of individual assistant messages, transition and forbidden-edge constraints are checked over tool-call sequences, argument groundedness and argument specification are checked over tool-call arguments, predicted-plan compliance is evaluated over ordered semantic steps, and predicted-final-state compliance is evaluated over the full conversation outcome. This hybrid whole-trace and stepwise structure is central to the system’s claim that procedural failures can remain invisible to endpoint metrics.

The evaluators use severity tiers. For Output Spec Eval, the tiers are: TIER 1 (SEVERE) for failures affecting final-state achievement, TIER 2 (MODERATE) for procedural violations when the final state is correct, and TIER 3 (MINOR) for minor procedural issues not affecting the outcome. For Transition Spec Eval, TIER 1 denotes successful illegal actions, TIER 2 attempted violations that were later corrected, and TIER 3 attempted violations caught before execution. The Forbidden Edges Specification Eval is fully deterministic and scores 0 if any forbidden transition occurs, 100 otherwise.

The final score uses the paper’s gated-minimum aggregation strategy:

$S_{\mathrm{final} = \min \left( \min_{c \in C} (S_c), \frac{\sum_{i \in E} w_i S_i}{\sum_{i \in E} w_i} \right)$

where $C$ is the set of critical evaluators, $E$ is the set of all included evaluators, and $w_i$ is the assigned tier weight. The weighting scheme is critical = 3, important = 2, low priority = 1. The paper states that Predicted Plan Specification and Output Specification are always critical; Predicted Final State is dynamically promoted from low to critical when an outcome failure is detected; Transition Specification and Argument Specification are in the important tier. The point of the minimum gate is that strong secondary performance cannot mask failure on a critical procedural dimension.

4. Empirical evaluation on $\tau^2$-bench

The empirical study evaluates AgentPex on traces from $\tau^2$-bench across airline, retail, and telecom domains. The authors curated 50 traces per domain for each of Claude 3.5 Sonnet, GPT-4.1, and o4-mini, yielding 450 total traces. After filtering incomplete evaluator responses, the final dataset contains 424 clean traces: 140 Claude 3.5 Sonnet, 144 GPT-4.1, and 140 o4-mini. The dataset spans 93 tasks and uses 1,145 human-authored criteria from $\tau^2$-bench for reference outcome evaluation. All evaluated agent models were run at temperature 0, and the user simulator was always GPT-4.1; specification extraction and LLM-as-a-judge evaluation used gpt-5-mini-2025-08-07 (Sharma et al., 25 Mar 2026).

AgentPex broadly aligns with outcome metrics while still providing distinct signal. Using output_spec alone as a classifier of $\tau^2$0 failure, the mean output-spec score was 56.9 on $\tau^2$1-failed traces and 70.2 on $\tau^2$2-successful traces, with ROC-AUC = 0.680; at threshold < 65, it flagged 48% of $\tau^2$3-failed traces. The paper explicitly argues that this does not replace hand-authored criteria, especially for hidden database-state mismatches, but does provide useful supervision without manual labels.

The strongest quantitative result concerns hidden procedural violations among outcome-perfect traces. Among 58 Claude 3.5 Sonnet traces with perfect $\tau^2$4 reward, 48 traces (83%) still contained at least one procedural violation. This is the paper’s clearest evidence that outcome-only evaluation is insufficient.

The reported model-level averages show that AgentPex differentiates models that appear broadly similar under $\tau^2$5 reward alone.

Model	Overall Aggregate	Output Spec	Transition Spec
Claude 3.5 Sonnet	57.6	63.6	59.2
GPT-4.1	62.6	65.0	63.7
o4-mini	62.9	66.9	80.6

A second pattern is that Argument Groundedness is near ceiling across models—98.7 for Claude 3.5 Sonnet, 99.1 for GPT-4.1, and 98.1 for o4-mini—while Output Specification and Transition Specification are the dominant bottlenecks. This suggests that, in the evaluated setting, the most common failures are procedural and behavioral rather than simple argument hallucination.

5. Violation typology, model profiles, and case studies

The paper’s case studies make clear that AgentPex is intended to surface failures with operational relevance rather than merely stylistic deviations. In the motivating airline duplicate-cancellation trace, the customer asks the agent to identify schedule conflicts across seven reservations and cancel duplicate itineraries. Under $\tau^2$6-bench, the trace receives reward 1.0 because the right reservations are canceled and refunds are recorded. AgentPex nevertheless identifies four minor stylistic output violations, four transition violations where the agent includes user-facing text and a tool call in the same message, and a predicted-plan deviation because the agent fails to re-check reservation status after cancellation. The final-state evaluator still agrees that the database is correct, but the aggregate score falls to 85 rather than 100 (Sharma et al., 25 Mar 2026).

Two recurrent violation families are especially prominent. The first is simultaneous text and tool call, which appears 449 out of 723 instances across 128/140 Claude traces. This violates a system rule that tool calls and user-facing responses should not occur in the same message. The second is omitted calculation, with 11 instances in which the agent performs arithmetic in natural language instead of invoking the required calculate tool. Both are examples of failures that may preserve outcome correctness while degrading procedural reliability.

AgentPex also exposes sharply different model profiles. Claude 3.5 Sonnet had 449 simultaneous_call_text violations, compared with 29 for GPT-4.1 and 0 for o4-mini. Claude was also the only model with subjective comments in the trace set (7 instances) and had the highest number of skipped verifications (30 instances). GPT-4.1 was the only model performing multiple tool calls in a single turn (7 instances) and had the highest rates of fabricated information and providing unavailable information. o4-mini had the strongest workflow routing, with Transition Spec 80.6, but was the only model with skipped required authentication (7 instances). The paper’s point is not merely that one model is better overall, but that AgentPex reveals different deployment risks that outcome-only scoring largely flattens.

Domain analysis further shows that telecom is the hardest domain according to $\tau^2$7, and AgentPex’s predicted plan evaluator reflects that difficulty. This supports the interpretation that task complexity often manifests first as planning and procedural-compliance degradation, not only as endpoint failure.

6. Significance, limitations, and relation to adjacent work

AgentPex belongs to a broader movement toward making agent systems inspectable, controllable, and auditable, but it occupies a specific niche: trace-time procedural evaluation. This distinguishes it from workflow-specification systems such as AgentSPEX, which focuses on declarative YAML workflows with explicit control flow, modular structure, parallel execution, and explicit state management (Wang et al., 14 Apr 2026); from task-scoped authorization frameworks such as PAuth, which derive symbolic operation constraints and provenance-carrying envelopes for server-side authorization (Sharma et al., 17 Mar 2026); from protocol-security work such as AgentRFC, which proposes a six-layer Agent Protocol Stack and 11 security/completeness invariants for agent protocols (Zheng et al., 25 Mar 2026); and from black-box interpretability systems such as AgentXRay, which reconstruct editable surrogate workflows from input-output observations (Shi et al., 5 Feb 2026). AgentPex is narrower than those systems in scope, but more operationally focused on validating whether a concrete trace obeyed its own prompt-derived procedural specification.

The paper is explicit about its limitations. Empirical evaluation is confined to $\tau^2$8-bench; computational cost is substantial because the pipeline uses multiple LLM calls for extraction and evaluation; extraction can only recover explicit constraints; exact final-state prediction is harder in highly complex environments; the system detects failures but does not repair prompts or policies; extracted rules may overlap and double-penalize a single failure; and continuous deployment could produce alert fatigue unless warnings are prioritized and deduplicated (Sharma et al., 25 Mar 2026).

A final limitation is conceptual: AgentPex is strongest on prompt-derived procedural and behavioral constraints directly observable in traces. It is not presented as a replacement for environment-level ground truth, nor as a full formal verifier of hidden state changes. Its significance lies instead in adding a scalable compliance layer between hand-authored criteria and raw outcome metrics. In that role, AgentPex can function as continuous monitoring infrastructure, prompt-refinement feedback, model-selection support, and enterprise QA for systems where outcome correctness alone is too weak a standard.