Google Research adicionou um Sufficient Context Agent à Gemini Enterprise Agent Platform em 8 de junho, shipando-o como feature public-preview chamada Cross-Corpus Retrieval. O framework é RAG multi-agente, e sua contribuição distintiva é um agente específico no pipeline cujo único job é decidir se a evidence retrieved até agora é realmente suficiente para responder a pergunta. O RAG padrão retrieve uma vez e responde. Este framework roda cinco fases: um Root Agent parseia a request e delega, um RAG Agent fan-out queries paralelas através de múltiplas data sources, o Sufficient Context Agent inspeciona os snippets retrieved contra o prompt original, um Query Rewriter gera novas buscas dirigidas se gaps são encontrados, e um passo final de síntese confirma a completude antes que o modelo tenha permissão de gerar. Os números que Google publicou: no FramesQA, um benchmark de 824 queries sobre 2.676 documentos PDF, o sistema atingiu 90,1% de accuracy ao selecionar a database correta de quatro fontes, entregou até 34% de melhoria de factuality sobre um baseline RAG vanilla que ele mesmo usava um advanced retrieval engine mais um LLM parser mais um re-ranker, e manteve a latência dentro de 3% entre os modos single-corpus e cross-corpus.

O mecanismo que vale o exame é o que o Sufficient Context Agent faz que o distingue de um check de relevance ou confidence padrão. Um quality gate RAG típico produz um binário ou um score: relevant ou não, confident ou não, e quando falha ou responde de qualquer jeito ou retorna "insufficient context" e para. O Sufficient Context Agent faz algo mais específico: quando a evidence está incompleta, escreve um Reason and Feedback log que nomeia o gap. Não "insufficient" mas "encontrei o server ID no corpus A mas não as hardware specs, que deveriam estar em uma segunda database." Esse gap nomeado é o que o Query Rewriter consome para gerar a próxima busca. A loop portanto não é retrieve-score-retry com a mesma query, é retrieve, diagnostica a peça faltante específica, rewrite a query para mirar essa peça, retrieve de novo. Os três failure modes que mira são concretos e familiares a qualquer um que tenha shipado RAG: answers parciais (você encontrou metade da resposta em uma fonte e parou), premature not-found (a primeira busca voltou vazia então o sistema desistiu), e hallucination (o context estava incompleto então o modelo guessou para preencher o buraco). Nomear o gap é o que converte um dead-end "não sei" em uma busca dirigida seguinte.

A leitura ecossistema é que isso é o mesmo padrão de state-externalization que temos trackeado, agora aplicado ao problema de knowing-what-you-don't-know, e shipado em um runtime enterprise em vez de publicado como paper. Harness-1 externalizou o bookkeeping de retrieval no ambiente. Memory OS externalizou a memória de agente em seis camadas tipadas. O Sufficient Context Agent externaliza o julgamento de sufficiency em um agente dedicado com um log escrito, em vez de deixá-lo como propriedade implícita da confidence do gerador. O contexto estratégico é que isso aterrissa dentro da Gemini Enterprise Agent Platform, o mesmo tier enterprise onde vivem os Managed Agents do Antigravity 2.0, o que significa que Google está montando o stack de agente enterprise uma capability externalizada por vez: orchestration, retrieval, sufficiency-checking, query-rewriting, cada uma um component nomeado em um runtime que você aluga em vez de um prompt que você escreve. Essa é a productization da direção de research agentic-RAG, e o número 34% de factuality é o argumento que estão fazendo aos enterprise buyers que se queimaram por RAG-que-alucina-com-confidence na primeira onda.

Segunda-feira pela manhã, se você roda RAG em produção e seu failure mode são respostas confident wrong em queries multi-hop: o padrão Sufficient Context é a arquitetura a estudar, e o move de design chave é fazer o sufficiency check nomear o gap específico em vez de emitir um binário, porque o gap nomeado é o que faz a re-search dirigida em vez de repetitiva. Você pode construir este padrão você mesmo sem a plataforma Gemini, os components são um orquestrador, um retriever paralelo, um sufficiency-checker prompteado para escrever um gap log, um query rewriter, e um synthesizer. Se você é uma enterprise na Gemini Enterprise Agent Platform: Cross-Corpus Retrieval está em public preview agora e os números FramesQA valem ser validados contra seu próprio corpus de documentos, especialmente a accuracy de cross-corpus database-selection já que é o caso multi-source que o RAG padrão lida pior. Se você avalia buy-versus-build para agentic RAG: este release é a opção buy ficando concretamente melhor, e a pergunta é se o 3% de overhead de latência e o platform lock-in valem o não ter que construir e manter a loop de cinco agentes você mesmo. E se você tracka o fio de consolidação agent-runtime, note onde shipou: não como framework open ou artefato de research, mas como capability alugada dentro do runtime enterprise, que é exatamente a camada que os vendors maiores correm para possuir.