Two things landed in the last week that point the same direction: the hard part of agent retrieval is no longer packing the window, it's guaranteeing that what you retrieved was correct to begin with.
The clearest argument comes from a [DataHub engineering post](https://datahub.com/blog/context-engineering-for-ai-agents/) published five days ago, which makes a case most RAG teams will recognize from their own incident logs. Its framing: agents don't usually fail because the context window was badly ordered or compressed. They fail because the agent found a table, read its schema, wrote fluent SQL, and answered from a staging table nobody has trusted since last quarter. Window curation cannot catch that class of error — the failure happened before the model saw anything.
The architectural response is a context layer between the agent and the data platform, typically exposed as an MCP server. The post describes Miro running this pattern with Claude Code decomposing the question, DataHub supplying governed metadata — entity descriptions, glossary terms, lineage, example queries — and Snowflake Cortex executing the SQL. The number worth noting: before that layer existed, accuracy sat below 40%. A coding agent wired straight into a warehouse sees schema and nothing else, which is roughly the position most internal "chat with your data" deployments are in today.
The FIS example in the same piece shows the ceiling on retrieval-only approaches. Software for more than 20,000 bank clients, 75 billion transactions a year, on mainframes whose column names carry no semantic meaning at all. Ontology derivation in Databricks Genie handled part of it; the rest is knowledge that lives in people's heads and was never written down. If your corpus has no semantics to embed, no reranker saves you. Someone has to author meaning, and keep authoring it as teams reorganize and metrics get redefined.
Why this matters more now
Because the layers below it are commoditizing fast. Per [this week's agent news roundup](https://aiagentstore.ai/ai-agent-news/this-week), OpenAI put a managed Agents API into public beta that handles orchestration, long-running sessions, and context management, with sandbox compute from OpenAI, customers, or partners including Vercel and DigitalOcean. If session state, memory plumbing, and sandboxing become a vendor API call, the remaining differentiator for anyone building internal knowledge tools is the quality and governance of what gets retrieved. That is not a component you can buy in a beta.
It also reframes agent memory. Work like the [xMemory paper](https://arxiv.org/abs/2602.02007) argues that flat top-k similarity is a poor match for an interaction stream full of near-duplicates — it returns redundant context, while summary hierarchies blur the details that distinguish candidates. Same lesson, different corpus: retrieval quality is a structuring problem, not a scoring problem.
Practical read for teams: treat your semantic layer, glossary, and lineage as production dependencies of the agent, with owners and freshness SLAs. Instrument which retrieved objects the agent actually used, not just whether users liked the answer. And measure accuracy against a set of questions where the wrong-but-plausible table exists — that's the failure mode you're buying the context layer to prevent.