The easiest way to make an AI agent look ready is to score its final answer. Give it a task, grade the response, compare the number to last week’s model, and call the higher number progress.

That works until the agent is allowed to do real work.

Once an agent can search, retrieve records, call tools, change state, draft messages, escalate cases, or assemble reports, the final answer is only the last page of the story. The operating question is no longer “Was the answer plausible?” It is “What did the agent do to get there, what evidence did it rely on, which checks did it skip, and can we replay the same evaluation after the model or framework changes?”

That is why the next serious layer in agent evaluation is not another leaderboard. It is an evaluation contract.

Final-answer grading is too thin for agents

Traditional LLM evaluation assumes the model is mostly a text generator. You give it an input, receive an output, and grade the result. Agents break that shape. They are not just producing text; they are choosing tools, sequencing actions, reading intermediate state, interpreting retrieved evidence, and sometimes performing side effects.

A final answer can be correct for the wrong reason. It can be wrong after using the right evidence. It can pass a benchmark while violating the operating policy that would matter in production. It can look safe in a vendor dashboard but become impossible to compare once the team moves from one orchestration framework to another.

The August 2026 arXiv paper “The Evaluation Context Protocol (ECP): A Portable Contract for AI Agent Evaluation” frames this as an infrastructure problem. The authors argue that agent evaluation has to move beyond isolated model scoring toward the evaluation of autonomous agentic architectures. Their proposed ECP is early-stage, not a settled industry standard, but the direction is important: define a portable layer where an agent exposes user-visible output, tool calls, and evaluator-safe audit context so checks can run uniformly across frameworks.

That sounds dry. It is not. It is the difference between “we trust this agent because it got an 87” and “we know exactly which run artifacts must exist before this workflow can be accepted.”

A contract makes the run inspectable

A useful evaluation contract does not need to be grand. It needs to be explicit.

For a customer-support agent, the contract might say: here is the customer-visible answer, the records consulted, the tools called, the escalation decision, the policy checks, the cost and latency, the replay ID, and the reason a human was or was not pulled in.

For a coding agent, the same idea becomes: here is the patch, the files read, the commands executed, the tests run, the permission boundary, the errors encountered, and the evidence that the final claim matches the repository state.

For a clinical or scientific workflow, the standard is higher. The relevant question is not only whether the agent found an answer, but whether the answer deserves to be called a defensible claim.

That is what makes another August 2026 arXiv paper, “Bringing analytic rigor to agentic AI for science,” useful beyond its neuroimaging domain. The authors describe Brain Researcher, an agentic research harness that operates under rules for admissible analyses, required checks, and claim scope. In their reported benchmarks, the harness increased first-choice tool-selection accuracy across seven models from 23.3% without it to 93.6% with it, while verifiable grounding rose from 4.6% to 22.0%.

Those numbers should not be copy-pasted into a sales deck as universal proof that every agent becomes reliable with a harness. That would miss the point. The important lesson is structural: the workflow forced the agent to expose choices, constrain claims, weigh alternatives, and pass through review states such as accepted, qualified, revised, blocked, rejected, or deferred.

That is evaluation as an operating system, not evaluation as a scoreboard.

Portability matters because agents are not stable products yet

Most enterprise AI teams are still swapping pieces underneath the agent: model versions, retrieval pipelines, tool routers, orchestration frameworks, permission systems, memory stores, and monitoring vendors. If the evaluation evidence is trapped inside one stack’s trace format, every migration resets the trust story.

An evaluation contract gives the team a stable seam. The implementation can change, but the required evidence does not.

This is also where governance becomes practical. NIST’s AI Risk Management Framework emphasizes repeatable risk management, measurement, documentation, and lifecycle controls. For agents, those concepts are hard to operationalize if the only artifact is a chat transcript or a dashboard screenshot. A contract turns governance into something executable: a run either exposes the required fields or it does not; a policy check either passed with evidence or it did not; a human handoff either happened under the stated condition or it did not.

Anthropic’s “Building Effective AI Agents” makes a related engineering point from another angle: reliable agents are built through workflow design, tool use, feedback loops, and appropriate agentic complexity, not just by choosing the strongest model. An evaluation contract is how those workflow decisions become testable. It attaches acceptance criteria to the path the agent took, not only to the words it returned.

What to put in the first version

The first contract should be boring enough that the team actually uses it. Start with the fields that decide whether a run can be trusted: user request, normalized task type, final output, tool calls, retrieved evidence, policy checks, human review decisions, side effects, cost, latency, model version, framework version, replay ID, and evaluator version.

Then write checks against that contract. Did the agent cite evidence for every important factual claim? Did it call the required eligibility tool before producing a recommendation? Did it avoid side effects in dry-run mode? Did it escalate when confidence or policy required escalation? Did the tool arguments match the allowed scope?

This is where a contract becomes more valuable than a leaderboard. A leaderboard tells you which model won a static contest. A contract tells you whether a workflow obeyed the rules your business actually cares about.

The trap: fake certainty

There is one danger. Teams can turn evaluation contracts into another form of theater.

A contract is not a magic safety certificate. It does not prove that the agent is globally safe, fair, compliant, or correct. It proves that a run exposed agreed-upon evidence and passed agreed-upon checks. That is still a big improvement, but only if the checks are tied to real failure modes.

If the contract only captures what is easy to log, it will become bureaucracy. If it captures the decisions that would matter during an incident review, it becomes infrastructure.

The practical test is simple: when an agent fails, would this contract help the team understand the failure faster? Could another model be evaluated against the same expectations? Could a reviewer see whether the agent overclaimed, skipped a tool, used stale evidence, or performed an unauthorized side effect?

If not, the contract is decorative.

Before the next model bakeoff

The next time an enterprise team compares two agents, it should not only ask which one scored higher. It should ask which one produced better evidence.

Can both agents emit the same evaluation contract? Can the team replay the same checks? Can the business define “acceptable” in terms of required evidence, required checks, and allowed actions rather than vibes? Can the evaluation survive a model swap?

That is the boring, durable work between a demo and a dependable system.

Agents are becoming more capable. That makes the old evaluation habit more dangerous, not less. The more an agent can do, the less acceptable it is to judge only what it says at the end.

The future of agent evaluation is not a bigger scoreboard. It is a contract that says: show your work, expose your actions, ground your claims, and let the organization test the run against the rules it actually lives by.

Build AI Systems That Survive Contact With Real Work

We help teams turn AI research into practical automations, agent workflows, and operational systems that can be evaluated and improved.

Get the Field Guide — $10 →