Google Research added a Sufficient Context Agent to the Gemini Enterprise Agent Platform on June 8, shipping it as a public-preview feature called Cross-Corpus Retrieval. The framework is multi-agent RAG, and its distinctive contribution is one specific agent in the pipeline whose only job is to decide whether the evidence retrieved so far is actually enough to answer the question. Standard RAG retrieves once and answers. This framework runs five phases: a Root Agent parses the request and delegates, a RAG Agent fans out parallel queries across multiple data sources, the Sufficient Context Agent inspects the retrieved snippets against the original prompt, a Query Rewriter generates new targeted searches if gaps are found, and a final synthesis step confirms completeness before the model is allowed to generate. The numbers Google published: on FramesQA, a benchmark of 824 queries over 2,676 PDF documents, the system reached 90.1% accuracy at selecting the correct database out of four sources, delivered up to 34% factuality improvement over a vanilla RAG baseline that itself used an advanced retrieval engine plus an LLM parser plus a re-ranker, and kept latency within 3% between single-corpus and cross-corpus modes.
The mechanism worth examining is what the Sufficient Context Agent does that distinguishes it from a standard relevance or confidence check. A typical RAG quality gate produces a binary or a score: relevant or not, confident or not, and when it fails it either answers anyway or returns "insufficient context" and stops. The Sufficient Context Agent does something more specific: when the evidence is incomplete, it writes a Reason and Feedback log that names the gap. Not "insufficient" but "found the server ID in corpus A but not the hardware specs, which should be in a second database." That named gap is what the Query Rewriter consumes to generate the next search. The loop is therefore not retrieve-score-retry with the same query, it is retrieve, diagnose the specific missing piece, rewrite the query to target that piece, retrieve again. The three failure modes it targets are concrete and familiar to anyone who has shipped RAG: partial answers (you found half the answer in one source and stopped), premature not-found (the first search came back empty so the system gave up), and hallucination (the context was incomplete so the model guessed to fill the hole). Naming the gap is what converts a dead-end "I don't know" into a directed next search.
The ecosystem reading is that this is the same state-externalization pattern we have been tracking, now applied to the knowing-what-you-don't-know problem, and shipped into an enterprise runtime rather than published as a paper. Harness-1 externalized retrieval bookkeeping into the environment. Memory OS externalized agent memory into six typed layers. The Sufficient Context Agent externalizes the sufficiency judgment into a dedicated agent with a written log, instead of leaving it as an implicit property of the generator's confidence. The strategic context is that this lands inside the Gemini Enterprise Agent Platform, the same enterprise tier where Antigravity 2.0's Managed Agents live, which means Google is assembling the enterprise agent stack one externalized capability at a time: orchestration, retrieval, sufficiency-checking, query-rewriting, each a named component in a runtime you rent rather than a prompt you write. That is the productization of the agentic-RAG research direction, and the 34% factuality number is the argument they are making to enterprise buyers who got burned by RAG-that-confidently-hallucinates in the first wave.
Monday morning, if you are running RAG in production and your failure mode is confident wrong answers on multi-hop queries: the Sufficient Context pattern is the architecture to study, and the key design move is making the sufficiency check name the specific gap rather than emit a binary, because the named gap is what makes the re-search targeted instead of repetitive. You can build this pattern yourself without the Gemini platform, the components are an orchestrator, a parallel retriever, a sufficiency-checker prompted to write a gap log, a query rewriter, and a synthesizer. If you are an enterprise on Gemini Enterprise Agent Platform: Cross-Corpus Retrieval is in public preview now and the FramesQA numbers are worth validating against your own document corpus, especially the cross-corpus database-selection accuracy since that is the multi-source case standard RAG handles worst. If you are evaluating buy-versus-build for agentic RAG: this release is the buy option getting concretely better, and the question is whether the 3% latency overhead and the platform lock-in are worth not having to build and maintain the five-agent loop yourself. And if you are tracking the agent-runtime consolidation thread, note where this shipped: not as an open framework or a research artifact, but as a rented capability inside the enterprise runtime, which is exactly the layer the major vendors are racing to own.