Agent Evals Stopped Grading Answers and Started Grading Trajectories

The unit of analysis changed

For two years, evaluating an LLM feature meant grading a single input-output pair: run the prompt, check the answer, move on. That model is dead for agents, and the eval vendors spent the last quarter rebuilding around a different unit entirely — the trajectory. An agent produces a chain of reasoning, tool calls, and intermediate results that unfolds over many turns, and two runs of the same task can take completely different paths and both be correct, or both be wrong for entirely different reasons [2]. Once your "agent" is really a supply chain of MCP servers, retrieved context, and tool outputs you don't control, "just evaluate the model" stops being the right unit of analysis — you're evaluating a supply chain [5].

OpenAI's exit from the evals business

The clearest signal that the ground shifted: OpenAI announced on June 3, 2026 that its hosted Evals product goes read-only on October 31 and shuts down entirely on November 30, with migration pointed at Promptfoo [1] — the same Promptfoo that OpenAI itself acquired in March for a reported $86M, absorbing the red-team eval leader used by more than a quarter of the Fortune 500 [3]. The open-source Evals repo stays usable, but it was only ever built for registry-based, reproducible grading of prompt chains via a Completion Function Protocol — not trajectory scoring [1]. That gap is exactly why Braintrust closed an $80M Series B at an $800M valuation in February, and why DeepEval, Inspect AI, LangSmith, and Arize Phoenix all shipped agent-specific trajectory features this spring [3]. The commercial eval market didn't grow because founders got excited about testing — it consolidated because the old grading unit (one input, one output) stopped mapping to what agents actually do.

What trajectory scoring actually checks

Strip away the vendor marketing and the eval frameworks converging in 2026 check a consistent set of things a single-output metric can't see: did the agent call the right tools, with the right arguments, in a sane number of steps; did it loop, backtrack, or wander off; did it recover cleanly from a tool error instead of hallucinating a result; and did it stay grounded in what the tools actually returned rather than what it assumed they'd return [2]. None of that shows up if you're only diffing a final answer against a reference string.

The practical pattern teams are converging on: replay production traces with synthetic tool failures injected — one bucket per tool, one row per HTTP error class the endpoint actually returns (400, 401, 403, 429, 5xx), plus empty-result and partial-result rows — then gate CI on per-bucket recovery rates rather than a single aggregate pass rate. Score the trajectory shape itself: no repeated calls with identical arguments, no dead-end branches that never rejoin the goal, and step count roughly proportional to task complexity.

Policy-driven evals, courtesy of Microsoft

Microsoft's contribution at Build 2026 attacks a different failure mode: policies that exist as prose and never become tests. ASSERT (Adaptive Spec-driven Scoring for Evaluation and Regression Testing) converts plain-English behavior requirements — "the agent must not reveal PII" — into scored, executable test suites through a four-stage pipeline: systematization, taxonomization, test-set generation, and inference scoring, with its LLM-judge approach reaching 80-90% agreement with human annotators. It's MIT-licensed and framework-agnostic across LangChain, CrewAI, AutoGen, and the OpenAI Agents SDK, paired with an Agent Control Specification that places deterministic guardrails at five runtime checkpoints — input, model, state, tool execution, and output [4]. The pitch is blunt: a policy document with zero enforcement weight isn't a control, it's a wish. ASSERT and Rubric (Foundry's new context-aware evaluator generator) are Microsoft's bet that eval criteria should come from your agent's actual spec, not a generic benchmark someone else wrote.

An implementation sketch

Here's the shape a trajectory-plus-provenance test takes in practice, using pytest-style assertions against a captured agent run:

def test_refund_agent_trajectory(agent_run):
    trace = agent_run.trace

    # Tool correctness: right tools, right args, right order
    tool_calls = [c.name for c in trace.tool_calls]
    assert tool_calls == ["lookup_order", "check_refund_policy", "issue_refund"]
    assert trace.tool_calls[0].args["order_id"] == agent_run.input["order_id"]

    # No loops, no repeated identical calls
    seen = set()
    for call in trace.tool_calls:
        key = (call.name, frozenset(call.args.items()))
        assert key not in seen, f"repeated call: {call.name}"
        seen.add(key)

    # Error recovery: injected 429 on issue_refund should trigger backoff, not hallucination
    if trace.tool_errors:
        assert trace.final_output.status != "refund_confirmed"
        assert trace.tool_calls[-1].name == "retry_issue_refund"

    # Provenance: every claim in the final answer traces back to a tool result
    assert trace.is_grounded(trace.final_output.text)

    # Policy: never surface raw card numbers regardless of task success
    assert not contains_pan(trace.final_output.text)

This isn't exotic — it's pytest with agent-aware assertions, which is exactly why DeepEval's pytest-native ergonomics have become the default entry point for teams that don't want a new DSL just to test an agent [3].

The law caught up faster than anyone expected

The EU's Digital Omnibus pushed the AI Act's high-risk obligations from August 2026 to December 2027, but the substance didn't change — Article 13 still requires high-risk systems to produce outputs deployers can interpret, and Articles 12 and 19 require automatically generated logs. In agent terms, that's replayable provenance for every request-tool-response-outcome chain, by law rather than by preference, with penalties up to €35 million or 7% of global turnover [5]. Gartner's estimate that over 40% of agentic projects get cancelled by 2027, mostly over cost and weak controls, is the commercial version of the same warning [5]. Golden trajectories and tool-contract tests aren't nice-to-haves anymore; they're the artifact an auditor or a board member is eventually going to ask for.

Avant Concepts take

We've said it before and this quarter proved it again: most "agent" failures teams bring us aren't model failures, they're missing eval harnesses. The scramble around OpenAI Evals sunsetting, Braintrust's valuation, and Microsoft shipping ASSERT is really one story — the industry finally admitting that grading a final answer was never enough, and everyone is racing to own the trajectory-and-provenance layer instead. Our take: don't build this yourself. Wire DeepEval or Promptfoo into CI for pytest-native trajectory assertions, point production traces at Phoenix or Langfuse, and reserve ASSERT-style policy tests for the handful of hard constraints (PII, refund limits, compliance language) that actually need spec-driven enforcement — that's the build-vs-buy call every time. But don't outsource the golden trajectory set itself; that's your product knowledge, and no vendor can write it for you. If you can't replay why an agent called the tool it called, you don't have an agent in production — you have an unmonitored liability with a chat interface.