AWS builds a nine-stage quality loop for production AI agents

Healthy infrastructure can hide a wrong answer

AWS has published a production evaluation framework built around a simple problem: an AI agent can stay available, respond quickly and still become less trustworthy. The company’s internal multi-agent sales system gives field teams conversational access to revenue, customer and performance data. Traditional telemetry showed the service was working, but pre-release evaluation found answers that could have damaged a customer conversation.

One response turned $410.08 of three-month service revenue into $410.08 million. Another confused sales revenue with a measure excluding adjustments, while a third invented an annual recurring revenue estimate absent from the data. The agent also presented its own calculations as sourced facts. Each response was fluent enough to pass a superficial review, showing why latency and error-rate dashboards cannot measure semantic correctness.

A coordinated release can create a quality gap

Agents depend on models, prompts, tools, permissions and frequently refreshed data. A change in any layer can alter behaviour even when the application code is untouched. AWS reports that a temporary mismatch between a data change, a tool update and the paired prompt reduced a pre-production pass rate from 78 per cent to 38 per cent. Nothing had to crash for quality to fall sharply.

That result supports release gates that understand a complete configuration rather than testing components in isolation. Versions of prompts, tools, model endpoints and data contracts should travel together, with an evaluation result attached to the exact bundle. If one part arrives early, the system should continue using the last verified combination or reduce its scope until the new set passes.

Nine stages turn testing into an operating loop

The AWS approach covers the lifecycle from development through live operation. It combines curated task sets, continuous-integration checks, regression gates, deployment validation, canary scoring, production sampling, drift detection, incident analysis and feedback into future tests. The purpose is not a one-off benchmark score but a loop that repeatedly asks whether each sub-agent and the assembled workflow still meet their contract.

Deterministic evaluators should check facts that can be computed directly, such as whether a number matches an authorised data source or a required citation exists. Model-based judges can assess relevance and explanation quality where fixed rules are insufficient. Human review remains necessary for calibration, high-impact failures and cases where business meaning cannot be compressed into a single automated score.

AgentCore is one part of the assurance stack

AWS uses AgentCore Evaluations as the connective layer, with Bedrock Guardrails for safety, CloudWatch for metrics and tracing, S3 and Redshift for evaluation evidence, Amazon Quick for dashboards and Lambda for custom checks. The architecture matters because quality evidence has to survive beyond the immediate run. Operators need to trace a failed answer back to its prompt, data, tool call and evaluator version.

The evaluation store should be governed like other sensitive analytics. Sales and customer traces can contain commercial information and role-scoped data. Access controls, retention and redaction need to cover prompts, retrieved records and grader outputs. A quality program that gathers unrestricted production conversations can create a new privacy and security problem while trying to solve an accuracy problem.

Metrics should reflect business harm

An aggregate pass rate can hide failure in the tasks that matter most. Teams should slice results by sub-agent, user role, data source and consequence. A small error in formatting may be tolerable; a thousand-fold revenue inflation is not. Severity-weighted measures and hard invariants make that distinction visible and keep easy requests from masking deterioration in high-stakes workflows.

AWS’s framework is valuable because it comes from a system serving its own field organisation. The lesson generalises: production agents require continuous semantic monitoring, not just uptime. Organisations should start with a fixed regression set, record the exact configuration behind every result and turn confirmed incidents into tests. Trust grows when a system can prove what changed, catch quiet regressions and limit the reach of an agent whose quality falls.

What to watch next

A practical rollout can begin smaller than nine mature stages. Teams can first define five high-impact tasks, capture correct source-backed answers and run them on every change. They can then add canary traffic, production sampling and drift alarms as evidence accumulates. What matters is that failures feed the system: an incident should create a reproducible case, a named owner and a verified control. Without that loop, dashboards may describe quality without improving it.

Implementation detail

Evaluation independence is another safeguard. The team that builds an agent may unintentionally design tests around its strengths or accept explanations it recognises. Periodic review by domain owners, risk staff and representative users can challenge the scoring rules and add cases the development team overlooked. Grader models also need monitoring: a changed judge can move the reported pass rate even when the agent is identical. Frozen calibration examples and occasional double-blind human scoring help separate real improvement from measurement drift.