AWS shows how 100% retrieval precision can hide an AI agent's failure

Your agent confidently answers employees' questions, provides links, and passes retrieval checks. Ready to ship? In an AWS example, retrieved chunks scored 100% precision on one metric, yet lacked the information needed to answer a question about sick leave. After a prompt revision, the answer got even worse. The practical lesson: before changing the instructions again, check whether the documents contain the answer at all.

AWS described the case in an article about the Agent Development Lifecycle, or Agent DLC. This approach to agent development has teams define acceptance criteria in advance, test every change, and feed problems discovered in production back into the test suite. For developers, its value lies in a concrete way to identify which component needs fixing.

Why 100% in the report was not enough

The authors built an HR information agent and tested it on three questions. Their measurements included how well sources supported the agent's claims, how useful the retrieved chunks were, and whether they answered every part of the user's question.

Imagine an employee asking when they need to submit a medical certificate. Retrieval returns a general leave policy that mentions sick leave in passing. The chunk is relevant to the topic and receives a positive score. But it contains no deadline for submitting the certificate. This is precisely the distinction that precision measured at the whole-chunk level obscured.

For the problematic question, that precision reached 100%, while useful facts accounted for 9% of the retrieved material and subquestion coverage was 0%. The authors then checked the source documents: the corpus did indeed lack a separate sick leave policy.

The team changed only the system prompt, requiring the agent to rely strictly on sources, ignore irrelevant material, and stay on point. For the question about employee evaluations, the share of supported claims rose from 83% to 87%. For the sick leave question, it fell from 39% to 31%. Instructions could not supply missing information. The next step should have been to expand the knowledge base and check retrieval.

What to test before release

In Agent DLC, the starting point is an agreed set of criteria, thresholds, and test cases. For a support agent, for example, teams need to define which claims require citations, when the agent should acknowledge missing information, and which customer details it is allowed to use.

The team then evaluates a version, traces the path to the error, changes one component, and repeats the evaluation under the same rules. This sequence helps connect a result to a specific change. If the prompt is rewritten, the knowledge base updated, and the criteria changed all at once, explaining the shift in scores becomes much harder.

The recommendation is to run each test case several times: the same request can lead an agent to produce different answers and make different tool calls. The evaluators themselves also need testing. If another model judges the answers, its scores should be compared with examples reviewed by humans, and their variability measured.

Criteria carry different weight. Violating a prohibition on disclosing someone else's data blocks release. Answer quality can be governed by a threshold for successful runs. Some metrics can initially be monitored until the team is confident it can measure them reliably.

The limits of the experiment's findings

A high score for source support does not guarantee an acceptable answer either. In one case, the agent claimed to know the user's preferred contact method. It had no user profile: the model combined information from different documents and presented it as a personal fact. The answer scored 90% for source support, so fabrications of this kind require a separate check.

The study's scope is modest: three questions in a demonstration implementation. It is neither a customer result nor proof that the approach is ready for every production deployment. The authors also warn that scores vary between runs.

A practical step for teams is to take real failures from their own agent and add them to the test suite. For each case, establish whether the sources were sufficient, whether tools were used correctly, and whether fabricated information appeared. Then fix the identified cause and repeat the runs. Tests should also run on a schedule: an external model, API, or knowledge base can change without a single commit in your repository.