Everyone assumed retrieval was the bottleneck for production agents. It isn't.
I talk to AI engineers building production agents every week. For two years, every data problem got the same prescription. Need proprietary data? Vector database. Better context? Chunk differently. RAG became so universal it stopped being questioned.
These same engineers stopped talking about retrieval quality and started talking about context management, specifically how agents discover what data exists across systems, how they resolve entities across silos, and how they keep context windows clean enough for the model to reason at all.
Speed of retrieval was never what held agents back. It was whether your agent could assemble the right context across disconnected systems, and that's a problem RAG was never designed to solve.
RAG isn't dying. But its appropriate scope is far narrower than the industry assumed, and the gap between what RAG was designed for and what production agents actually need is where most teams are getting stuck.
How RAG Became the Default When AI agents first became a serious capability, the immediate problem was obvious: these models were powerful but blind to internal data. Enterprises needed agents that understood proprietary documentation, customer histories, internal processes, and everything behind the firewall.
The intuition seemed natural. Humans read documents to do research, so agents should too. Chunk documents, generate embeddings, write a retrieval function, and suddenly your agent could answer questions about internal data that no public model could touch. You could build a working prototype in an afternoon, and for a while that speed of iteration masked a fundamental limitation: RAG could retrieve documents, but it couldn't understand the systems those documents described.
Production made that limitation impossible to ignore. Early RAG implementations like text-to-SQL tools and basic retrieval pipelines failed when they hit real customer diversity and entity resolution complexity.
Chunked documents are a crude, lossy way to give an agent the context it actually needs, and the crudeness only becomes apparent when you leave the demo environment and encounter the full messiness of real data.
The Context Rot Problem RAG's core design makes the context window worse, not better.
Research on context rot shows that model performance degrades measurably as input length grows, and irrelevant material accelerates the decline dramatically. Even on simple tasks, models become less reliable as you add context. RAG compounds this by stuffing document chunks into the context window with no guarantee of relevance, no entity awareness, and no understanding of how the retrieved information relates to anything else the agent knows.
The failure is subtle and hard to debug. Your agent retrieves five documents. Four are relevant. The fifth isn't, but that single distractor can misdirect the agent's reasoning in ways you won't catch until a customer reports the wrong answer.
And the problem compounds over time.
A knowledge base starts clean, retrieval works, confidence builds. Then more teams contribute content, more data sources get connected, and every new document increases the probability that the next retrieval pulls in noise that derails the chain of reasoning.
Bigger Windows Don't Fix Relevance When context windows expanded to two million tokens, teams thought the problem was solved. Retrieve more, give the agent everything, let it sort out what matters. But a larger context window doesn't fix relevance, it amplifies whatever quality your retrieval provides. With poor retrieval and disconnected data, a bigger window just means more material for the model to hallucinate through.
The deeper issue is that RAG frames context as a retrieval problem when it's actually a discovery problem. Retrieval asks: given this query, which document chunks are most semantically similar? Discovery asks: what entities exist across all connected systems, and what does this agent need to know about them right now? The second question produces dramatically better context because it organizes around entities and relationships rather than document similarity.
Retrieval vs. Discovery Consider an agent processing a refund. A RAG pipeline retrieves documentation about refund policies, maybe a few related customer records if someone thought to chunk them into the knowledge base. But what the agent actually needs is the specific transaction from Stripe, the customer's identity resolved across Stripe and the CRM and the support system, and the complete refund history across all three. That's not a retrieval problem. It's a search and discovery problem across structured, entity-aware data, followed by a write operation that RAG was never designed to handle.
What Production Agents Actually Need Three problems keep killing production agent deployments, and none of them are about better chunking strategies.
The most fundamental is discovery. Most source systems expose IDs, not search. Your CRM, support system, billing platform, and email tools all contain records, but none of them understand how those records relate to each other across tools.
Consider an agent asked to find every customer who had a failed charge last week and also opened a support ticket. In a RAG pipeline, it has no starting point. It can only retrieve chunks from whatever was indexed. What the agent actually needs is a unified layer that resolves and aligns entities so it can search across everything at once. Without that, every cross-system query becomes a brittle chain of lookups that breaks the moment a single ID doesn't resolve.
Context Quality Over Retrieval Quality Discovery alone isn't enough if what you discover is noise. Context quality (which is distinct from retrieval quality) determines whether the agent reasons well or badly. RAG fills the context window with chunks ranked by vector similarity and hopes the right information surfaces.
A context store that replicates data across sources and resolves entities into a unified model does something fundamentally different: it lets the agent query for exactly the structured context it needs, with entities already aligned across systems. This results in fewer and better tokens.
For most use cases, data the context store replicates and indexes within the hour is more than sufficient for search and discovery. True real-time freshness matters only at the moment of action, when the agent fetches from the source system directly before executing a write.
That moment of action reveals the third gap, the one most teams discover too late. An agent escalating a support ticket needs to create a Jira issue, update the customer record in Salesforce, and notify the account team in Slack. That's three writes across three systems, each requiring proper authentication and input validation.
Agents update records, trigger workflows, and modify system state, and that requires connectors that treat writes as first-class operations with all the reliability guarantees that implies: authentication management, rate limiting, schema change handling, error recovery.
Enterprises need full auditability of what data an agent accessed, what decisions that data influenced, and what permissions governed each step. The plumbing has to work like actual pipes, handling backpressure, leaks, and changing specifications. Because when it fails, the agent doesn't just give a wrong answer. It takes a wrong action.
Search, Discovery, and Structured Context The teams furthest ahead aren't fixing their RAG implementations, rather replacing them.
There's a useful precedent in coding agents. Both Claude Code and Codex saturated coding benchmarks recently, and not because of better models. The breakthrough came from how their operational scaffolding structures and delivers context, not from how it chunks or retrieves documents.
The pattern emerging in production follows the same principle.
Data replication feeds a context store that resolves entities across sources and pre-indexes records for search. Instead of retrieving document chunks against a query, the agent searches this unified layer to discover relevant entities, then assembles precisely the context it needs. When the task requires action, it calls structured functions directly: salesforce.update_opportunity(id, changes) rather than searching for documentation about how Salesforce opportunities work.
The Economics of Precise Context This changes the economics of context at scale. A RAG-based support agent might retrieve five document chunks averaging 1,000 tokens each per interaction. That's 5,000 tokens of loosely relevant context per request, much of it wasted on tangential passages. An agent querying entity-resolved, pre-indexed data retrieves only what's relevant to the specific entity and task. The savings come from eliminating the irrelevant context that RAG includes by design. At thousands of interactions daily, that precision compounds into the difference between economically viable and unsustainable.
Governance becomes tractable too. When you structure access patterns so they're observable, you can audit exactly what an agent accessed, the context and policy that governed it, and when, down to the individual decision. Try doing that with a vector similarity search that returned the top-k chunks from an unstructured knowledge base.
Domain-Aware Agents Domain-aware agents outperform general-purpose systems when this infrastructure supports them. A Salesforce agent that understands CRM data models operates differently than a general-purpose agent searching document chunks. So does a Stripe agent that specializes in payment operations. Both perform best when they can discover entities across a pre-indexed layer and then fetch or write against live systems directly. Document retrieval alone can't provide that structured operational awareness. A unified context layer that replicates and resolves data across sources can, and the performance difference is large enough that teams who make the switch don't go back.
Where RAG Still Belongs RAG works well for what it was designed for, and that scope deserves honest acknowledgment.
Research workflows genuinely benefit from document retrieval. Analyzing historical data, synthesizing written sources, and answering questions about static documentation are all tasks where RAG is the right tool. Content analysis and generation are similarly well-suited, since agents that draft emails, summarize conversations, or extract insights from text are fundamentally reading and writing natural language.
The problems emerge when teams stretch RAG into operational territory. Multi-step automation that reasons across systems. High-frequency operations where token costs compound. Workflows that need entity awareness spanning CRM, billing, and support at once. RAG was built to help agents read. Production agents need to discover, reason, and act, and the distance between those capabilities is where most teams are stuck.
The Real Bottleneck The model race gets all the attention. The decisive work is happening where fewer people look.
Production agents need three capabilities, not one. Search to discover what entities exist across systems and how they connect. Fetch to get the current state of a specific entity when freshness matters. And write to safely complete actions against live systems. Replication and entity resolution provide the foundation. A context store makes that foundation queryable. Direct connectors handle the moments when the agent needs to read or change something right now.
If you're defaulting to document retrieval for every agent use case, reconsider. If you're building operational agents, invest in reliable connector infrastructure. Authentication, rate limits, schema management, and error handling aren't glamorous, but they're what separates agents that demo well from agents that run in production.
The pipes don't connect yet. The teams shipping production agents recognized this early and built accordingly. The connectors, the context stores, the entity resolution layers, that's the infrastructure that gives agents not just documents but understanding. For most teams, it's still the missing piece.
Subscribe to Agent Blueprint to learn more about agentic data infrastructure.
