Google Research a ajouté un Sufficient Context Agent à la Gemini Enterprise Agent Platform le 8 juin, le shipant comme feature public-preview appelée Cross-Corpus Retrieval. Le framework est du RAG multi-agent, et sa contribution distinctive est un agent spécifique dans le pipeline dont le seul job est de décider si l'evidence retrieved jusqu'ici est vraiment assez pour répondre à la question. Le RAG standard retrieve une fois et répond. Ce framework roule cinq phases : un Root Agent parse la requête et délègue, un RAG Agent fan-out des queries parallèles à travers de multiples data sources, le Sufficient Context Agent inspecte les snippets retrieved contre le prompt original, un Query Rewriter génère de nouvelles recherches ciblées si des gaps sont trouvés, et une étape finale de synthèse confirme la complétude avant que le modèle ait le droit de générer. Les numbers que Google a publiés : sur FramesQA, un benchmark de 824 queries sur 2 676 documents PDF, le système a atteint 90,1% d'accuracy à sélectionner la bonne database sur quatre sources, a delivré jusqu'à 34% d'amélioration de factuality sur un baseline RAG vanilla qui lui-même utilisait un advanced retrieval engine plus un LLM parser plus un re-ranker, et a gardé la latence à 3% entre les modes single-corpus et cross-corpus.

Le mécanisme qui vaut l'examen c'est ce que le Sufficient Context Agent fait qui le distingue d'un check de relevance ou confidence standard. Un quality gate RAG typique produit un binaire ou un score : relevant ou pas, confident ou pas, et quand il fail il soit répond quand même soit retourne "insufficient context" et stoppe. Le Sufficient Context Agent fait quelque chose de plus spécifique : quand l'evidence est incomplète, il écrit un Reason and Feedback log qui nomme le gap. Pas "insufficient" mais "trouvé le server ID dans le corpus A mais pas les hardware specs, qui devraient être dans une deuxième database." Ce gap nommé c'est ce que le Query Rewriter consomme pour générer la prochaine recherche. La loop n'est donc pas retrieve-score-retry avec la même query, c'est retrieve, diagnose la pièce manquante spécifique, rewrite la query pour cibler cette pièce, retrieve encore. Les trois failure modes qu'il cible sont concrets et familiers à n'importe qui qui a shipé du RAG : answers partiels (t'as trouvé la moitié de la réponse dans une source et stoppé), premature not-found (la première recherche est revenue vide donc le système a abandonné), et hallucination (le context était incomplet donc le modèle a guessé pour remplir le trou). Nommer le gap c'est ce qui convertit un dead-end "je sais pas" en une recherche dirigée suivante.

La lecture écosystème c'est que c'est le même pattern de state-externalization qu'on a tracké, maintenant appliqué au problème de knowing-what-you-don't-know, et shipé dans un runtime enterprise plutôt que publié comme paper. Harness-1 a externalisé le bookkeeping de retrieval dans l'environnement. Memory OS a externalisé la mémoire d'agent dans six couches typées. Le Sufficient Context Agent externalise le jugement de sufficiency dans un agent dédié avec un log écrit, au lieu de le laisser comme propriété implicite de la confidence du générateur. Le contexte stratégique c'est que ça atterrit dans la Gemini Enterprise Agent Platform, le même tier enterprise où les Managed Agents d'Antigravity 2.0 vivent, ce qui veut dire que Google assemble le stack d'agent enterprise une capability externalisée à la fois : orchestration, retrieval, sufficiency-checking, query-rewriting, chacune un component nommé dans un runtime que tu loues plutôt qu'un prompt que tu écris. C'est la productization de la direction de research agentic-RAG, et le numéro 34% de factuality est l'argument qu'ils font aux enterprise buyers qui se sont fait brûler par du RAG-qui-hallucine-avec-confidence dans la première vague.

Lundi matin, si tu roules du RAG en production et ton failure mode c'est des réponses confident wrong sur des queries multi-hop : le pattern Sufficient Context est l'architecture à étudier, et le move de design clé c'est faire que le sufficiency check nomme le gap spécifique plutôt qu'émette un binaire, parce que le gap nommé c'est ce qui rend la re-search ciblée au lieu de répétitive. Tu peux bâtir ce pattern toi-même sans la plateforme Gemini, les components sont un orchestrateur, un retriever parallèle, un sufficiency-checker prompté pour écrire un gap log, un query rewriter, et un synthesizer. Si t'es une enterprise sur Gemini Enterprise Agent Platform : Cross-Corpus Retrieval est en public preview maintenant et les numbers FramesQA valent d'être validés contre ton propre corpus de documents, surtout l'accuracy de cross-corpus database-selection puisque c'est le cas multi-source que le RAG standard gère le pire. Si tu evalues buy-versus-build pour de l'agentic RAG : cette release c'est l'option buy qui devient concrètement meilleure, et la question c'est si le 3% d'overhead de latence et le platform lock-in valent le fait de pas avoir à bâtir et maintenir la loop à cinq agents toi-même. Et si tu tracks le thread de consolidation agent-runtime, note où ça a shipé : pas comme framework open ou artefact de research, mais comme capability louée dans le runtime enterprise, qui est exactement la couche que les vendors majeurs racent pour owner.