Google Research añadió un Sufficient Context Agent a la Gemini Enterprise Agent Platform el 8 de junio, shipeándolo como feature public-preview llamada Cross-Corpus Retrieval. El framework es RAG multi-agente, y su contribución distintiva es un agente específico en el pipeline cuyo único job es decidir si la evidence retrieved hasta ahora es realmente suficiente para responder la pregunta. El RAG estándar retrieve una vez y responde. Este framework corre cinco fases: un Root Agent parsea la request y delega, un RAG Agent fan-out queries paralelas a través de múltiples data sources, el Sufficient Context Agent inspecciona los snippets retrieved contra el prompt original, un Query Rewriter genera nuevas búsquedas dirigidas si se encuentran gaps, y un paso final de síntesis confirma la completitud antes de que el modelo tenga permitido generar. Los números que Google publicó: en FramesQA, un benchmark de 824 queries sobre 2.676 documentos PDF, el sistema alcanzó 90,1% de accuracy al seleccionar la database correcta de cuatro fuentes, entregó hasta 34% de mejora de factuality sobre un baseline RAG vanilla que él mismo usaba un advanced retrieval engine más un LLM parser más un re-ranker, y mantuvo la latencia dentro del 3% entre los modos single-corpus y cross-corpus.
El mecanismo que vale el examen es lo que el Sufficient Context Agent hace que lo distingue de un check de relevance o confidence estándar. Un quality gate RAG típico produce un binario o un score: relevant o no, confident o no, y cuando falla o responde de todos modos o retorna "insufficient context" y para. El Sufficient Context Agent hace algo más específico: cuando la evidence está incompleta, escribe un Reason and Feedback log que nombra el gap. No "insufficient" sino "encontré el server ID en el corpus A pero no las hardware specs, que deberían estar en una segunda database." Ese gap nombrado es lo que el Query Rewriter consume para generar la próxima búsqueda. La loop por lo tanto no es retrieve-score-retry con la misma query, es retrieve, diagnostica la pieza faltante específica, rewrite la query para apuntar a esa pieza, retrieve de nuevo. Los tres failure modes que apunta son concretos y familiares a cualquiera que haya shipeado RAG: answers parciales (encontraste la mitad de la respuesta en una fuente y paraste), premature not-found (la primera búsqueda volvió vacía así que el sistema se rindió), y hallucination (el context estaba incompleto así que el modelo guesseó para llenar el hueco). Nombrar el gap es lo que convierte un dead-end "no sé" en una búsqueda dirigida siguiente.
La lectura ecosistema es que esto es el mismo patrón de state-externalization que hemos trackeado, ahora aplicado al problema de knowing-what-you-don't-know, y shipeado en un runtime enterprise en vez de publicado como paper. Harness-1 externalizó el bookkeeping de retrieval en el ambiente. Memory OS externalizó la memoria de agente en seis capas tipadas. El Sufficient Context Agent externaliza el juicio de sufficiency en un agente dedicado con un log escrito, en vez de dejarlo como propiedad implícita de la confidence del generador. El contexto estratégico es que esto aterriza dentro de la Gemini Enterprise Agent Platform, el mismo tier enterprise donde viven los Managed Agents de Antigravity 2.0, lo cual significa que Google está ensamblando el stack de agente enterprise una capability externalizada a la vez: orchestration, retrieval, sufficiency-checking, query-rewriting, cada una un component nombrado en un runtime que rentas en vez de un prompt que escribes. Esa es la productization de la dirección de research agentic-RAG, y el número 34% de factuality es el argumento que están haciendo a los enterprise buyers que se quemaron por RAG-que-alucina-con-confidence en la primera ola.
Lunes por la mañana, si corres RAG en producción y tu failure mode son respuestas confident wrong en queries multi-hop: el patrón Sufficient Context es la arquitectura a estudiar, y el move de diseño clave es hacer que el sufficiency check nombre el gap específico en vez de emitir un binario, porque el gap nombrado es lo que hace la re-search dirigida en vez de repetitiva. Puedes construir este patrón tú mismo sin la plataforma Gemini, los components son un orquestador, un retriever paralelo, un sufficiency-checker prompteado para escribir un gap log, un query rewriter, y un synthesizer. Si eres una enterprise en Gemini Enterprise Agent Platform: Cross-Corpus Retrieval está en public preview ahora y los números FramesQA valen ser validados contra tu propio corpus de documentos, especialmente la accuracy de cross-corpus database-selection ya que es el caso multi-source que el RAG estándar maneja peor. Si evalúas buy-versus-build para agentic RAG: este release es la opción buy volviéndose concretamente mejor, y la pregunta es si el 3% de overhead de latencia y el platform lock-in valen el no tener que construir y mantener la loop de cinco agentes tú mismo. Y si trackeas el hilo de consolidación agent-runtime, nota dónde shipeó: no como framework open o artefacto de research, sino como capability rentada dentro del runtime enterprise, que es exactamente la capa que los vendors mayores racean para poseer.