Every team deploying agents hits the same question: how do you know it is doing the right thing? Not just producing text that sounds correct, but actually completing the task, using the right tools, respecting permissions, and leaving the system in the right state. That is what an evaluation framework defines.

As of September 2026, the vocabulary is settling: Anthropic published a detailed eval framework for agents (Anthropic Engineering, 2026). DeepEval and Braintrust both position themselves as evaluation platforms rather than agent platforms. Google Cloud added production-grade evaluation to its agent platform (Nov 2025). The gap is no longer whether evaluation exists — it is whether your framework matches your agent’s actual behavior.

A builder in an AI community forum described the framework as a harness: “the system that enables a model to act as an agent: it processes inputs, orchestrates tool calls, and returns results. When we evaluate an agent, we’re evaluating the harness and the model working together.” That distinction matters. Evaluating the model alone misses half the failure surface.

The five patterns

No single framework covers every quality dimension. Production agents need a stack, not a single score. Here are the five patterns, ordered from most deterministic to most flexible.

PatternWhat it checksWhen it runsExample
Deterministic gatesHard failures: tests, type checks, security patterns, state contractsBefore deployment (CI gate); optionally at runtime“Every generate_invoice() call must include audit_event: 'invoice_generated' in the log”
LLM rubricQuality of reasoning, completeness, tone, accuracyAfter each run; periodic batch grading“Rate the agent’s explanation on clarity (1-5) and factual accuracy (1-5)”
Static analysisCode quality, lint errors, import hygiene, test coverageBefore deployment; continuousruff, mypy, bandit checks on agent output files
State contractsSystem state after agent action: database updates, file writes, permission grantsAfter agent completes; verified against reference state“After create_user(), the user row exists and no duplicate email exists”
Transcript metricsBehavioral signals: number of turns, tool calls, token usage, latency, retry patternsDuring and after every run; tracked over time“Average 3.2 turns per request this week, up from 2.1 last week”

Each layer answers a different question. Gates ask: did it break anything? Rubrics ask: did it do it well? Static checks ask: is the code safe? State contracts ask: is the world in the right shape? Transcripts ask: is it behaving differently over time?

If you only run rubrics, you miss security failures. If you only run gates, you miss quality degradation. A production framework needs at least three layers running continuously.

Why most agent demos fail in procurement

The failure mode is not bad reasoning. It is missing evidence. A procurement review asks: how do you know the agent won’t leak data, call the wrong API, or corrupt a record? The answer “it looks fine” does not pass.

An evaluation framework solves this by making quality verifiable. A gate that checks security_logs: {event_type: "auth_blocked"} produces evidence a security team can read. A rubric score of 4.2 out of 5 is a number that can trend. A state contract that verifies an audit entry exists is a binary fact.

A framework also protects the agent from itself. Without gates, the agent can succeed on one task and silently corrupt the database on another. With gates, the failure is caught before deployment. With transcript tracking, you see the corruption pattern before it repeats.

The harness is the evaluation target

When evaluating an agent, you are evaluating two things at once: the model (does it understand the task?) and the harness (does it route inputs correctly, manage context, call tools in the right order, and handle errors?). The framework must test both.

The Anthropic framework (2026) explicitly separates graders by type: deterministic_tests (hard gates), llm_rubric (flexible quality), static_analysis (code hygiene), state_check (world verification), tool_calls (behavior tracking), transcript (interaction metrics), and latency (speed). Each grader produces a separate score. No single number captures the agent’s quality.

This design choice is deliberate. A single score hides trade-offs: an agent that is fast but unreliable looks the same as one that is slow but perfect. Separate graders let you decide which dimension matters for which deployment.

Deterministic gates come first

Before any rubric or scoring, define the hard failures. These are the cases where the agent must stop, not just score poorly.

Examples from production agent deployments:

  • Authentication bypass: any attempt to reach a protected endpoint without valid tokens must be rejected by the harness, not just logged.
  • Data leakage: any response that includes content outside the caller’s permission scope must trigger an immediate failure, not a low rubric score.
  • State corruption: any action that writes to the wrong table, updates the wrong record, or deletes data that should be preserved must fail the state contract.

These are not quality judgments. They are contracts. The framework defines them as deterministic tests with explicit inputs and expected outputs, exactly as Anthropic’s framework describes them.

Building a framework for your team

You do not need every vendor’s platform. You need a framework that matches your agent’s behavior. Start with three questions:

  1. What are the hard failures that must never pass? (gates)
  2. What does success look like for the tasks the agent handles? (rubric)
  3. What state must the system be in after the agent runs? (contract)

Then add transcript tracking to see if the agent’s behavior is drifting over time. A framework that takes one week to build and runs for months is more valuable than a perfect framework that takes six months to design.

Further reading