Company Brain: a arquitetura de contexto que tenta frear a alucinação de agentes de IA em produção

Conceito debatido no Vale do Silício propõe uma estrutura integrada de dados, regras e relações, organizada em camadas distintas, para que agentes de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → parem de inventar respostas diferentes para a mesma pergunta. Para quem constrói esses sistemas, é um nome novo para um problema de arquitetura bem conhecido.

O problema que todo time de IA em produção já viu

Três agentes, três respostas diferentes para "quantas vendas fechamos este mês". Quem já colocou mais de um agente de IA em produção reconhece o sintoma: cada um consulta uma fonte diferente, aplica uma regra de negócio que só ele conhece e entrega um número plausível, mas errado.

É esse o problema que o conceito de Company Brain tenta nomear, segundo artigo publicado na Exame por Antonio Duarte, CEO e cofundador da Nekt. A tese central é simples: agentes não têm a experiência tácita que um analista sênior acumula em anos de empresa, e por isso reproduzem erro em escala, não em exceção.

O que é, de fato, o Company Brain

Na prática, Company Brain não é produto, é um padrão de arquitetura: uma estrutura que reúne dados, processos e regras de negócio em formato consultável por humanos e por agentes. Para quem trabalha com dados, soa familiar, é a velha promessa do data catalog e do data mesh, só que agora com um consumidor novo e insaciável, o agente autônomo que roda a mesma consulta milhares de vezes sem supervisão.

A diferença prática está no que esse repositório precisa guardar. Não basta ter tabelas e documentos, é preciso capturar o que normalmente fica só na cabeça de quem opera o negócio: o critério que define uma venda como concluída, a fórmula usada para calcular um indicador, o procedimento adotado quando um cliente pede cancelamento. Sem isso, o agente preenche a lacuna com inferência, e inferência de modelo de linguagem sobre regra de negócio é receita de alucinação.

As quatro camadas, traduzidas em arquitetura

O material da Exame descreve o Company Brain em quatro camadas, que mapeiam quase direto para decisões de arquitetura que qualquer time de plataforma de dados já discute:

• Ingestão: dados estruturados (CRM, ERP, planilhas) e não estruturados (e-mails, transcrições de reuniões, documentos internos) entram no sistema.
• Curadoria: histórico organizado, inconsistências corrigidas, dados preparados para consulta, o trabalho pesado de engenharia de dados↳Engenharia de dados43 conteúdosResolvendo desafios de Big Data com Ciência de Dados na UberData · abr 2019Análise de dados com Python e tabelas dinâmicas com PandasData · mai 2019Ferramentas para análise de dados são cada vez mais fundamentais para auxiliar pessoas desenvolvedorasData · jun 2024Ver tudo em Data → que raramente aparece em slide de board.
• Context graph: a camada nova de verdade. Aqui ficam as relações entre dados e regras de negócio, o significado de cada indicador, os processos documentados. É um grafo de conhecimento aplicado a semântica corporativa, não só a entidades.
• Acesso controlado: agentes consomem essas informações via APIs e MCP, com permissão específica por atividade.

A camada que de fato diferencia Company Brain de um data warehouse bem feito é a terceira. Um data warehouse guarda o quê; o context graph guarda o porquê e o como, e é esse metadado semântico que o agente usa para não inventar a resposta quando o dado bruto é ambíguo.

RAG, grafo de conhecimento ou fine-tuning: o que muda na prática

A fonte não entra em detalhe de implementação, mas a decisão técnica por trás de um context graph tem trade-offs que quem constrói já conhece de outros nomes. Vale comparar as três abordagens mais comuns para dar contexto de negócio a um agente:

O ponto prático: RAG puro resolve recuperação de texto, não resolve ambiguidade de regra de negócio. Fine-tuning engessa a regra dentro do modelo, o que é péssimo quando a política comercial muda todo trimestre. O context graph é mais caro de manter, mas é a única das três opções em que dá para auditar por que o agente respondeu o que respondeu, requisito que vira obrigatório assim que o agente participa de decisão com impacto financeiro.

Governança não é feature, é pré-requisito

O uso de MCP para dar acesso a agentes resolve conectividade, não resolve permissão. O artigo original é direto nisso: um agente que analisa dados comerciais pode precisar ler o CRM sem ter autorização para escrever nele, e um agente financeiro deve acessar só o subconjunto de dados da sua função.

Para quem projeta esse tipo de sistema, isso significa tratar cada agente como um principal de IAM, não como um script com chave de API genérica. Logging de toda ação executada deixa de ser boa prática e vira requisito de auditoria, principalmente quando o agente opera de forma contínua e sem humano no loop para cada chamada.

O caso Nekt: 20 agentes, 10 mil chamadas por mês

Segundo Duarte, a Nekt usa essa arquitetura internamente para suas próprias operações de go-to-market: mais de 20 agentes realizam cerca de 10 mil chamadas mensais, todos compartilhando o mesmo ambiente de dados e as mesmas definições de cliente, venda e resultado. Um desses agentes, dedicado a verificar inconsistências no CRM, já resolveu centenas de problemas sem intervenção humana.

O número interessa menos pelo volume e mais pelo que ele exige de manutenção: toda vez que a Nekt muda uma etapa do funil comercial ou um critério de atendimento, essa mudança precisa chegar ao context graph antes de chegar aos agentes. É o mesmo problema de schema drift que qualquer pipeline de dados enfrenta, só que agora o consumidor downstream toma decisão de negócio em vez de só gerar um relatório.

Quando não vale a pena construir isso

Montar um context graph com curadoria contínua é caro e lento para entregar valor. A própria fonte reconhece que empresas ainda estruturando suas primeiras operações têm prioridades mais urgentes. Os sinais de que vale investir são concretos: informações espalhadas em ferramentas diferentes sem fonte única da verdade, reuniões recorrentes só para decidir qual número está certo, dependência de uma ou duas pessoas que concentram conhecimento tácito, e desconfiança recorrente nas respostas que os agentes já produzem hoje.

Se nenhum desses sintomas aparece, o caminho mais barato continua sendo RAG bem feito sobre uma base de documentos razoavelmente organizada, com revisão humana nos pontos de decisão crítica. Company Brain resolve um problema real de escala, mas escala é exatamente o que falta para a maioria dos times que ainda têm dois ou três agentes rodando em produção.

O viés que vale registrar

Vale uma ressalva de leitura: o autor do artigo original é CEO e cofundador da Nekt, empresa que, segundo o próprio artigo, usa essa arquitetura internamente para organizar sua operação de go-to-market. Isso não invalida o diagnóstico, que reflete um problema técnico real e documentado em qualquer time que já rodou múltiplos agentes contra a mesma base, mas explica por que o texto soa mais como relato de prática interna do que como estudo de caso neutro e independente.

Quem avalia adotar a ideia deveria pedir o mesmo que pediria de qualquer fornecedor novo: benchmark de latência do context graph sob carga, e um plano claro de quem mantém a camada semântica atualizada quando a regra de negócio muda.

Fonte 1: Exame (https://exame.com/bussola/company-brain-o-que-e-o-conceito-que-ganha-forca-no-vale-do-silicio/)

Artigo de opinião "Company Brain: o que é o conceito que ganha força no Vale do Silício", publicado pela Exame (Bússola) em 5 de novembro de 2026, assinado por Antonio Duarte, CEO e cofundador da Nekt.

Fonte: Exame