Arthur Guttilla Head of Product Marketing, Strattum Com passagens na Amazon Web Services e no Google, Guttilla trabalhou diretamente com fundadores de startups e empresas de capital de risco, compreendendo as necessidades de empresas tecnológicas em estágio inicial na interseção entre tecnologia e negócios.
A empresa tem três agentes de IA rodando. Um responde ticket no suporte, outro monta briefing de conta antes da reunião comercial, o terceiro lê contrato. Cada um conectou as próprias fontes, guarda o próprio histórico e descobriu sozinho que aquele cliente aparece com três nomes em três sistemas. Nenhum dos três sabe o que os outros dois aprenderam. O que falta entre eles é um Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
A memória de um agente hoje costuma ser três coisas: o histórico das conversas dele, um índice vetorial próprio e um punhado de regras escritas no prompt por quem montou o projeto.
Quando alguém do suporte ensina ao agente de atendimento que a cláusula de SLA vigente é a do aditivo, e não a do contrato original, essa correção vira instrução dentro daquele agente. O agente do comercial continua citando o prazo antigo na semana seguinte.
Isso se repete em cada termo ambíguo do negócio. O que conta como churn, o que conta como pedido faturado, quem é a mesma empresa quando o CNPJ está no ERP e a razão social está no CRM. A empresa paga três vezes pela mesma modelagem, e as três versões divergem com o tempo. A pergunta que atravessa dois agentes volta com duas respostas, e ninguém consegue dizer qual está certa.
Armazenar mantém o documento disponível. Lembrar exige saber que aquele ticket é do mesmo cliente do contrato que vence em março e do pedido que atrasou na semana passada. Essa relação é o que um agente isolado não consegue produzir sozinho, porque ela vive entre sistemas que ele não enxerga inteiros.
Um Company Brain modela essa relação em três peças. O grafo de conhecimento guarda as entidades do negócio e as ligações entre elas: cliente, contrato, ticket, pedido, pessoa. A ontologia do negócio guarda o que cada termo significa nesta empresa específica, porque "cliente ativo" tem uma definição em vendas e outra em finanças. A camada semântica traduz a pergunta em linguagem natural para os dados corretos, com a permissão correta.
Modelado uma vez, esse conjunto deixa de ser propriedade de um agente e passa a ser infraestrutura dos próximos.
A decisão de arquitetura que sustenta o compartilhamento é servir o contexto em vez de copiá-lo. O brain é exposto aos modelos e agentes por um protocolo aberto de conexão entre modelos e fontes de dado, o MCP.
Na prática, cada agente pergunta ao mesmo lugar. O de suporte pede o contrato vigente daquele remetente. O comercial pede o histórico de tickets daquela conta. Os dois recebem o recorte que a pergunta exige, montado sobre o mesmo grafo, com a mesma definição de termo. Os dados permanecem no perímetro da empresa, e nenhuma cópia da base entra no provedor do modelo.
Quando alguém corrige a ontologia, a correção vale para os três agentes na mesma hora. O aprendizado deixa de morrer dentro da ferramenta onde aconteceu.
É aqui que a conta muda para quem decide onde colocar o próximo trimestre de engenharia.
Velocidade de implementação: as fontes são conectadas uma vez. O segundo caso de uso começa do grafo e da ontologia que já existem, sem abrir uma rodada nova de integração. O terceiro começa do segundo, sem nenhum time de dados ou de IA pagando de novo o custo de integração.
Custo: contexto que chega organizado é contexto menor. Menos token por chamada, menos retrabalho de prompt, e a chance de rodar a mesma tarefa em um modelo mais barato, porque o trabalho de descobrir o que importa saiu do raciocínio do modelo e foi para a camada que prepara o dado.
A objeção aparece rápido. Se todos os agentes leem do mesmo lugar, alguém acaba vendo o que não deveria.
A permissão vem do sistema de origem. Cada pessoa recebe pelo agente apenas o dado que o perfil dela já enxerga no ERP ou no CRM, e o agente do comercial não vira porta de entrada para a fatura que o vendedor nunca teve acesso. Nenhum projeto novo escreve controle de acesso do zero.
Cada resposta também aponta de qual sistema o dado veio, o que permite conferir antes de agir sobre ela.
Modelar entidade e fechar a definição de um termo é trabalho de gente que conhece o negócio, e a primeira versão da ontologia vai estar errada em algum ponto. Isso se corrige com uso, à medida que as perguntas reais mostram onde a modelagem não bate com a operação.
O brain também não inventa o que ninguém registrou. Se a etapa de expedição só existe numa planilha preenchida no fim do dia, o grafo fica com um buraco ali.
E os agentes continuam com memória própria de conversa. O histórico daquele atendimento específico pertence àquele agente. O que passa a ser comum é a estrutura do negócio embaixo dele.
Pegue um termo que dois dos seus agentes tratam de forma diferente hoje e escreva qual definição vale. Depois liste as cinco ou seis entidades que aparecem em quase toda pergunta da operação. Esse é o recorte inicial, e ele cabe em algumas semanas de trabalho.
Na Strattum, é assim que a gente entra: uma pergunta real, as fontes que ela exige, e o contexto modelado para servir também o próximo agente. Se quiser testar o recorte da sua, me chama aqui.
Fale com um especialista da Strattum sobre o recorte inicial: os termos, as entidades e as fontes que ele exige.