Agent Evals in CI: Regression Gates for Trajectories and Tool Calls
Agents fail deterministic tests because the same input yields different trajectories. This article shows how to gate regressions in CI in 2026: assertions on tool calls and trajectories, offline datasets with reference outputs, online LLM judges on production traces, cost tracking per run, and eval-driven development as the working method.
Why agents break classical CI
An agent is a loop: a model receives a task, calls tools, observes results, and decides the next step. The same input rarely produces the same path twice. Classical tests assert one expected output for one input. That contract does not hold for agents. A prompt edit that fixes one scenario silently degrades three others, and no unit test notices.
The scale of the problem is measured. τ-bench (June 2024) ran function-calling agents against simulated users and real APIs. GPT-4o solved about 61 percent of retail tasks on a single trial. Run the same task eight times and require all eight to succeed — pass^8 — and the rate drops below 25 percent. Reliability, not peak capability, is the deficit. CI has to measure it.
The trajectory is the unit under test
A trajectory is the sequence of tool calls an agent makes, including the arguments it generates, plus the state it leaves behind — files, database rows, messages. Evals assert against this sequence, not only the final answer: was the right tool called, with the right arguments, before the side effect happened?
Two granularities work in practice. Single-step evals freeze the agent after one decision and check it — cheap, fast, precise; LangChain reported in December 2025 that about half of their agent test cases were single-step. Full-turn evals run the whole loop and score final response, trajectory, and state changes together.
One caution: strict sequence matching over-constrains. Agents reach correct results through valid paths the test author did not anticipate. Reserve exact-order assertions for cases where order is a correctness or safety requirement; elsewhere assert that a tool was called, not when. Open-source evaluators such as agentevals (February 2025) support both modes: strict trajectory matching and judge-based trajectory scoring.
Regression gates on every pull request
A gate only works if the team does not route around it, and teams route around slow gates. An LLM-judge suite that takes ten minutes per push gets marked non-required within weeks. We therefore split the gate into tiers ordered by latency and cost: deterministic checks run on every commit, judge-based scoring runs on merge, and the full dataset runs nightly.
Gate on deltas, not absolutes. A suite that drops from 96 to 91 percent while still clearing a 90 percent threshold is a regression in progress. Store the baseline score from the main branch, compare each pull request against it, and block on a defined drop. Repeat non-deterministic cases — three runs, majority pass — to separate agent regressions from sampling noise.
| Tier | Trigger | Checks | Merge gate |
|---|---|---|---|
| Deterministic | Every commit | Schema validity, expected tool calls, argument checks, cost ceilings | Yes — 100 percent required |
| LLM-as-judge | Merge to main | Rubric scores, refusal behavior, trajectory quality | Yes — threshold with repeat runs |
| Full regression | Nightly | Complete dataset, cross-model comparison, cost audit | No — alert only |
Offline datasets and online judges
Offline evals run against a curated dataset with reference outputs. Correctness is defined per case; deterministic graders check it. This is where regression gating lives. The dataset does not need to be large: Anthropic's guidance from January 2026 is that 20 to 50 tasks drawn from real failures are a sufficient start, because early changes have large effect sizes.
Offline datasets cannot anticipate real users. Online judges close that gap: an LLM scores sampled production traces against a rubric — reference-free, continuous, drift-sensitive. LangSmith shipped multi-turn evals for whole conversations in October 2025; Langfuse runs judge pipelines over stored traces. The two feed each other: a trace the online judge flags becomes an offline dataset entry, and the bug it exposed stays fixed.
Judges are measurement instruments and need calibration. Score at temperature zero, write rubrics that name explicit conditions, and check judge output against human labels before trusting it. An uncalibrated judge produces a number, not a measurement — and judges drift just like the agents they score.
Cost per run as a first-class metric
Agent evals consume real tokens. The τ-bench authors reported roughly $0.61 per task and trial — $0.38 for the agent, $0.23 for the simulated user — with 96 percent of the agent's cost in input tokens. A suite of 100 cases with three repeats is a measurable line item on every pull request. Track it per run, or the suite gets budget-cut before the quarter closes.
Token accounting is standardizing; cost accounting is not. The OpenTelemetry GenAI semantic conventions define token-usage attributes and metrics (gen_ai.usage.input_tokens, gen_ai.client.token.usage), still in Development status as of February 2026. A standardized cost metric does not exist — you compute cost from token counts and a maintained price table. Then use it: a change that doubles tokens per task is a regression even when quality scores hold. Cost ceilings belong in the deterministic tier.
Eval-driven development
Eval-driven development inverts the order: write the eval before the capability. The suite starts at a low pass rate and defines the hill to climb. When a new model ships, one suite run shows what improved and what broke. Anthropic describes building features that work "well enough" today as bets on future models — capability evals make the bet measurable.
Two disciplines keep the loop honest. First, environment hygiene: every trial starts from a clean state, and external APIs are recorded and replayed, because shared state produces flaky evals that measure nothing. Second, read the transcripts. A failing grade does not distinguish an agent mistake from a grader rejecting a valid solution. Only the transcript does.
Outlook from February 2026
Three developments look likely from here. Trajectory data becomes portable: OpenTelemetry's GenAI conventions already model tool-call spans, and MCP standardizes the tool interface, so eval harnesses will consume traces from any runtime. Cost enters the conventions as a first-class signal. And judge calibration moves from ad-hoc scripts into the platforms.
The durable asset will not be the public benchmark — those saturate. It will be the private, product-specific suite that grows with every production failure. We treat that suite as a deliverable with the same status as the agent itself: versioned next to the code, gating every merge, owned by whoever owns the spec. Agents will keep changing models; the evals carry the knowledge across.
Sources
- Yao et al.: τ-bench — A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv, 17 Jun 2024)
- Anthropic Engineering: Demystifying evals for AI agents (9 Jan 2026)
- LangChain Blog: Evaluating Deep Agents — Our Learnings (3 Dec 2025)
- LangChain Blog: Quickly Start Evaluating LLMs With OpenEvals (26 Feb 2025)
- LangChain Blog: Insights Agent and Multi-turn Evals in LangSmith (23 Oct 2025)
