Agent reliability starts with the result the system leaves behind

Anthropic’s January 9, 2026 engineering article on agent evaluations made a simple distinction with large consequences: a transcript saying a flight was booked is different from a reservation actually existing in the database. The company argued that evaluating an agent means evaluating the model together with its harness and environment. That moves reliability beyond the fluency of a final answer and toward the state the system leaves behind. Anthropic agent evaluation engineering.

A single successful run is a poor basis for granting an agent authority. The same request may produce a different path on the next attempt, especially when tools, users, and incomplete information interact. Reliability asks a more demanding question: how consistently does the system reach the correct outcome while respecting the same constraints?

The τ-bench paper, submitted June 17, 2024, introduced repeated-trial evaluation of agents interacting with tools and simulated users under domain policies. Its results highlighted inconsistency in the systems tested. Those original rates should not be carried forward as measurements of current products. τ-bench paper.

Repeat the awkward cases

Our recommendation is to repeat the cases that stress the workflow: an ambiguous request, a policy exception, a failed tool response, or a user who changes their mind. Report both successful completion and rule violations. An agent that eventually gets the answer right may still be unsuitable if some attempts take an unauthorized action along the way.

Reflexion, submitted March 20, 2023, explored using verbal feedback and memory to improve later attempts without updating model weights. The research suggests one route to adaptation, while leaving the quality of feedback as an important part of the design. Reflexion paper.

Keep the denominator

We would publish the number of attempts behind every internal success claim and preserve failed traces for review. Improvement should be demonstrated on fresh cases, not only on a remembered example. This shifts the conversation from a compelling demo to an operating record. Greater autonomy should follow repeated evidence that the system knows when to proceed, when to retry, and when to hand the task back.

The failure can be in the test itself

The same account described an Opus 4.5 attempt that found a policy loophole in a flight-booking task and failed the written evaluation despite producing a better outcome for the user. It also discussed separate quality and regression suites at Descript and browser-based application checks at Bolt. These are vendor-reported examples, but they expose a real methodological issue: a rigid expected path can reject a valid solution, while a permissive language judge can accept a convincing failure. Anthropic agent evaluation engineering.

Infrastructure changes the score

In a February 5, 2026 study, Anthropic varied the resources available to coding agents. Its Terminal-Bench experiments found that additional memory headroom reduced infrastructure errors, while more generous allocations could also change which solution strategies succeeded. The company separately ran a SWE-bench comparison across 227 problems and ten samples per problem, reporting a smaller score increase with more RAM. These results concern the studied configurations, not a universal adjustment to every published leaderboard. Anthropic infrastructure noise study.

Reliability is a property of the whole attempt

The connection between these findings is more useful than a single headline percentage. An agent can fail because it misunderstood the task, because it made the wrong tool call, because the tool failed, or because the environment did not have enough resources. A user experiences all four as an unsuccessful attempt. A researcher trying to improve the model needs to distinguish them.

The reverse problem also matters. A generous environment can rescue an inefficient strategy. That may be acceptable for a premium research task and unacceptable for a low-cost support workflow. Calling both results “model accuracy” obscures the operational choice. The relevant system includes time, compute, tool access, and the way success is recognized. Changing those conditions changes the claim being made.

Repeated work reveals what a demonstration hides

The older tau-bench and Reflexion research discussed below approaches reliability from repeated interaction and feedback. The point is not that a historical score predicts a current product. It is that a single successful run reveals little about a system expected to handle the same class of work thousands of times. Repetition exposes unstable behavior, while a record of intermediate actions helps distinguish recovery from luck.

This is particularly important for agents that modify persistent systems. A retry may be harmless when searching the web and harmful when submitting an order twice. A final answer can omit that distinction entirely. The outcome must include both whether the intended change occurred and whether unwanted changes accompanied it.

For readers comparing agents, the practical implication is that a compelling demonstration is the beginning of evidence. More meaningful reporting identifies the task set, the environment, the number of attempts, and the final states examined. It also states what the evaluation cannot see. Anthropic’s accounts are useful because they make several hidden variables visible. They do not resolve every measurement problem, but they explain why reliable autonomy will be established by reproducible system behavior rather than by the confidence of a model’s closing sentence.

The research behind the release

Tau-bench’s June 2024 experiments combined policy-following, tool use, and simulated user conversations, then evaluated the resulting database state. Its repeated-success measure made inconsistency visible. The point for current products is methodological rather than numerical: a historical benchmark score cannot represent a model released years later, but the distinction between occasional success and dependable repetition remains essential. A customer support action may look routine in one demonstration and become difficult when information is missing or the user changes a request. Reliability reporting needs to preserve those conditions rather than average them into an unexplained headline. Original research paper.