Contexto que seu warehouse não alcança

As duas grandes plataformas de dados chegaram ao mesmo diagnóstico, e acho que é o correto. A Databricks passou o seu summit defendendo que a IA tem um problema de contexto, não de inteligência, e que esse problema de contexto é o que explica por que os agentes têm desempenho ruim. A Snowflake está vendendo o Agentic Enterprise com a mesma premissa: que as empresas vão rodar frotas de agentes e a plataforma que os fundamenta vence.

As duas investiram pesado nisso. Modelos semânticos e definições de métricas para que todos concordem sobre o que uma métrica mede. Glossários e domínios para que um agente tenha uma definição autoritativa. Linhagem, histórico de consultas, catálogos, governança sobre o que um agente pode acessar. Ontologias que se aprimoram sozinhas a partir do que a plataforma observa. É o trabalho de engenharia mais consistente que já se fez sobre fundamentação de contexto.

Pense no que essas fontes de contexto têm em comum. Pipelines, logs de consultas, linhagem de tabelas, definições de métricas, objetos governados. Todas elas são estruturadas, e as que se aprimoram sozinhas melhoram a partir do que a plataforma consegue enxergar, que é o data warehouse.

Esse é o limite.

Onde o significado é decidido

Pense no que acontece quando um número muda de significado.

Alguém numa thread diz que o churn deveria excluir as contas que migramos. O financeiro concorda numa resposta. Está decidido, mas o modelo semântico só fica sabendo disso quando alguém se lembra de atualizar o objeto governado, o que pode levar dias, semanas, ou, pior, nunca acontecer. Até lá, todo agente fundamentado no catálogo responde com a definição antiga, governada e consistente, mas errada, o que é uma falha pior do que dar uma resposta obviamente quebrada, porque nada nela parece errado.

O mesmo vale para tudo que uma empresa decide em vez de calcular. Quem é o responsável pelas renovações agora. Qual conta está encolhendo silenciosamente. Por que a meta do Q3 mudou. O que foi combinado sobre a reclamação. Nada disso nasce como dado estruturado, e boa parte chega de fora: um cliente menciona os planos de expansão numa ligação, a nova entidade de faturamento dele aparece numa assinatura de e-mail, a conta que está recuando nunca diz isso abertamente, e você só percebe lendo cinco threads diferentes em conjunto.

Isso é conhecimento operacional, e ele fica entre os dois tipos de conhecimento que as empresas já mantêm. Os registros estruturados vivem nos sistemas criados para eles. O conhecimento canônico, a missão, o posicionamento, os playbooks, muda raramente e sobrevive em documentos curados. O conhecimento operacional não é nem um nem outro. Ele nasce em texto, fica desatualizado em semanas, e, se chega a algum lugar, esse lugar é uma wiki.

E isso só acontece se alguém escrever, e quase ninguém escreve. Não porque as pessoas são preguiçosas. Porque não é trabalho de ninguém, não tem prazo, e quem sabe já sabe. É por isso que wikis apodrecem.

Então a plataforma consegue dizer a um agente o que aconteceu com total autoridade, mas estruturalmente não consegue dizer a ele o porquê, nem o que o cliente disse na semana passada. Os dois vivem em texto ao qual a plataforma não tem acesso.

Recuperar não é o mesmo que saber

A objeção óbvia é que dados não estruturados já estão no roadmap. A Snowflake comprou a Datavolo em 2024 exatamente por isso, uma camada de pipeline construída sobre o Apache NiFi que move documentos e outras fontes não estruturadas para dentro da plataforma. A própria descrição da Snowflake sobre o negócio foi que ele aprofundava o serviço deles na “bronze layer” do ciclo de vida dos dados, que é a camada bruta onde os dados chegam. O Cortex Search então recupera a partir do que chega ali.

A Databricks chega ao mesmo lugar por um caminho diferente. Os volumes do Unity Catalog guardam arquivos de qualquer formato ao lado das suas tabelas, sob a mesma governança, e as ferramentas de recuperação dela leem esses arquivos.

Essas ferramentas resolvem parte do problema: trazem o texto para dentro e o colocam em algum lugar governado. Mas não mudam a definição de churn que foi discutida por e-mail. O que as duas plataformas têm depois disso é um corpus pesquisável de mensagens, e consultar um corpus não é o mesmo que ter uma resposta atualizada.

Recuperar informação a partir de mensagens brutas se parece com arqueologia. Você escava, encontra algo que corresponde à consulta, e nada garante que o que você encontrou é a versão mais recente. A thread em que o preço foi proposto e a thread em que ele foi fechado correspondem igualmente a uma consulta sobre preço, e a que é mais fácil de recuperar não é necessariamente a que é verdadeira agora. Pergunte de novo no mês seguinte, sobre um corpus que cresceu, e você pode obter uma resposta diferente com a mesma confiança.

Recuperar informação a partir de conclusões mantidas é lembrar. A diferença está no corpus por baixo, não na recuperação em si. Um é um registro indiferenciado de tudo que alguém já disse. O outro é um conjunto menor de afirmações que alguém decidiu que são verdadeiras no momento, cada uma com um histórico por trás que uma pessoa pode corrigir.

Um artefato de autoria manual também não resolve, como as próprias plataformas de dados já sabem por seus glossários. Um modelo semântico é mantido à mão, e artefatos mantidos à mão apodrecem do mesmo jeito que wikis apodrecem, pelo mesmo motivo: a transcrição nunca acontece.

A camada que falta

O que fica entre essas duas coisas é algo que lê as comunicações continuamente, propõe o que mudou, e pede para uma pessoa confirmar. Não é um índice de busca sobre os e-mails, e não é um documento que pertence a alguém.

É isso que construímos. Um brain, que é um conjunto de páginas contendo o que uma empresa sabe, montado a partir das mensagens que ela já tem em Gmail, Outlook, Slack, Microsoft Teams e Google Chat, mantido atualizado por workflows que escrevem de volta nele enquanto rodam, com uma pessoa aprovando ou editando cada atualização, e cada empresa decidindo por quanto tempo manter essa etapa de aprovação no processo.

Isso permite a junção com os dados do data warehouse. Quando o financeiro redefine churn numa thread, o brain lê essa thread e pode propor a atualização do modelo semântico no mesmo dia, para uma pessoa aprovar. Esse é um caminho de escrita que o glossário não tem. O data warehouse continua sendo a autoridade sobre o que aconteceu. A camada acima dele registra por que aconteceu, e quando esse motivo foi confirmado pela última vez.

Se a qualidade dos agentes é um problema de contexto, o contexto que vive nas comunicações é a metade ainda não resolvida desse problema.