Google Research ने 8 जून को Gemini Enterprise Agent Platform में एक Sufficient Context Agent जोड़ा, इसे Cross-Corpus Retrieval नामक public-preview feature के रूप में ship किया। Framework multi-agent RAG है, और इसका विशिष्ट योगदान pipeline में एक specific agent है जिसका एकमात्र काम यह तय करना है कि अब तक retrieved evidence सवाल का जवाब देने के लिए वास्तव में पर्याप्त है या नहीं। Standard RAG एक बार retrieve करता है और जवाब देता है। यह framework पाँच phases चलाता है: एक Root Agent request को parse करता है और delegate करता है, एक RAG Agent कई data sources में parallel queries fan-out करता है, Sufficient Context Agent retrieved snippets को original prompt के विरुद्ध inspect करता है, अगर gaps मिलते हैं तो एक Query Rewriter नई targeted searches generate करता है, और एक final synthesis step model को generate करने की अनुमति देने से पहले completeness की पुष्टि करता है। Google ने जो numbers publish किए: FramesQA पर, 2,676 PDF documents पर 824 queries का एक benchmark, system ने चार sources में से सही database चुनते हुए 90.1% accuracy हासिल की, एक vanilla RAG baseline पर 34% तक factuality improvement दिया जो खुद एक advanced retrieval engine plus एक LLM parser plus एक re-ranker का उपयोग करता था, और latency को single-corpus और cross-corpus modes के बीच 3% के भीतर रखा।
जांचने योग्य mechanism यह है कि Sufficient Context Agent क्या करता है जो इसे एक standard relevance या confidence check से अलग करता है। एक typical RAG quality gate एक binary या एक score produce करता है: relevant या नहीं, confident या नहीं, और जब यह fail होता है तो या तो वैसे भी जवाब देता है या "insufficient context" return करता है और रुक जाता है। Sufficient Context Agent कुछ अधिक specific करता है: जब evidence अधूरी होती है, यह एक Reason and Feedback log लिखता है जो gap का नाम लेता है। "insufficient" नहीं बल्कि "corpus A में server ID मिला लेकिन hardware specs नहीं, जो एक दूसरी database में होने चाहिए।" वह named gap वही है जो Query Rewriter अगली search generate करने के लिए consume करता है। Loop इसलिए उसी query के साथ retrieve-score-retry नहीं है, यह retrieve, specific missing piece का diagnose, उस piece को target करने के लिए query को rewrite, फिर से retrieve है। यह जिन तीन failure modes को target करता है वे concrete और किसी भी ऐसे व्यक्ति के लिए familiar हैं जिसने RAG ship किया है: partial answers (तुमने एक source में आधा जवाब पाया और रुक गए), premature not-found (पहली search खाली लौटी इसलिए system ने हार मान ली), और hallucination (context अधूरा था इसलिए model ने छेद भरने के लिए guess किया)। Gap का नाम लेना वही है जो एक dead-end "मैं नहीं जानता" को एक directed अगली search में बदलता है।
Ecosystem reading यह है कि यह वही state-externalization pattern है जिसे हम track करते रहे हैं, अब knowing-what-you-don't-know problem पर लागू, और एक paper के रूप में publish करने के बजाय एक enterprise runtime में ship किया गया। Harness-1 ने retrieval bookkeeping को environment में externalize किया। Memory OS ने agent memory को छह typed layers में externalize किया। Sufficient Context Agent sufficiency judgment को एक written log के साथ एक dedicated agent में externalize करता है, इसे generator के confidence की implicit property के रूप में छोड़ने के बजाय। Strategic context यह है कि यह Gemini Enterprise Agent Platform के अंदर land करता है, वही enterprise tier जहाँ Antigravity 2.0 के Managed Agents रहते हैं, जिसका मतलब Google एक बार में एक externalized capability enterprise agent stack को assemble कर रहा है: orchestration, retrieval, sufficiency-checking, query-rewriting, प्रत्येक एक runtime में एक named component जिसे तुम rent करते हो बजाय एक prompt जो तुम लिखते हो। यह agentic-RAG research direction का productization है, और 34% factuality number वह argument है जो वे उन enterprise buyers को दे रहे हैं जो पहली लहर में RAG-जो-आत्मविश्वास-से-hallucinate-करता-है से जल गए।
सोमवार सुबह, अगर तुम production में RAG चलाते हो और तुम्हारा failure mode multi-hop queries पर confident गलत जवाब है: Sufficient Context pattern अध्ययन करने योग्य architecture है, और key design move यह है कि sufficiency check को specific gap का नाम लेना बनाना बजाय एक binary emit करने के, क्योंकि named gap वही है जो re-search को repetitive के बजाय targeted बनाता है। तुम इस pattern को Gemini platform के बिना खुद बना सकते हो, components एक orchestrator, एक parallel retriever, एक gap log लिखने के लिए prompt किया गया sufficiency-checker, एक query rewriter, और एक synthesizer हैं। अगर तुम Gemini Enterprise Agent Platform पर एक enterprise हो: Cross-Corpus Retrieval अब public preview में है और FramesQA numbers तुम्हारे अपने document corpus के विरुद्ध validate करने लायक हैं, खासकर cross-corpus database-selection accuracy क्योंकि वह multi-source case है जिसे standard RAG सबसे खराब handle करता है। अगर तुम agentic RAG के लिए buy-versus-build evaluate करते हो: यह release buy option का concretely बेहतर होना है, और सवाल यह है कि क्या 3% latency overhead और platform lock-in उस five-agent loop को खुद बनाने और maintain न करने के लायक हैं। और अगर तुम agent-runtime consolidation thread को track करते हो, ध्यान दो यह कहाँ ship हुआ: एक open framework या research artifact के रूप में नहीं, बल्कि enterprise runtime के अंदर एक rented capability के रूप में, जो ठीक वह layer है जिसे प्रमुख vendors own करने के लिए दौड़ रहे हैं।