Retrieval was the easy layer. It is also the only one most enterprise AI stacks have finished.
The retrieval pilot works. It answers questions about the policy library, the contract archive, the support history. It demos beautifully. Eleven months later it is still a demo, because the distance between a system that answers questions and a system that is allowed to act on them turned out to be six other pieces of engineering nobody scoped.
RAG helps agents know more. Knowing more is not the same as being safe, useful, or shippable. McKinsey's QuantumBlack Labs (2026) put the same point in operating terms when it named the four capabilities that separate enterprise-ready agentic AI from experiments: flexible architecture, rigorous evaluation, disciplined engineering practice, and scaled expertise. Its blunter observation is that many generative AI initiatives struggle to move past the demo stage precisely because they were run as isolated experiments rather than engineered systems.
Seven layers stand between a retrieval demo and a production agent. Retrieval is the first. The seventh is the one almost nobody writes down, and it is not engineering at all.
What RAG Actually Fixed
Give retrieval its due, because the criticism only lands if the credit is honest.
Foundation models arrive with a fixed set of problems that no amount of prompting solves. Pinecone (2025) lists them cleanly: a training cutoff that freezes what the model knows, shallow depth in specialised domains, no access to private or proprietary data, and probabilistic output that produces confident answers with nothing to check them against. Every one of those is a knowledge problem.
RAG fixes knowledge problems. It puts your documents in front of the model at inference time, so the answer is grounded in your contract templates rather than the internet's average opinion about contract templates. It gives you citations, which turns an unverifiable claim into something a reviewer can check. It lets you update what the system knows by updating a document, not by retraining anything.
That is a large win, and it is why RAG spread so fast. It is also, precisely, the boundary.
RAG changes what the model knows. It does not change what the system is permitted to do, how you find out whether it did the right thing, or who answers for it when it does not. Those are different problems with different solutions, and none of them get easier because your retrieval improved.
Where Retrieval Stops Paying Off
The first thing teams try when a pilot underperforms is more retrieval work. Better embeddings. Smaller chunks. A reranker. Sometimes that is right. Often it is a way of continuing to work on the layer you already understand.
Retrieval quality is real and it has structure. Weaviate (2026) breaks it into four dimensions worth auditing separately: the embedding model you chose, your chunking architecture, your retrieval strategy, and index maintenance and freshness. Each one fails differently. A stale index and a bad chunk boundary produce the same symptom, which is a confidently wrong answer, and they need completely different fixes.
Two findings from that research matter more than the tuning advice.
The first is that scaling the model does not solve a retrieval problem. If the right passage never reaches the context window, a larger model just writes a more fluent answer without it. Retrieval failure is the upstream cause of a large share of what gets reported as hallucination, and teams routinely misdiagnose it as a model quality issue. (This is the most expensive misdiagnosis in the category, because the fix people reach for is a bigger model contract.)
The second is that retrieval errors compound in multi-agent systems rather than averaging out. One agent's slightly wrong retrieval becomes another agent's premise, which becomes the input to a tool call. Error propagation is a property of the architecture, not of any individual component.
There is also a class of retrieval problem that is not really about retrieval at all. AWS Prescriptive Guidance documents how the source data itself defeats RAG applications: missing structure and metadata, inconsistent terminology and undefined abbreviations, verbose or redundant passages, ambiguous phrasing, and documents written for a human reader who already knew the background. No chunking strategy repairs a knowledge base that disagrees with itself.
The honest framing is this. Retrieval done perfectly still leaves you with a system that can describe your refund policy and cannot issue a refund. Everything expensive starts the moment you close that gap.
The Moment Your Agent Can Act
Everything changes when the system gets a tool that writes.
Up to that point, the failure mode of your AI is an incorrect sentence. A human reads it, notices it is wrong, and ignores it. The blast radius of a bad answer is one reader's attention. After that point, the failure mode is an incorrect action against a system of record, and there may be no human in the path at all.
Consider two agents with an identical retrieval layer over the same knowledge base.
The first is a support triage agent. It reads a ticket, retrieves the relevant runbook, and drafts a suggested reply for an agent to approve. Every output passes a human before it reaches a customer. The worst realistic outcome is a wasted thirty seconds.
The second is a refund agent. It reads the ticket, retrieves the same runbook, checks the order in the commerce system, and issues the refund. Same retrieval, same model, same prompt quality. The worst realistic outcome is money leaving the business against a policy the agent misread, at whatever rate the queue delivers tickets.
Same retrieval layer, two completely different engineering bills. Nothing about the difference is a retrieval problem.
Oktana (2026) makes the useful move of classifying tool risk before the build starts rather than after the incident. The classification is not complicated. For each tool the agent can call, write down what it changes, whether the change is reversible, who else sees the effect, and what a wrong call costs. Read-only tools against internal data sit at one end. Tools that move money, send external communications, or modify production records sit at the other.
That list then drives design rather than decorating it. High-risk tools get a confirmation step , a narrow parameter range, a rate limit, and a rollback path. Low-risk tools run unattended. The mistake is applying uniform caution across every tool, which produces a system so hedged that nobody uses it, or uniform trust, which produces the incident.
Orchestration and Where Determinism Belongs
Not every step in a workflow should be a model decision, and one of the more expensive habits in agent engineering is treating autonomy as a default rather than a choice.
Databricks (2026) sets out a ladder that is worth internalising: a single LLM call with a prompt, then a deterministic chain with hard-coded steps, then a single agent that selects its own tools, then a multi-agent system. Complexity increases at every rung. So does failure surface, latency, cost, and the difficulty of explaining what happened.
The design question is not "how autonomous can we make this" but "where does judgment add value". Put determinism wherever correctness is cheap to specify. If the rule is that refunds over a threshold need a human, that is an if statement, not a prompt instruction the model may or may not honour on a long context. Reserve model judgment for the parts of the workflow that resist specification, which is usually interpretation of messy input rather than the decision logic downstream of it.
Multi-agent architectures deserve particular scepticism as a starting point. They are the right answer for genuinely separable domains with different tools and different context needs. They are the wrong answer for a workflow that a single agent with five tools would handle, because every handoff is a place where context is lost and upstream error is inherited as fact. MuleSoft (2026) frames the enterprise version of this problem well, arguing that agents are an architecture problem rather than a technology problem, and that the layer teams forget is the one that encodes what the business actually does.
How You Know It Is Good Enough to Ship
Here is the widest gap on this topic. Search for enterprise agent architecture and you will find layer diagrams, security guidance, and observability tooling. You will find very little about how anyone decides an agent is good enough to put in front of customers, and even less about how they decide it is still good enough three months later.
Evaluation is the load-bearing layer that most stalled pilots are missing. McKinsey's QuantumBlack Labs (2026) names it as one of four essentials specifically because agentic systems introduce new uncertainty that component testing does not surface: tool failures, memory drift, and unexpected behaviour across multi-agent workflows. Its recommendation is evaluation at the system level, not at the model level.
In practice that means four things.
An offline eval set built from real traffic. Not synthetic questions written by the team that built the agent. Take a few hundred real cases, have a domain expert label the correct outcome, and keep them versioned. This is the highest-leverage artefact in the whole programme and it is usually the one nobody funds.
A regression suite that runs on every change. Prompt edits, model upgrades, a new tool, a reranker swap, a knowledge-base refresh. Any of them can move behaviour. Without a suite that runs automatically, "we improved the prompt" is a claim rather than a measurement.
A release gate with a threshold somebody signed. A named pass rate on the eval set, agreed in advance by a person with the authority to accept the residual risk. Not a vibe check in a review meeting. For a claims-intake agent, that might be a minimum extraction accuracy on the fields that drive payment, plus a ceiling on the rate at which it escalates cases it should have handled.
Drift checks after launch. Model providers update models. Your business changes its policies. Your users learn what the agent does badly and route around it, which changes the input distribution. An agent that passed in March is an untested agent in September unless something re-runs the suite.
The argument that lands with a CIO is not about quality. It is about optionality. Without evals you cannot safely change anything, so the system freezes, and a frozen agent decays because the business keeps moving and the agent does not. The eval suite is what buys you the right to keep editing the thing you shipped.
Who Is Allowed to Do What
An agent inherits the permissions of whatever credentials it was wired up with, which in most first implementations means the permissions of the engineer who built it or a service account with generous scope. That is fine in a prototype and indefensible in production, for two reasons that arrive at different times.
The first is retrieval-side. If your knowledge base contains documents that not every user is allowed to read, then an agent that retrieves across the whole index will leak them through a summary, no matter how carefully you word the system prompt. AWS (2025) documents the authorization patterns for this directly, showing how per-user access grants can be enforced at the retrieval layer so the agent only ever sees what the requesting user could have opened themselves. Filtering after retrieval is not equivalent. By then the content is already in the context window.
There is an ingestion-side version of the same problem. AWS Security (2024) covers filtering at ingest, which matters because a knowledge base populated from external or user-supplied sources is an injection surface. Content that reaches the index can carry instructions that reach the model.
The second reason is identity, and it scales faster than people expect. Accenture (2025) points at the shape of the problem: agent identities are proliferating well beyond human ones, and existing identity management was designed for a population of people who join, change roles, and leave at human speed. Agents get created for a project, granted access, and then persist. Nobody offboards them because nobody owns them , which is a preview of the last layer in this list.
The practical test is an audit question , and it is one to put to your team today. For any action an agent took last week, can you show which identity performed it, under which grant, and who approved that grant? If the answer involves reading application logs and inferring, you do not have a permissions layer. You have a service account.
What a Useful Trace Contains
Observability for agents is not application logging with a nicer dashboard. The thing you need to reconstruct is a decision, and decisions have inputs that traditional logs throw away.
LangChain (2026) makes an argument worth taking seriously here, which is that building and testing are converging in agent engineering. The trace is not just an incident-response artefact. It is the raw material for the eval set, the debugging surface during development, and the evidence in a post-incident review. Teams that treat it as an ops concern to add later end up rebuilding it as a development concern anyway.
A trace that earns its storage cost carries, joined under one identifier: the user input, the retrieved context with document identifiers and scores, every tool call with its arguments and its response, the intermediate reasoning steps, the final output, and the identity the whole thing ran as. Anything less and you can see that something went wrong without being able to say why.
The test to run on your own stack is a timing one. When an agent does something wrong, how long does it take to answer the question "why did it do that"? If the answer is measured in days, or if it involves reading a chat transcript and guessing which document it must have pulled, the observability layer does not exist yet.
The Layer Nobody Writes Down
Six layers of engineering, and the one that decides whether any of it survives contact with an organisation is not engineering at all.
Every architecture guide on this topic stops at the technology boundary. They name models, data, tools, orchestration, governance. Almost none of them names a person. That omission is why so many technically sound pilots stop working , and it is the part of McKinsey's framing that gets skipped: alongside architecture, evaluation, and engineering discipline, it names operating models that make AI reliable, measurable, and production-ready. Operating model is a polite phrase for who does what on a Tuesday afternoon when the thing starts failing.
Four questions decide whether you have an owner model. None of them are technical.
Who gets paged? A production agent needs the same on-call answer as a production service. If the answer is "the team that built it, if they still work here", you have a prototype in production.
Who approves a permission change? When someone wants the agent to write to a new system, there has to be a named approver who understands the blast radius, and a record of the decision.
Who funds the eval work? Evaluation is ongoing cost with no demo value, which makes it the first thing cut when the project budget closes. It needs a line item and an owner, or it will not exist by the second quarter.
Who decides to turn it off? Someone has to hold the authority to deprecate the agent, and to notice that it should be deprecated. Agents without owners do not get retired. They get forgotten while still holding credentials.
This is where the seven layers stop being an architecture conversation and become a staffing one. A serious agent programme needs retrieval engineering, tool and integration work, orchestration design, an evaluation practice, identity and access expertise, observability tooling, and a named owner with the standing to make calls about risk. Very few organisations have all seven on staff, and hiring all seven permanently is an expensive answer to a question that changes every six months.
That is the gap our Fractional Agentic Team is built for. It is an embedded team that supplies the layers you are missing, works inside your stack rather than alongside it, and hands over an owner model your people can run. If you already know which layers are empty, that is the conversation to have.
The Seven-Layer Self-Check
Run this against your own stack. One question per layer, and the only useful answers are yes or no.
- Knowledge retrieval. Can you state your retrieval accuracy on a labelled set, rather than describing your chunking strategy?
- Tool execution. Is there a written classification of every tool the agent can call, by what it changes and whether that change is reversible?
- Workflow orchestration. Are the steps that must be correct implemented as deterministic logic rather than as instructions the model is asked to follow?
- Evals. Is there a versioned eval set built from real traffic, and does it run automatically on every change?
- Permissions. Can you show, for any action the agent took, which identity performed it and under which grant?
- Observability. When an agent behaves wrongly, can you reconstruct why from a single trace in under an hour?
- Owner model. Is there a named person who gets paged, approves permission changes, funds the eval work, and can decide to turn it off?
Count the noes. That is the real project plan, and it is almost never "improve retrieval".
The question worth taking into the next budget conversation is not whether your retrieval is good. Retrieval is probably fine. It is which of the other six layers has a name against it.
