Por que agentes de IA dão respostas diferentes sobre os mesmos dados?

Por que agentes de IA dão respostas inconsistentes sobre os mesmos dados?

Porque a maioria dos agentes é conectada aos dados sem que alguém diga o que eles significam. Um protocolo como o Model Context Protocol (MCP) padroniza como um agente chega a uma fonte, mas não carrega nenhuma definição do que é um "cliente ativo", de qual data conta como receita, ou de se dois registros com nomes diferentes são a mesma empresa. Quando esse contexto falta, o modelo faz a única coisa que pode: preenche a lacuna com uma suposição plausível. Rode a mesma pergunta amanhã e a suposição muda, então o número muda junto.

A falha não é um modelo fraco. É a lógica de negócio sendo improvisada dentro de uma janela de contexto em vez de ser definida uma vez, nos dados.

Mesmo modelo, mesma pergunta, duas arquiteturas. Consultando as fontes diretamente, um agente acertou 38% das vezes, em 234 chamadas de ferramenta, em cerca de 15 minutos. Em uma camada de dados governada, o mesmo agente chegou a 91% de acurácia com uma única consulta SQL em 19 segundos. (Benchmark Nekt)

O MCP resolve isso?

Não. O MCP resolve a conexão, não o significado, e esses são problemas diferentes. Ele padroniza como um agente descobre e chama uma ferramenta, o que é um avanço real: antes dele, toda integração era sob medida, e depois dele a integração virou um protocolo. Mas saber como conversar com um sistema não é o mesmo que saber o que os dados dele significam. Uma fonte pode entregar a um agente o valor bruto de um campo. Ela não pode dizer ao agente que o campo está armazenado em milionésimos, ou que um negócio marcado como "ganho" há dois anos não deve ser contado como receita hoje. Esse conhecimento é contexto, e contexto não viaja no protocolo. Alguém precisa modelá-lo.

O que dá errado quando falta a camada semântica?

O agente vira um banco de dados improvisado feito de texto, e ele falha de quatro jeitos que nunca aparecem na demo. Pergunte "quanto custou cada cliente novo no último trimestre, por canal" e, sem nada por baixo, ele precisa paginar o CRM, puxar contatos (porque o canal fica no contato, não no negócio), puxar o investimento em anúncios de várias plataformas em vários formatos, puxar o faturamento para saber quem de fato pagou, e então juntar tudo isso lendo registros dentro da janela de contexto. Esse último passo é onde quebra: ele erra fusos horários, conta duplicados, estoura a janela e perde metade do que já tinha lido.

• Ele inventa a definição. Perguntado "quantos clientes ativos", sem regra ele cria uma: assinaturas ativas na segunda, negócios ganhos na quarta. Dois números defensáveis, ambos diferentes. Quem lê perde a confiança e volta para a planilha.
• Ele junta no lugar errado. Combinar tabelas é trabalho de banco de dados: chaves, índices, processamento. Fazer isso lendo dentro do contexto é caro e frágil, e é a principal fonte da explosão de tokens.
• O escopo vaza. Sem permissões por agente na camada de dados, o controle de acesso vira uma linha num prompt. Um prompt é um pedido educado, não um limite.
• O custo cresce com o volume, não com a pergunta. O conjunto de dados dobra, a conta de tokens dobra, e a resposta não melhora. É aqui que projetos morrem por orçamento, e não por engenharia.

A escala desse risco já está no radar dos analistas. A Gartner projeta que mais de 40% dos projetos de IA agêntica serão cancelados até o fim de 2027, citando custos crescentes, valor de negócio pouco claro e controles inadequados. Custo crescente e valor pouco claro são exatamente o que um caminho de dados sem governança produz.

Que camada de dados resolve isso?

Uma camada em três estágios, em que cada estágio tem uma única função, para que o agente leia significado em vez de reconstruí-lo. Os estágios:

• Raw guarda o que a fonte enviou, sem alterações, para que qualquer número possa ser auditado até a origem.
• Trusted concentra a limpeza que ninguém vê e de que todo mundo depende: deduplicação, tipos corretos, fusos horários corretos. Um exemplo real: quando dois registros são mesclados num CRM, o registro absorvido muitas vezes continua no Raw porque o conector nunca captura a exclusão, então contar a partir do Raw conta o mesmo cliente duas vezes. A regra que filtra isso vive no Trusted, escrita uma vez e aplicada a todo agente e todo relatório.
• Service é o dado modelado na linguagem do negócio: não "tabela de negócios", mas revenue_by_channel ou active_customers, uma tabela por pergunta que a empresa de fato faz. É aqui que o agente lê.

O efeito é que a inteligência sai do prompt e vai para o modelo de dados. O agente deixa de ser o lugar onde as regras de negócio vivem e volta a fazer o que faz bem: entender a pergunta em linguagem natural e escolher a tabela certa. Uma consulta, 19 segundos.

O que é Context Engineering, e por que agentes precisam disso?

Context Engineering é a prática de escrever o significado de negócio de uma coluna ao lado do próprio dado, para que um agente leia a regra em vez de adivinhá-la. Uma pessoa que vê uma coluna com nome estranho pergunta a um colega. Um agente não pergunta, ele deduz, e deduz com confiança. Então toda coluna que importa carrega uma anotação. Casos reais que quebram agentes sem isso:

• Custo de anúncio armazenado em milionésimos, em que uma unidade de moeda é 1.000.000. Sem a anotação, o agente reporta um custo por aquisição um milhão de vezes maior, e explica a crise de forma convincente.
• Tipo de e-mail, separando corporativo de pessoal. O corporativo converte entre 15% e 20%, o pessoal perto de 1%. Um agente que mistura os dois conclui que um canal saudável está quebrado.
• Ganhos históricos. Um cliente que cancelou ainda tem um ganho registrado naquele mês; se ele volta em outro ano, são dois. Sem a regra, o agente diz "nunca foi cliente" sobre alguém que está pagando agora.
• Qual data é a data. Criação, fechamento, primeira cobrança: três datas, três respostas para "quanto vendemos em junho", e uma delas vira a comissão de um vendedor.

Nada disso é dado. Tudo isso é contexto sobre o dado, e é exatamente o que um protocolo de conexão não carrega. A disciplina é antiga, já que dar significado aos dados sempre foi trabalho de dados. O que mudou foi o consumidor: antes era um analista que perguntava quando tinha dúvida, e agora é um agente que responde mesmo quando não sabe.

Na prática, esse contexto pode ser servido automaticamente. Quando um agente consulta a Nekt via MCP, ele recebe mais que a tabela. Recebe a definição junto: como a empresa mede o MRR, o que conta como cliente ativo, qual data vira receita. A regra de negócio chega embutida na resposta em vez de ficar por conta de um palpite bem escrito.

Como construir uma camada de dados para agentes de IA?

Comece pelas perguntas, não pelas ferramentas. A ordem que funciona:

1. Escreva as dez perguntas que o negócio de fato faz toda semana. Isso, e nada mais, é o escopo da camada Service.
2. Para cada pergunta, liste as fontes e a chave que as une. Se nenhuma chave aparece em todas, esse é o primeiro problema, e ele é anterior a qualquer IA.
3. Traga tudo bruto para o Raw, sem limpeza, para que possa ser auditado e reprocessado.
4. Escreva as regras trabalhosas no Trusted: deduplicação, fusos horários, tipos, registros mesclados, unidades de moeda. Uma vez, em código, versionado, nunca num prompt.
5. Modele o Service na linguagem do negócio, uma tabela por pergunta.
6. Anote o contexto em toda coluna sobre a qual uma pessoa precisaria perguntar.
7. Só então conecte o MCP, com permissões por agente e escopo mínimo. O MCP é o último passo, não o primeiro, e começar por ele é o motivo de tantos projetos de agentes travarem.

A conclusão não é "MCP ou camada semântica". São três coisas juntas: dados estruturados por baixo, MCP para conectar e Context Engineering para dar significado. Tire qualquer uma e o agente volta a adivinhar. O modelo é o mesmo com 38% e com 91%. O que muda é o que fica por baixo dele.