O contexto mais barato é o que seu agente nunca carrega. Google transforma a documentação em API para agentes

Uma suposição comum entre agentes de código: quanto mais documentação você coloca na frente do modelo, melhores são as respostas. Cole a referência completa da API, deixe o agente raspar algumas páginas, e a precisão vem junto.

Na maioria dos casos, não vem. Contexto grande e raspado é lento, caro e muitas vezes desatualizado: um post de fórum de dois anos atrás parece tão autoritativo para o modelo quanto a referência atual. Em 7 de outubro, o Google descreveu como é a alternativa para as próprias plataformas, e vale a leitura como contraexemplo dessa suposição.

O que o Google construiu no lugar

A Developer Knowledge API é, nas palavras do Google, sua fonte oficial e programática da verdade para a documentação de desenvolvedor sobre Google Cloud, Firebase, Android e mais. Ela oferece busca semântica e por palavra-chave, retrieval em chunks que devolve trechos relevantes em vez de páginas inteiras, respostas fundamentadas a perguntas e páginas completas em Markdown quando o agente precisa do texto completo. O Google diz que o índice é atualizado com frequência, então os agentes veem mudanças na documentação com pouca defasagem.

O acesso vem pela gcloud CLI (pré-instalada no Cloud Shell), por uma skill de agente via MCP que o Google lista para Antigravity, Claude Code, Cursor e GitHub Copilot, por bibliotecas de cliente em sete linguagens e por um API Explorer.

O workflow recomendado é a parte interessante: buscar chunks primeiro e só trazer páginas completas em Markdown quando necessário. O post do Google não classifica a API como em disponibilidade geral (GA) nem como preview, e também não informa preços. As quotas padrão documentadas são 100 buscas por chunks e 100 leituras de documentos por minuto por projeto, e 50 respostas fundamentadas por dia por projeto, então confira o status e os termos antes de construir pipelines de produção em cima disso.

Testando a suposição

Mais contexto não é mais precisão. Alguns trechos relevantes dão ao modelo menos texto irrelevante para atravessar. Escalar para uma página completa só quando os trechos não bastam costuma melhorar as respostas e cortar tokens ao mesmo tempo. Agentes já colocam carga pesada nos sistemas de dados, como descrevemos em nossa análise do caminho de dados dos agentes; o desenho do retrieval é onde boa parte dessa carga se decide.

A autoridade é uma propriedade do caminho, não do modelo. Um agente que recupera da documentação atual do próprio fornecedor tem menos chance de usar um parâmetro obsoleto do que um que raspa um fórum. Nenhum upgrade de modelo conserta um caminho de retrieval que aponta para a fonte errada.

Uma fonte para muitos agentes. Expor o mesmo conhecimento por CLI, MCP e bibliotecas significa que toda ferramenta de código da empresa lê a mesma verdade, em vez de cada uma construir seu próprio scraper.

O mesmo erro, dentro da empresa

Os times de plataforma internos têm o problema que o Google acabou de resolver para a própria documentação. Referências de API, runbooks, padrões de arquitetura e políticas de segurança vivem em wikis que os agentes raspam mal, ou são colados inteiros nos prompts.

A correção tem o mesmo formato. Publique o conhecimento interno como um serviço de retrieval, com busca, chunks e documentos completos, exposto via MCP para que todo agente aprovado o use; é a decisão de busca gerenciada que discutimos em nosso texto sobre o Compass, da Cohere, aplicada ao conhecimento interno. Dê a cada fonte um responsável e uma cadência de atualização, senão o agente vai recuperar verdades desatualizadas com muita confiança. Depois, meça o retrieval por si só, se o chunk certo voltou, e acompanhe os tokens gastos em contexto por tarefa, que costuma ser a maior linha da conta de um agente de código.

O contexto mais barato é aquele que seu agente nunca precisou carregar. O mais confiável é o que veio do dono da verdade.