Notas do Cloud Next 2026: Por Que Seu Agente Precisa de um Grafo de Contexto

Post 5 de 5 das minhas notas de campo do Cloud Next 2026. Esta foi a sessão de que voltei mais genuinamente útil — não porque algo nela fosse novo, mas porque os palestrantes rodaram um experimento ao vivo limpo que mostrou algo que muitos times suspeitam, mas raramente demonstram. Quero manter o tom humilde, porque o princípio que articularam é algo que muitos profissionais chegaram por conta própria. O valor estava em ver a mesma pergunta receber uma resposta errada e depois uma resposta certa, com apenas a camada de contexto mudando.

A sessão foi dada por um time corporativo de plataforma de dados apresentando o trabalho deles com o Google. Não vou nomeá-los — eles não se apresentaram formalmente no palco, e não quero inventar afiliações. Havia também um representante de partner engineering do Google no painel. O trabalho descrito abaixo é deles. A leitura é minha.

A Montagem da Demo

Conectaram um agente a dois data products: um data product de NPS e um data product de customer lifetime value. Cerca de quinze tabelas no total, o tipo de espalhamento que existe em qualquer warehouse corporativo real. Aí fizeram ao agente uma única pergunta de negócio difícil:

Se a satisfação do cliente sobe um ponto, qual é o ganho líquido de receita?

Essa não é uma pergunta de “select sum from table”. Atravessa dois data products. Exige que o agente entenda que satisfação do cliente significa NPS dentro do produto de satisfação, que receita significa lifetime value dentro do produto de CLV, que os dois se conectam no nível do cliente, e que “líquido” implica um delta contra uma baseline. É o tipo de pergunta sobre a qual um bom analista pensaria por dez minutos antes de escrever SQL.

A Primeira Tentativa: Apenas Metadado

Na primeira rodada o agente tinha acesso apenas ao metadado de tabela padrão que se obtém de fábrica do BigQuery — nomes de colunas, tipos de dados, contagens de linhas, uma string de descrição. O agente fez o que esses sistemas fazem quando estão confiantes e errados. Pegou a tabela mãe do produto de NPS, achou uma coluna que conseguiu correlacionar com algo que interpretou como receita, fez a aritmética e devolveu um número.

O número estava errado. Mais importante: o agente nunca chegou às tabelas de CLV. Ficou preso na tabela mãe do produto de satisfação, tratou aquilo como o mundo inteiro e respondeu com convicção. Esse é o modo de falha que continuo vendo times encontrarem. Não é “o modelo não consegue raciocinar” — o modelo raciocina. O raciocínio só estava sobre um mapa incompleto do território.

A Segunda Tentativa: Três Sinais

Aí adicionaram três coisas ao contexto do agente:

Um glossário de negócio. O que “satisfação do cliente” significa nesta organização? Significa NPS, medido mensalmente, na entidade cliente. O que “ganho de receita” significa? Significa delta de CLV, medido contra um período de baseline. O glossário é curto. É linguagem direta. Não vive em um banco de grafos. Vive em um documento.
Metadado gerado por IA, sobreposto ao schema das tabelas. Não apenas “está coluna é INT64”. Mais próximo de: está coluna representa o NPS do cliente para o período mais recente de medição; nulos indicam não-respondentes e devem ser excluídos do cálculo de ganho. É metadado que sabe para que o dado serve, não só o que ele é.
Joins de lineage entre data products. O lineage técnico de como o dado fluiu dos eventos brutos até o produto de NPS e o produto de CLV, mais os joins entre produtos que os conectavam na entidade cliente. Isso veio direto do BigQuery e do dataform — a engine já conhecia o lineage; o agente apenas não tinha acesso a ele.

Mesmo agente. Mesma pergunta. Resposta diferente. Correta, com navegação rastreável entre os dois produtos.

A Fórmula

O palestrante escreveu no palco uma fórmula que copiei no caderno porque é a versão mais limpa dessa ideia que já vi escrita:

Qualidade da resposta do agente = f(metadado + navegação)

Metadado é a fonte da verdade sobre entidades — o que são as colunas, o que significam, quais são suas fronteiras. Navegação é como se vai de uma pergunta em linguagem de negócio até as entidades certas, atravessando data products. A maioria das demos de “IA sobre seus dados” entrega ao agente metadado e para por aí. Por isso falham em perguntas que cruzam produtos: metadado sem navegação é dicionário sem mapa.

O enquadramento que acho útil: metadado responde “o que é isso”, navegação responde “como chego lá daqui”. Um agente de relatórios que só sabe a primeira coisa vai produzir números confiantemente errados em qualquer pergunta que cruze uma fronteira — que é a maior parte das perguntas que valem a pena fazer.

Dois Grafos

Eles distinguiram com clareza entre dois grafos que muitas vezes ficam misturados quando times dizem “grafo de conhecimento”:

Grafo de lineage. Técnico. Como o dado flui pelas transformações da origem até o produto. A maioria das empresas com um stack moderno já tem isso, mesmo que não tenha exposto. BigQuery e dataform produzem isso como subproduto de operar o warehouse. Expor para o agente é um trabalho de integração, não de modelagem.

Grafo de contexto. Negócio. Como conceitos se relacionam na linguagem da organização. NPS pertence a satisfação. CLV pertence a receita. Cliente é a entidade de junção. “Ganho” é um delta. Este grafo é onde a maioria das empresas não tem nada. Não porque seja difícil de construir — porque ninguém ficou responsável por construí-lo.

Quando o palestrante disse “grafos de conhecimento”, ele tomou cuidado: grafos de conhecimento não são uma coisa única, e certamente não são sinônimo de banco de grafos. Ele os enquadrou como uma camada que “me ajuda a mapear onde ir para obter conhecimento e se tenho o contexto certo para usá-lo corretamente”. Essa frase é a que quero pressionar, porque ela muda o que você está construindo. Você não está construindo um grafo. Está construindo uma camada de navegação sobre artefatos que já existem.

A Parte Contraintuitiva

Aqui está o achado que eu não esperava de uma sessão do Google, e é a parte que a maioria dos times vai errar se ler só um resumo:

Contexto demais não é bom. Contexto demais faz o agente alucinar. Adote uma abordagem minimalista.

O instinto, quando o agente erra, é dar mais a ele. Mais tabelas, mais descrições de coluna, mais documentação, mais consultas de exemplo, mais tudo. A experiência do palestrante — e bati nisso no nosso próprio trabalho com clientes — é que mais contexto expande a superfície sobre a qual o modelo pode alucinar. O modelo encontra um fragmento de contexto irrelevante, trata como estrutural, e agora você tem uma resposta confiantemente errada com um rastro mais longo.

O contexto certo é pequeno. O contexto errado é tudo o que você tem. A disciplina de construir um grafo de contexto é a disciplina de escolher o que não incluir.

Uma Recomendação Prática

A manchete que quero deixar é simples, e acho que é a parte mais acionável para qualquer time que assistiu uma demo desse tipo e sentiu que estava além do seu stack: você pode começar seu grafo de contexto como um glossário de negócio em markdown. Não precisa de banco de grafos. Não precisa de Neo4j. Não precisa de vector store.

Abra um arquivo markdown. Escreva seus vinte principais conceitos de negócio em linguagem direta. Para cada um, nomeie a entidade onde vive, o data product que o detém e como ele se compõe com outros conceitos. Faça commit no mesmo repositório que detém suas transformações de dados. Faça desse documento o que um analista entregaria para alguém recém-contratado no primeiro dia — esse documento, somado ao lineage que seu warehouse já produz, é a maior parte do que um agente precisa para parar de estar confiantemente errado.

Subir depois para um banco de grafos é detalhe de implementação. O investimento em um grafo de contexto é pequeno. Ele se paga no momento em que um agente de relatórios tem que responder uma pergunta do tipo “por que esse número se mexeu?” envolvendo mais de um data product. O que, em qualquer organização com que trabalhei, é a maioria das perguntas que de fato importam.

A melhor demo que vi no Cloud Next 2026 não foi um lançamento de modelo. Foi um time mostrando, com duas rodadas da mesma pergunta, que os agentes que já temos funcionam — quando damos um mapa a eles.

Fontes

Google Cloud. “Google Cloud Next 2026.” Abril de 2026.
Google. “ADK Documentation.” Abril de 2026.
Notas pessoais do autor, presencial em Las Vegas.

A Victorino ajuda times a construir o grafo de contexto que transforma um agente confiante e errado num agente governado e navegável: contato@victorino.com.br | www.victorino.com.br