An AI agent can respond quickly and still produce an answer that is unsuitable for business use. Monitoring may look healthy while the meaning of a number in the answer is wrong. That gap needs attention both before release and during operation.

The AgentCore evaluation framework published by AWS on October 16, 2026 follows this problem across development and production. Its nine stages connect a definition of quality, tests of proposed changes, and production failures that become future test cases.

But does passing a set of familiar questions justify a production rollout? The answer depends on how evaluators, test data, and execution histories work together.

Measure correctness across the customer, period, and unit

In a pre-launch evaluation of an AWS sales assistant, an agent described $410.08as$410.08 million. Successful execution did not preserve the business meaning. Comparing the digits alone would miss the problem.

A practical design response is to define correctness through the customer, reporting period, metric, currency, and unit, rather than through fluent wording. This is a suggested way to apply the case study; the required fields depend on the job the agent performs.

AgentCore offers built-in LLM judges and custom evaluators. Custom evaluation can use a tailored LLM rubric or code running in AWS Lambda, as described in the evaluator documentation.

A customer ID or established amount can be checked in code. Whether an explanation addresses a question is a candidate for a written rubric assessed by an LLM. Keeping factual agreement and usefulness visible separately, before combining scores, makes it easier to decide what needs fixing.

Replay known cases to separate tool failures from answer-generation failures

Once criteria are defined, they need repeatable questions and expected outcomes. This reference collection is a golden set. The AWS case study evaluates tools, individual agents, and interactions among agents.

If a tool resolves the wrong customer, fluent downstream prose still produces a wrong answer. Conversely, correct retrieved data can be misinterpreted during answer generation. Expectations at intermediate boundaries can therefore help narrow the cause beyond a final pass or fail.

For its release gate, the case study freezes validated tool responses and replays them to candidates. This reduces variation from changing external data and supports comparison using the same evidence. However, fixed responses cannot establish the latency of a real dependency or behavior after its data changes.

A practical adoption sequence is to run critical known cases on changes and broaden coverage before release. Acceptance criteria should also include latency and cost limits. A higher average score, for example, is not sufficient justification if failures increase for a particular customer group.

Evaluate unfamiliar production questions without assuming reference answers exist

Passing fixed questions does not establish how users will phrase real requests. Reference data can also change without an application deployment. Release tests and ongoing evaluation address different sources of change.

AgentCore’s evaluation types differ in how interactions are selected and processed.

Evaluation type	Selection and execution	Operational use
On-demand	Evaluate selected execution histories	Compare changes or investigate an unsuccessful response
Batch	Evaluate multiple CloudWatch Logs sessions in an asynchronous job	Regression assessment across a collection or periodic quality reviews
Online	Sample and filter production sessions	Detect quality changes involving inputs absent from tests

Evaluators are not interchangeable across these modes without restrictions. Custom evaluators using ground-truth placeholders for expected answers, assertions, or tool trajectories cannot be configured for online evaluation, because those references are unavailable for live requests. The custom evaluator documentation states this limitation.

Results from reference-based tests and live traffic therefore need distinguishable populations and scoring conditions. Choose sampling rates according to the failures you want to detect and the volume of evaluation. A score cannot establish the absence of failures outside the sample.

Connect CloudWatch histories to scores, including missing evaluations

A low score raises another question: what caused it? Investigation needs a path back through the request, tool calls, returned information, and final answer. Collecting execution history and scoring that history must be connected before the result becomes useful for diagnosis.

The on-demand setup guide requires appropriate IAM and model invocation permissions, CloudWatch Transaction Search, and supported instrumentation. Its Python walkthrough assumes Python 3.10 or later and the ADOT library. Log ingestion takes time, so an empty history immediately after invocation says nothing about answer quality.

Evaluation responses can also contain both successes and failures, including model timeouts. Displaying only the average of successfully scored results obscures whether the intended workload was evaluated. The same guide describes partial failures and their error information.

One implementation approach is to display intended evaluations, completed evaluations, and scoring errors alongside quality scores. A low score then initiates answer investigation, while missing scores initiate evaluation-pipeline investigation. Each signal leads to a different next action.

Turn production failures into tests that can block the next release

Fixing a cause without retaining a reproduction leaves room for the same failure to return. The AWS framework includes adding low-scoring interactions to the reference collection and evaluating subsequent improvements.

On the product side, AgentCore optimization uses traces and a target evaluator to propose system-prompt or tool-description changes. It also provides A/B testing through Gateway traffic splitting and online scoring. A recommendation becomes a candidate for validation, rather than proof of improvement.

A manageable starting point is one business fact that must be correct: define its expected result, implement its evaluation, and establish that a failure blocks release. Then connect production histories and fixes to that process.

Passing familiar questions alone cannot establish ongoing production quality. Tests that block regressions and evaluations that discover new failures need to feed each other. That connection makes correctness something the team can keep assessing as the agent and its operating conditions change.

Source

• Title: Building trust in AI agents: A production-ready evaluation framework with Amazon Bedrock AgentCore
• URL: https://aws.amazon.com/blogs/machine-learning/building-trust-in-ai-agents-a-production-ready-evaluation-framework-with-amazon-bedrock-agentcore/