Start by counting index reads. Classic RAG does one retrieval and one generation [10], so a request that touches the index twice is a bug you can go find. This design has two loops. AgenticRetrieveStream splits the question into sub-queries and retrieves iteratively from the managed datastore inside a single tool call [3], and the agent that made the call then checks whether the returned context is sufficient and calls again if it is not [6]. Reads per question is therefore a product: outer iterations times sub-queries per call [13]. The caller sets neither factor.
That is what breaks the panels people already built. A RAG relevance view is normally keyed on the user's query string joined to the chunks that came back. The string that actually reaches the index is now generated inside the service call [14], so your join key is synthetic and you did not write it.
`Type: MANAGED` is the line that settles the trade. Bedrock takes over ingestion, storage, indexing and retrieval, embedding and reranking run on service-managed models by default, and there is no vector database to provision, scale, or patch [9]. The earlier walkthrough in this series automated single-shot RAG against a self-managed vector store [11], which you sized and patched yourself. AWS states the operational consequence plainly: once an agent reasons and retrieves in a loop, you can no longer see what it did or whether the answer was any good [12].
The answer shipped here is instrumentation in the runtime itself, with every step auto-wrapped in OpenTelemetry spans from the first call [7], and token usage and metrics going to CloudWatch and X-Ray to feed on-demand and continuous evaluation [8]. That is the right place for it. An application cannot instrument a loop it does not run. What the published excerpt does not say is whether the sub-queries generated inside AgenticRetrieveStream surface as spans [16], and that one detail decides whether you can score relevance per hop or only per finished answer.
The routing demonstration gives the agent one retrieval tool per knowledge base and one clean choice, financial or weather [4]. Routing between finance and weather is the kind of test that passes. For the behaviour to transfer, your knowledge bases would have to be as separable as those two; if two of them hold last quarter's numbers, the tool-selection record becomes your only per-request evidence of which base answered. Each call is brokered by AgentCore Gateway over MCP [5], so that choice is at least visible at a boundary you can watch.
The excerpt also names seven observability layers without listing them, and the managed versus customer-managed comparison table is cut off before its rows [15], so the adoption cost is asserted rather than priced. In my context I would take the CloudFormation chain [1] and hold two figures as unknown until measured: reads per question, and router accuracy across corpora that overlap. Neither is recoverable after the fact from a log written for one hop.
