AWS says its sales AI misstated $410.08 as $410.08 million before launch

AWS’s internal sales AI returned answers while its monitoring stayed green—but some answers were badly wrong. In an October 16 case study, AWS disclosed that one agent turned $410.08 in customer revenue into $410.08 million before launch. The company detailed a nine-stage evaluation framework designed to catch errors that ordinary system-health checks missed.

A successful response, an unreliable number

The revenue error covered three months of one customer’s spending on a service. AWS says its Customer Insights Agent also labeled Sales Revenue as Sales Revenue excluding Adjustments, supplied an annual recurring revenue estimate absent from the data, and presented its own calculations as sourced facts. The company says it caught these errors before launch.

The distinction matters for the work this system supports. AWS’s Sales, Marketing, and Global Services Operations team developed it for field sales worldwide. Sellers use its answers to prepare for customer meetings and plan account strategy. Leaders use the same system for business reviews, including weekly reviews that would otherwise require manual report preparation.

Users ask business questions in plain English through Amazon Quick, with answers restricted by territory and role. Behind that interface, specialized agents handle performance analysis, customer intelligence and database queries. The Data Insights Agent translates questions into SQL, the language used to query structured databases.

When related updates arrive apart

Another disclosed failure involved release coordination rather than an isolated answer. AWS says a data change, a tool change and a corresponding prompt update can leave the system temporarily mismatched if they are intended to ship together but arrive separately. In one pre-production test, that mismatch alone sharply reduced the evaluation pass rate.

The mismatch penalty

Evaluation pass rate

78%→38%

%

AWS attributes this decline in one pre-production test to the window when coordinated changes were mismatched.

Quality can also change without a software release: upstream data pipelines refresh weekly. AWS describes the evaluation framework as a way to check answers before releases and continuously in production, then trace failures to the data, prompt or agent code. Its scope extends beyond whether a request completed quickly or returned an error.

Nine stages, three layers of checks

The framework uses Amazon Bedrock AgentCore Evaluations across the development and production lifecycle. AWS organizes its nine stages around distinct questions, starting with a definition of acceptable behavior and ending with feedback intended to improve the system.

• Define and compare: establish what good performance means, then experiment to determine which version performs better.
• Check changes and deployment: test for regressions when code is merged, apply release gates, and use canary checks to catch silent failures.
• Challenge and maintain: run adversarial tests, detect quality drift, monitor live behavior and feed findings back into improvement.

Those checks apply at three levels: each tool, each individual agent and the coordination between agents. Each level has its own reference test set, evaluators and criteria for moving forward. AWS says evaluating an agent alone misses both weaknesses in its underlying tools and failures in routing or combining work across agents.

The starting point is a business outcome, not a model score. For sellers, AWS maps accurate account intelligence to measures such as identifying the right customer and grounding answers in data. Leadership review reliability maps to accuracy and response coverage. Teams also define latency targets, cost-per-query budgets, safety policies and alarm conditions.

AWS groups evaluation into safety, quality, performance, cost and operational control, and says safety remains the first priority. Its accuracy rule is strict: any one defined failure type makes a response inaccurate. Examples include returning the wrong metric or labeling data with the wrong time period—even when the customer and other details are correct.