Contexto governado agnóstico de fonte e runtime: a diferença que importa

Duas ferramentas chamaram atenção recentemente por atacar o mesmo problema de ângulos opostos. A RavenDB lançou o Quill, uma camada de contexto que roda em cima do banco SQL que a empresa já tem. A Glean anunciou o Tau, um espaço de trabalho no desktop que leva o agente para os arquivos, apps e código da máquina do usuário (a disponibilidade geral está prevista para o fim de 2026). Dois jeitos diferentes de dizer a mesma frase: “seus agentes precisam de contexto melhor”. Nenhum dos dois resolve a pergunta que vem logo depois, que é como provar de onde veio cada resposta.

Essa pergunta importa mais do que parece numa demo. Um CTO ou Head de IA que está prestes a colocar agentes em produção não quer só respostas plausíveis. Quer saber, depois do fato, qual fonte sustentou aquela resposta, se ela estava aprovada e atualizada, e quem tinha escopo para usá-la. É isso que separa um piloto que impressiona de um sistema que sobrevive a uma auditoria.

O que o Quill resolve, e o que ele não resolve

O Quill ataca um problema real: dado estruturado em SQL é difícil de consultar em linguagem natural, e colocar um agente para gerar queries direto contra produção é arriscado. A resposta da RavenDB foi colocar uma camada de contexto por cima do banco que já existe (PostgreSQL, SQL Server ou MySQL), sem migração, com busca, recuperação e os próprios agentes, e com controle do que cada agente pode ver independente das permissões do banco.

Isso resolve bem um caso específico: empresa com dado relacional centralizado, num desses bancos, e consulta que não sai do universo daquele banco. Fora desse caso, a cobertura cai. Documento, PDF, página de wiki interna, outro banco de um time diferente, tudo isso fica fora do que o Quill enxerga nativamente, porque a camada de contexto nasceu acoplada a uma fonte.

O problema não é a arquitetura em si. É a fronteira que ela herda. Quando contexto e fonte moram no mesmo lugar, o alcance do contexto para de ser uma escolha de governança e vira um acidente de onde o dado estava guardado. Uma empresa real raramente tem todo o conhecimento relevante dentro de um único banco. Tem contrato em PDF, política em wiki, ticket de suporte em outra ferramenta, planilha que ninguém documentou. Uma camada de contexto que só enxerga SQL cobre uma fatia, não a operação inteira.

E há uma segunda lacuna, mais silenciosa: proveniência pública. Controlar o que o agente pode ver é uma parte da resposta. O material público do lançamento não descreve um mecanismo auditável por fora do próprio produto que mostre, para cada resposta, qual trecho do banco foi usado, se aquele dado tinha aprovação de alguém com alçada e qual escopo valia naquele momento. A resposta pode estar correta. O que falta é o rastro que prova isso depois, para alguém que não escreveu a query.

Vale notar o que isso significa na prática do dia a dia de um time de dados. Uma tabela de clientes muda de esquema, um campo que antes guardava status ativo passa a guardar outra coisa, e ninguém avisou a camada de contexto. Com contexto acoplado ao banco, essa mudança se propaga direto para a resposta do agente, sem um ponto de controle no meio que pergunte “essa versão ainda é a aprovada?”. É a mesma lógica de uma planilha compartilhada sem controle de versão: funciona bem enquanto só uma pessoa mexe nela, e quebra silenciosamente assim que o time cresce.

O que o Tau resolve, e o que ele não resolve

O Tau ataca um problema diferente: onde a execução acontece. Ele leva o agente para a máquina do usuário, perto dos arquivos, dos apps e do código, ligado ao contexto corporativo que a Glean já indexa. É uma resposta legítima a uma dor real: boa parte do trabalho ainda mora no desktop, fora do alcance de um agente que só roda em nuvem.

Só que execução local resolve onde, não com quê. Um agente rodando no desktop ainda precisa de contexto para responder, e essa pergunta permanece em aberto: a fonte que ele consulta está aprovada? Está na versão certa? O escopo daquele agente bate com o que ele está acessando? Processar localmente não garante nada disso. Dá para rodar um agente local sobre um PDF desatualizado com a mesma facilidade que sobre um documento aprovado ontem.

Essa é a confusão comum entre dois problemas que parecem parecidos e não são: governança de execução e governança de contexto. A primeira pergunta onde o processamento roda e quem tem acesso à máquina. A segunda pergunta se o que o agente consome, não importa onde ele rode, passou por curadoria, tem versão ativa e deixa rastro depois de usado. Um produto pode ser exemplar na primeira e não tocar a segunda.

Um jeito simples de separar as duas camadas: pergunte o que acontece se o dispositivo for trocado. Se o agente local depende de um índice construído naquela máquina, migrar para outro notebook ou rodar o mesmo agente em nuvem para um caso de uso diferente significa reconstruir o contexto do zero. Isso é sinal de que contexto e execução não foram pensados como camadas separadas, foram empacotados juntos porque era mais simples de entregar assim.

As três propriedades que faltam nas duas abordagens

Contexto governado de verdade precisa de três coisas ao mesmo tempo, e isso é o que organiza a diferença entre preparar dado para um caso específico e preparar uma camada que serve qualquer agente, de qualquer lugar.

Agnóstico de fonte. A camada de contexto trata banco relacional, documento, página interna, planilha e API de terceiro pelo mesmo processo: entra como rascunho, passa por aprovação, vira fonte oficial com versão ativa. Não existe fonte de primeira classe (o banco nativo) e fonte de segunda classe (tudo o resto). Isso é o que permite que uma empresa com dado espalhado em seis sistemas diferentes tenha uma única trilha de governança, em vez de seis camadas de confiança desencontradas.

Agnóstico de runtime. O contexto preparado não pertence a um agente específico nem a um lugar de execução específico. Ele é servido via API, via MCP, ou via conector, para qualquer runtime que precise consumir: um agente rodando em nuvem, um rodando localmente, um orquestrador multiagente, uma integração do time de dados. Trocar de fornecedor de execução, ou rodar mais de um ao mesmo tempo, não exige reconstruir a base de conhecimento. O contexto fica parado; o que muda é só quem está perguntando.

Proveniência pública. Cada resposta carrega um rastro: qual fonte sustentou aquilo, qual era a versão ativa no momento, qual escopo foi aplicado, e um identificador de interação que amarra tudo isso. Esse rastro não é um relatório que o fornecedor promete gerar se pedirem; é parte estrutural de como o sistema responde, disponível para quem precisa auditar, não só para quem construiu o produto.

Essas três propriedades juntas são o que diferencia uma ferramenta de contexto de uma camada de contexto. A primeira resolve bem um caso de uso. A segunda vira infraestrutura sobre a qual a empresa inteira pode operar, agora e daqui a dois anos, quando a fonte de dados mudar ou o runtime de agente escolhido hoje for substituído por outro.

Por que isso importa mais com agentes em equipe

O risco de contexto acoplado a uma fonte ou amarrado a um runtime cresce quando o agente deixa de atender uma pessoa e passa a atender um time inteiro. Um analista que sabe que aquele banco SQL é a fonte “de verdade” consegue compensar mentalmente as lacunas. Um agente operando num canal compartilhado, respondendo para o time de vendas, o time de suporte e o jurídico ao mesmo tempo, não tem esse contexto humano de fundo. Ele responde com o que a camada de contexto entrega, e se essa camada só enxerga uma fatia da operação, o buraco fica invisível até alguém perguntar sobre o que está fora dela.

O mesmo vale para runtime. Uma empresa que hoje usa um agente de um fornecedor e no ano que vem adota outro, ou passa a rodar os dois em paralelo para casos diferentes, não deveria precisar refazer a aprovação de cada fonte porque a camada de contexto nasceu amarrada ao primeiro runtime. Esse é exatamente o tipo de retrabalho que uma arquitetura de engenharia de contexto bem desenhada evita desde o início: contexto e execução como camadas separadas, cada uma trocável sem derrubar a outra.

O que isso muda na prática para quem avalia essas ferramentas

Para quem está comparando opções, a pergunta certa não é “qual ferramenta tem a melhor busca semântica” nem “qual roda mais rápido no meu desktop”. É: se eu trocar de banco, de formato de documento ou de runtime de agente daqui a um ano, minha camada de contexto sobrevive, ou preciso recomeçar?

Vale testar isso com perguntas concretas. A camada de contexto aceita fonte fora do banco nativo sem gambiarra? Existe um conceito de aprovação e versão ativa que se aplica igual a qualquer fonte, ou só ao formato que o produto nasceu suportando? Dá para trocar o agente que consome esse contexto sem reconstruir a base? E, a pergunta que mais separa marketing de arquitetura: quando algo dá errado, existe um rastro público, inspecionável por um auditor, que mostra qual fonte, qual versão e qual escopo sustentaram aquela resposta?

Essas perguntas costumam render respostas desconfortáveis, porque a maioria das ferramentas de contexto foi construída para resolver um caso de uso específico primeiro e virou plataforma depois, por pressão de mercado. Isso não é demérito, é como a maioria dos produtos nasce. O problema aparece quando a empresa que compra a ferramenta não percebe essa origem e assume que “contexto” já significa “contexto governado para qualquer fonte e qualquer agente”, quando na prática significa “contexto bem resolvido para o caso que o fornecedor otimizou primeiro”.

É essa combinação (fonte plugável, runtime plugável, proveniência exposta) que sustenta governança de agentes de IA de verdade, e não só uma busca mais inteligente sobre o banco que a empresa já tinha, ou um agente mais perto dos arquivos do desktop. Nenhuma das duas coisas é ruim. As duas resolvem um problema real. Só resolvem metade do problema, e a metade que falta é justamente a que um comitê de IA vai cobrar primeiro.

A Contextfy existe nesse espaço: uma camada de contexto que prepara, aprova, versiona e serve conhecimento de qualquer fonte, para qualquer agente consumir via REST, MCP ou conectores, com trilha de evidência por interação. A escolha de banco continua sendo do cliente. A escolha de runtime também. O que muda é que nenhuma das duas escolhas trava a governança do contexto que sustenta cada resposta.

Sua base de contexto depende de uma fonte ou de um runtime específico?

Vale a pergunta franca antes de assinar qualquer um desses contratos: se eu precisar trocar de banco, somar uma fonte que não é SQL, ou rodar um segundo agente de outro fornecedor, minha camada de contexto atual acompanha, ou fica presa na escolha de hoje?

O Diagnóstico da Contextfy mapeia exatamente isso: onde seu contexto está acoplado a uma fonte ou a um runtime específico, e o que falta para ele virar uma camada agnóstica, auditável e pronta para qualquer agente que a empresa decidir usar.

Avaliar se meu contexto está preso a uma fonte ou runtime

---

RavenDB, Quill, Glean, Tau e demais marcas citadas pertencem a seus respectivos proprietários. A Contextfy é uma camada independente de contexto governado e não declara parceria oficial, certificação ou integração nativa, salvo quando explicitamente informado. Esta comparação descreve posicionamento público de categoria, não uma avaliação técnica exaustiva dos produtos citados.