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.
Em resumo
Um agente prepara a proposta de renovação de um cliente e precisa do desconto vigente. O CRM tem o desconto que o vendedor negociou, o contrato assinado tem outro e a tabela de preços do ERP aplica um terceiro. O agente usa o primeiro que encontra, e a proposta sai errada. Saber qual sistema fala por cada informação é o tema dos sistemas de registro. Com agentes, essa decisão precisa estar escrita, e registrá-la é uma das funções do Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
Um sistema de registro, ou system of record, é o sistema que a empresa reconhece como fonte oficial de um tipo de informação. O CRM costuma ser o registro de clientes e oportunidades, o ERP o de faturamento e contabilidade, o HRIS o de pessoas e a gestão de contratos o de cláusulas e vigências.
Outros sistemas guardam cópias, e a correção parte do registro oficial em direção a elas. Por isso o termo aparece associado à ideia de fonte da verdade.
Durante muito tempo, cada área escolheu os próprios sistemas de registro. Integrações ponto a ponto copiavam dados entre eles, e cada cópia envelhecia em um ritmo diferente.
A etapa seguinte foi a centralização analítica. Data warehouses e lakehouses passaram a reunir os dados de todos os sistemas, com modelos semânticos e regras de governança. Esse repositório mostra o que aconteceu, enquanto a operação continua nos sistemas de origem.
O arranjo funcionava porque quem atravessava os sistemas era uma pessoa. A analista de faturamento sabia que o endereço do CRM costuma estar desatualizado e conferia no ERP. A regra existia na experiência dela.
Em uma análise publicada por Jamin Ball na newsletter Clouded Judgement em dezembro de 2025, a tese é que os agentes elevam o padrão do que se espera de um bom sistema de registro.
O agente atravessa vários sistemas no mesmo fluxo, do pedido à cobrança, e grava alterações: abre pedidos, emite cobranças, atualiza cadastros. Um dado errado lido no começo do fluxo se propaga até o fim e entra em outros sistemas com aparência de informação confirmada.
Sem a experiência da analista, ele precisa de uma regra explícita sobre qual sistema é dono de cada informação e sobre o que fazer quando dois deles discordam.
Divergência entre sistemas de registro é comum. O HRIS, a folha de pagamento e o sistema de acessos podem apontar totais diferentes de colaboradores ativos, porque cada um trata de um jeito afastamentos, estagiários e desligamentos do mês. Cada número está certo dentro da própria regra, e o agente precisa saber qual usar em cada pergunta.
A hierarquia de verdade resolve isso por atributo. No registro de um cliente, cada campo pode ter um dono diferente:
Além do dono, a hierarquia precisa de regras de conflito. Se o CRM tem um endereço mais recente que o ERP, a regra pode mandar seguir o dono, sinalizar a divergência para uma pessoa ou bloquear a ação até a correção.
A análise descreve os sistemas operacionais se tornando máquinas de estado com APIs, que recebem o estado final por interfaces bem definidas. O data warehouse, somado à camada de métricas e às ferramentas de governança, passa a funcionar como um registro da verdade, que precisa codificar a precedência e o significado de cada dado, com contratos semânticos e planos de controle que dizem aos agentes como ler e gravar com segurança.
Os agentes conversam com essa camada. Eles leem o contexto por ela e gravam o estado final no sistema dono da informação, que continua sendo o registro oficial.
O Company Brain ocupa essa posição. Ele conecta CRM, ERP, HRIS e gestão de contratos uma única vez. O grafo de conhecimento liga o registro do mesmo cliente nos quatro sistemas, e a ontologia do negócio registra, para cada atributo, o sistema dono e a regra de conflito. A camada semântica aplica essa hierarquia ao traduzir a pergunta para a consulta certa.
Os sistemas de registro ficam intactos. O Company Brain não substitui o CRM nem o ERP e não copia as bases para um novo repositório. Os dados permanecem no ambiente da empresa, e o agente recebe via MCP, no momento da pergunta, apenas o recorte necessário, com a permissão herdada do sistema de origem.
A hierarquia também fica com a empresa. Ela é registrada na ontologia, fora de qualquer modelo, e sobrevive à troca de fornecedor de LLM. Cada resposta aponta a origem de cada atributo, como o endereço vindo do ERP e o responsável vindo do CRM.
Definir o dono de cada atributo é uma decisão que só a empresa toma. Finanças e vendas podem disputar a origem do desconto, e a escolha precisa de alguém com autoridade sobre os dois processos. A hierarquia aponta a fonte oficial, e a qualidade do dado nos sistemas de registro continua sendo responsabilidade de cada área.
Sistemas legados sem API exigem uma interface de escrita antes de receber alterações de um agente. Ações sensíveis, como mudar um desconto, passam por aprovação de uma pessoa.
O ponto de partida prático é o primeiro fluxo em que um agente vai gravar em um sistema, como a renovação de contratos ou a emissão de cobrança. Para cada atributo que o fluxo lê ou altera, registra-se o sistema dono, a regra de conflito e o responsável pela regra.
Esse mapa costuma caber em uma página. Registrado na ontologia do Company Brain, ele serve ao fluxo seguinte, que acrescenta apenas os atributos novos.