A lot of enterprise AI programs are stuck between a working pilot and a system anyone will sign off on. McKinsey's 2026 State of AI survey has the share of $1 billion-plus companies scaling agents in at least one function at 40 percent, up from 27 percent a year earlier. That's real movement, but it means most big companies are still somewhere between the pilot and the payoff.
Throughout this guide we'll come back to a regional health plan with about 600,000 members. Every prior-authorization request that lands there gets checked by a nurse against roughly 400 clinical policy documents, the member's eligibility in the core admin system, past claims, and the provider directory, and the policies are updated monthly. A standard RAG assistant can tell a nurse what the knee MRI policy says, but what the nurses actually want is something that checks whether this particular member's request meets it, shows the evidence, and puts the case in the right queue.
We've been building data and AI systems on AWS since 2008, a lot of them for banks, health plans, payments companies, and SaaS platforms that live under audit. Across that work, retrieval has kept the systems honest about the data and agency has let them finish the job, and in our experience a business owner won't sign off until both have been built for production.
Say the health plan's first pilot was a plain RAG assistant. It did one search, wrote one answer, and the nurses liked it for policy questions. Then they started pasting in real requests, and it would quote the knee MRI policy correctly while saying nothing about whether the member had done the six weeks of physical therapy the policy requires, because that was in the claims system and nobody had asked it to look there. The nurses went back to checking eligibility and claims by hand. Loan exceptions at a bank and renewal-risk reviews at a software company break a plain RAG assistant in the same way.
An agent with no retrieval fails in the opposite direction. It'll plan the whole review without complaint, working from whatever the model picked up in pretraining, and that's how you get an agent quoting a policy version the health plan retired two years ago. Agentic RAG combines the two, with controls around them, so the system reads current data and keeps a record an auditor can follow.
|
Dimension |
Traditional RAG |
Tool-calling agent (no retrieval) |
Agentic RAG |
|---|---|---|---|
|
How it retrieves |
One search, top few chunks |
Only through the occasional API call |
Several planned searches, checked as it goes |
|
Who decides the next step |
The code, because the pipeline is fixed |
The model, and nothing stops it |
The agent, within limits your policy sets |
|
Typical failure |
Misses multi-part questions |
Invented facts and unsafe actions |
Runaway loops and cost if nothing caps it |
|
Audit footprint |
The query and retrieved chunks |
Tool calls only |
Every plan, retrieval hop, and tool call |
|
Relative cost per query |
Lowest |
Moderate |
Highest, which is why routing matters |
|
Best fit |
FAQ, policy lookup, enterprise search |
Narrow, well-defined actions |
Multi-step research, decisions, and governed actions |
When the agent version picked up the same knee MRI request, it started by breaking it into three questions: was the member eligible on the date of service, which version of the imaging policy applied, and did the claims show the physical therapy?
That's query decomposition. It sent the eligibility question to the admin system through a Model Context Protocol (MCP) tool, the policy question to a vector index, the claims question to a SQL tool, and the ordering physician's details to a knowledge graph. The first claims search came back empty, because the therapy had been billed under a different provider.
So the agent rewrote the query and searched again, the same idea researchers describe as Corrective RAG and Self-RAG. With all three answers in hand, it wrote a short recommendation, cited each source, and dropped it in a nurse's queue for her to approve or reject.
Of the four things the agent did there, which were planning, routing, retrieving and checking, and handing off to a nurse, the last is where both the value and the risk are, so in our AI agents work we write it down before any code exists. The document says what the agent can do alone, what needs a person to approve it, and what it isn't allowed to touch. At the health plan, our version of that document would allow drafted approvals, which a nurse then signs, and would rule out the agent denying anything. On bigger programs we sometimes see the job split among specialist agents. One does research, one checks policy, one takes actions, and a supervisor agent hands out the work. That setup is called multi-agent RAG, and while it helps in complex domains, every extra agent adds hops you'll have to trace.
Most vendor content skips this question, and it's the first one your CFO will ask. The best data we've seen on it comes from a team that put both designs side by side and presented the results at ACL 2026, in a paper titled Is Agentic RAG worth it? Their agentic setups used, on average, 3.3 times as many input tokens, 1.9 times as many output tokens, and 1.5 times as much time as an enhanced RAG pipeline with reranking. Neither design came out ahead overall. The agentic version was better at working out what the user meant and rewriting the query, and the enhanced pipeline was better at ranking documents and routed more reliably when the domain was broad or messy.
That matches what we see in regulated production work. We'd let agency handle the steps that need judgment and keep everything else on the cheaper path. The Retrieval-Agency Fit Matrix below is what we use with leadership teams to make that call in one working session, and it's how we'd frame the agentic RAG vs. RAG decision for any use case.
Five signals that a use case is ready for agentic RAG:
If you can't check that last box yet, we'd hold off on the agent and ship enhanced RAG with hybrid search first. Every component carries forward into the agentic version later, so none of the work is wasted.
AWS has closed most of the plumbing gap. If you're starting a new agent today, it goes on Amazon Bedrock AgentCore. AWS renamed the original Amazon Bedrock Agents to Agents Classic and closed it to new customers on July 30, 2026. Existing accounts can keep using it and there's no end-of-life date yet, but if your pilot was built on it, we'd plan the move to AgentCore up front so it doesn't turn into a change order later. The table below maps each layer of an agentic RAG architecture to the AWS services we use and the decision your team still has to make.
|
Layer |
What it does |
AWS options |
Decision you own |
|---|---|---|---|
|
Knowledge ingestion |
Pulls in source content, then parses, chunks, and embeds it |
We'd use the Amazon Bedrock Managed Knowledge Base, which has connectors for Amazon S3, SharePoint, Confluence, Google Drive, and OneDrive, or a customer-managed knowledge base when you index into your own vector store |
Which sources are authoritative, and who owns freshness |
|
Index and vector store |
Holds the embeddings and runs hybrid search |
Managed Knowledge Base looks after storage for you; otherwise we'd pick from Amazon OpenSearch Serverless, Amazon S3 Vectors, Aurora PostgreSQL with pgvector, or Amazon Neptune Analytics for GraphRAG |
Latency target vs. storage cost, and EU data residency |
|
Agent runtime |
Runs the plan, route, retrieve, and verify loop |
AgentCore Runtime with Strands Agents, LangGraph, or another framework |
Maximum steps, timeouts, and the fallback path |
|
Tools |
Exposes APIs and functions to the agent |
AgentCore Gateway, which turns APIs and AWS Lambda functions into MCP tools |
Which actions are read-only and which need approval |
|
Identity and policy |
Passes the user's identity into every retrieval and tool call |
AgentCore Identity works with Amazon Cognito, Okta, or Microsoft Entra ID, and AgentCore Policy enforces Cedar rules at the Gateway |
The entitlement model enforced inside the query |
|
Safety |
Screens prompts and checks that answers are grounded |
Amazon Bedrock Guardrails, with content filters that catch prompt attacks, contextual grounding checks, sensitive-information filters, and Automated Reasoning checks |
Block vs. flag thresholds |
|
Memory |
Keeps session and long-term context |
AgentCore Memory |
Retention rules, and what must be forgotten |
|
Evaluation and observability |
Traces every hop and scores quality |
AgentCore Observability (OpenTelemetry, in Amazon CloudWatch) and AgentCore Evaluations |
Release gates and alert thresholds |
One change from this fall affects the first row. Since September 30, 2026, AWS hasn't allowed new Confluence, SharePoint, Salesforce, or Web Crawler connectors on customer-managed knowledge bases, and it now sends those sources to the Managed Knowledge Base, which looks after vector storage itself. For the health plan, that settles where the SharePoint policy library goes, while claims data stays in its own database behind a SQL tool.
Fraud rings, supply networks, and provider directories are all about relationships, and that's where a knowledge graph next to the vector index pays off, using GraphRAG on Neptune Analytics. We'd still start with hybrid search and only add the graph when the evaluation set shows it's needed.
Managed retrieval service or a custom agent? Here's how we frame the build choice for clients:
|
Option |
Where it fits |
Trade-off |
|---|---|---|
|
Managed agentic retrieval in the Amazon Bedrock Managed Knowledge Base |
Research and Q&A across documents, with the fastest time to value |
Less control over the planning logic, and per-call pricing |
|
Custom agent on AgentCore (Strands or LangGraph), with the knowledge base as a tool |
Workflows that read from and write to systems of record |
More engineering, but full control of routing, policy, and audit |
|
An assistant bolted onto an existing SaaS app |
Light internal search |
Limited auditability, and data may leave your AWS account boundary |
Our guide to running Amazon Bedrock agents in production goes deeper on inference profiles, batch pricing, and why guardrails and authorization solve different problems. For teams building agentic RAG on Amazon Bedrock, we usually end up recommending the custom path as soon as the agent has to touch a system of record, since that's where policy and audit requirements get specific, and the health plan's eligibility lookup is a good example.
In our experience compliance teams don't object to AI as such. They object to systems that can't show their work, and an agent cuts both ways there, since it takes more steps than a pipeline but every one of them can be logged if you plan for it. IBM's 2026 breach study shows why they're nervous: more than 20 percent of the organizations it surveyed had already had a breach aimed at an AI model or application.
Ask us for one control and we'd pick permission-aware retrieval. The nurse's entitlements decide what the agent is allowed to pull before the query runs, rather than someone trimming the results afterward. Filtering after the fact is how a well-meaning agent ends up summarizing a document the user was never cleared to see, and at the health plan that document would be another member's record. We treat that as a fixed rule in our enterprise AI strategy work, along with giving every retrieved passage an ID you can trace.
The table below is how we map the main frameworks to what we build. The health plan would mostly care about the HIPAA and SOC 2 rows, while a bank or payments company would usually answer to three or more of them at once.
|
Framework |
What the auditor will ask |
What we'd show them |
|---|---|---|
|
HIPAA |
Who saw this member's record, and were they allowed to? |
Retrieval scoped to the member and the nurse's role, encrypted indexes on HIPAA-eligible services under a BAA, and an access log for every hop |
|
SOC 2 |
How do you know what changed last Tuesday? |
Prompts, tools, and indexes in version control like code, plus a log of every plan and tool call |
|
PCI DSS |
Could a card number end up in the index? |
No, because card numbers are tokenized before anything is indexed |
|
GLBA, SEC, and FFIEC guidance |
Why did the system recommend that? And was it tested before it went out? |
The decision log with the evidence behind it, plus challenger-model test results for every release and its entry in the model inventory |
|
GDPR |
A customer asked to be forgotten. Is anything of theirs still in the system? |
Not once the deletion reaches the embeddings and cached answers, and none of it left the EU Regions to begin with |
|
EU AI Act (high-risk uses) |
Is there a log of what the system did, and can a person overrule it? |
Automatic event logs under Article 12, and a person who signs off on consequential actions under Article 14 |
For European operations, the clock has moved. Under the EU's Digital Omnibus amendments to the AI Act, adopted as Regulation (EU) 2026/1744, high-risk obligations for Annex III systems now apply from December 2, 2027, and AI embedded in regulated products follows on August 2, 2028. We'd use the extra time to build logging and oversight in now, since retrofitting them after an auditor asks costs far more.
In the US there's no comprehensive federal AI statute to map against, so the working baseline is sector regulation plus the NIST AI Risk Management Framework. NIST's Center for AI Standards and Innovation also launched an AI Agent Standards Initiative in February 2026, with agent security and identity among its focus areas, which tells you where auditor questions are heading.
That's the approach we took on the KlearTrust HIPAA claims platform: PHI-safe retrieval, an authority boundary for the agent, and audit evidence captured at decision time. A six-month manual review cycle was replaced by a production system in twelve weeks, and the platform passed HIPAA and internal audit on first review. For a health plan like the one in our example, the same controls sit at the center of any healthcare data platform we put into production.
Below is the back-of-the-envelope model we walk through with finance teams. It uses AWS list prices for retrieval in the Amazon Bedrock Managed Knowledge Base, the token multipliers from the ACL 2026 study, and a placeholder model price you'd swap for your own.
Assumptions:
|
Design |
Model tokens |
Retrieval |
Monthly total |
Cost per query |
|---|---|---|---|---|
|
Standard RAG for everything |
$1,800 |
$100 |
$1,900 |
$0.019 |
|
The agent on every query |
$5,100 |
$800 |
$5,900 |
$0.059 |
|
Routed, with 60% standard and 40% agentic |
$3,120 |
$380 |
$3,500 |
$0.035 |
Routing does most of the work here. Sending simple questions down the standard path cuts the bill by about 40 percent compared with putting everything through the agent. The other thing the model shows is that tokens are rarely what sinks the business case. The things that do sink it tend to be these:
We'd keep the per-query number in check by capping agent steps and token budgets, caching repeat retrievals, planning with a smaller model such as Amazon Nova 2 Lite, and running offline evaluation through batch inference. We'd also measure cost per resolved task next to cost per query, because an answer that gets escalated carries the cost of both the agent and the reviewer. At the health plan, a recommendation a nurse has to redo costs more than one the nurse just signs.
As for where the money comes from, it's usually already in the building. In the words of our point of view on funding AI: “Most of the AI budget you think you need is already in the building. It is paying interest on the old stack.” Legacy database licenses, integration tiers that bill hours to stay alive, and warehouses nobody runs new workloads on are all candidates for reallocation, which turns AI from an R&D line into a capital allocation decision. That matters, because McKinsey found only 37 percent of respondents attribute any EBIT impact to AI so far, about the same as a year earlier.
Dan Marks, our VP of Business, put it this way in Agentic AI: The Production Path:
“In the agent programmes reviewed, the technical blocker was almost never the model. Plenty stalled on one of three things: an authority boundary nobody had written down, an evaluation set nobody had built, or a source system nobody had assessed. The programmes that shipped fastest spent their first fortnight on the paperwork most teams treat as a distraction.”
That matches what we see. The table below is the failure-mode list we review with every client before go-live, with the fix we put in for each one.
|
Failure mode |
What you see |
Root cause |
Production fix |
|---|---|---|---|
|
Runaway loops |
Token bills spike and latency climbs |
No step cap or stop condition |
Hard step and budget limits, with a fallback to the standard path |
|
Permission leakage |
Users see content they shouldn't |
Filtering after retrieval |
Entitlements enforced inside the query |
|
Prompt injection through documents |
The agent follows instructions hidden in retrieved text |
Retrieved content treated as trusted |
Guardrails prompt-attack filters, tool allowlists, and provenance tags |
|
Retrieval drift |
Accuracy drops after re-embedding or a model swap |
No regression suite |
Golden-set regression in CI before every index or model change |
|
Stale index |
Answers quote a policy that's been replaced |
Nobody set a freshness SLA for batch ingestion |
We'd sync on events and show freshness dates in citations |
|
Tool-call cascades |
One failed API call takes the whole task down |
Tools don't retry or handle partial results |
We'd make tools idempotent, add circuit breakers, and escalate cleanly |
|
Judge bias |
Offline scores look great, and users still disagree |
An LLM grades LLM output and nobody calibrated it |
We'd keep a human-labeled calibration set and review it monthly |
At the health plan, the two failures we'd worry about most are the second and the fifth: a nurse seeing another member's record, and a recommendation that quotes last month's policy. Neither has anything to do with the model. In fact only one of the seven really does, and the rest come down to data, identity, and operations, which is why we spend less time on the RAG vs. AI agents debate than clients expect and more on getting retrieval and agency to behave together under real load.
Leaderboards won't tell you whether an agent will work on your contracts or your claims. On one knowledge benchmark alone, AA-Omniscience, Stanford's 2026 AI Index found hallucination rates anywhere from 22% to 94% depending on the model, and with a spread like that your own evaluation set has to be the source of truth. We'd build that set at the health plan from a few hundred past prior-authorization requests, including the messy ones.
|
Metric |
What it tells you |
Starting gate we typically set (tune to your risk) |
|---|---|---|
|
Retrieval recall@k and NDCG |
Whether the right evidence was found and ranked |
A baseline from your labeled set, and no release that regresses it |
|
Faithfulness (groundedness) |
Whether claims are supported by the retrieved evidence |
0.9 or higher on the golden set |
|
Citation accuracy |
Whether cited sources actually say what the answer claims |
100% on regulated answers |
|
Tool-call accuracy |
Whether the agent picked the right tool with valid inputs |
95% or higher before write access is granted |
|
Task success rate |
Whether the job got done without a human redo |
Agreed with the business owner for each use case |
|
Steps and cost per resolved task |
Whether agency is paying for itself |
Tracked weekly against the routed baseline |
|
p95 latency |
Whether users will wait for it |
Set by the workflow, not the engineering team |
|
Escalation rate |
Whether the authority boundary is set correctly |
Trending down after launch, with spikes triggering a review |
Say the health plan swaps in a newer model in March. Before it goes live, the change runs against the golden set in CI, and if faithfulness drops on the prior-authorization cases, it doesn't ship. After launch, AgentCore Observability traces each hop with OpenTelemetry, so the team gets alerts on step counts, grounding failures, and policy denials in the same place it already watches error rates.
When a metric slips, the cause is more often the data than the model. Gartner found in 2026 that organizations with successful AI initiatives invest up to four times more, as a share of revenue, in data and analytics foundations, and our point of view on why most enterprises will fail at agentic AI explains why source readiness belongs in week one of any agentic retrieval program.
With a scoped use case and an accountable owner, about 12 weeks, which is also the median from kickoff to production across Mactores engagements. Here's the plan we run, with a customer-signed exit at the end of each phase and a forward-deployed engineer owning the judgment calls, as described in how we work.
|
Weeks |
What gets done |
Exit criteria |
|---|---|---|
|
1 to 2 |
Write the authority boundary, assess source systems, and build the first golden evaluation set |
Signed scope, a named owner, and a labeled evaluation set |
|
3 to 5 |
Ingestion, indexing, permission-aware retrieval, and an enhanced RAG baseline |
Baseline scores recorded, and entitlement tests pass |
|
6 to 8 |
The agent loop, tools through MCP, guardrails, policy, and memory |
Tool-call accuracy and step limits meet the gate |
|
9 to 10 |
We red-team the agent, test it against prompt injection, and assemble the compliance evidence pack |
Security and compliance sign-off |
|
11 to 12 |
The agent runs in shadow mode, then rolls out in stages, and we cut over with runbooks in place |
It's handling production traffic and the business owner has accepted it |
Hibu's project shows why the dull work goes first. Its retrieval layer, a purpose-built MCP connector that gives Claude hybrid keyword and semantic search over an OpenSearch index of 1.82 million inbound lead calls a month, was finished before the agent layer went live. Questions that used to sit two to three days in an analyst queue now get answered in under five minutes.
Should you build it yourselves or bring in a partner? Here's the gut check we'd use:
|
Question |
Build in-house if |
Bring in a partner if |
|---|---|---|
|
Team |
Your engineers have already shipped agents to production on AWS |
Your team is strong on apps or data and new to agents |
|
Timeline |
No board or regulatory date is attached |
A date has been committed to the board or a regulator |
|
Risk |
Low-risk internal use |
Regulated data or consequential actions |
|
After go-live |
You plan to staff a permanent agent platform team |
You want your team to own it, with the heavy lifting done once |
If the answers point to a partner, our generative AI consulting work covers the retrieval side of agentic RAG, from precision and recall to faithfulness against source documents, on the same fixed-date, fixed-fee terms as the rest of what we ship.