Cérebro da empresa: como os agentes reconhecem o mesmo cliente em vários sistemas

O mesmo cliente se chama “Acme” no sistema de suporte, “ACME COMÉRCIO SP” no financeiro e ACME_COD_SP no CRM. Qualquer pessoa da empresa sabe que é a mesma empresa. Nenhum agente sabe.

Esse é o problema que mais encontrei ao colocar agentes para trabalhar em operações reais. O agente de suporte vê chamados com o nome digitado à mão. O financeiro vê faturas com código de cadastro. O comercial vê negociações com o nome fantasia. Cada um, sozinho, até funciona. Mas basta alguém perguntar “como está a Acme no geral?” e não existe quem responda.

No agent-builder, a plataforma onde construímos os agentes da OrganIA, chamamos de Brain (ou Cérebro da empresa) a camada que resolve isso. Este artigo explica o desenho, as decisões que mais me custaram e o dia em que descobrimos que ligações “confiantes” estavam erradas.

Sem uma camada comum, cada agente inventa a sua regra

Quando não há um lugar que diga quem é quem, três coisas acontecem. Todas custam.

Primeiro, cada agente cria sua própria regra de “é o mesmo cliente?”, e as regras discordam. O agente de suporte junta por nome, o financeiro por código, e um terceiro, feito depressa, por um contains qualquer.

Segundo, a pergunta que atravessa sistemas fica sem dono. Nenhum agente tem o mapa inteiro.

Terceiro, prioridade não existe. Todo chamado pesa igual, porque nada sabe que um cliente vale dez vezes o outro.

 SEM O CÉREBRO                         COM O CÉREBRO
 suporte    -> "Acme"                  suporte  ┐
 financeiro -> "ACME_COD_SP"           financ.  ├─> UMA ENTIDADE
 comercial  -> "Acme Comércio SP"      comerc.  ┘   cadastro + apelidos
                                                    + grupo + importância
 três regras que discordam                              │ ponteiros
                                                        ▼
                                       linhas de chamados, faturas,
                                       negociações: lidas AO VIVO

A tese: índice, não cópia

A tentação natural é copiar. Puxar os dados dos sistemas para uma base central, manter sincronizado, montar a visão 360 em cima. Já vi esse projeto em muitas empresas. Ele cria um segundo lugar onde a verdade mora, e duas verdades sempre divergem.

O Cérebro não guarda uma cópia do número. Guarda um atalho para onde o número vive e busca na hora, com etiqueta de onde veio e quando.

Na prática, o Cérebro guarda o cadastro da entidade e ponteiros para onde o dado dela está, e resolve tudo ao vivo na hora da consulta. Não há sincronização para dar errado, porque não há cópia.

O que essa inversão compra:

zero sincronização para quebrar;
zero dado velho por atraso de cópia;
uma única regra de identidade para a plataforma inteira;
proveniência natural, porque o dado tem endereço.

O que ela custa: a consulta ao vivo é mais cara que ler uma tabela desnormalizada. Pagamos isso com limites por fonte e recorte de colunas. E há uma consequência estrutural: se a fonte some, o ponteiro fica órfão. Por isso o painel de saúde conta órfãos de propósito.

A regra de decisão que usamos para cada fonte é simples. “Esse dado já está num lugar que dá para consultar?” Se sim, o Cérebro guarda só o ponteiro. Se não, como acontece com reuniões, e-mails e documentos narrativos que não têm casa, aí sim ele ingere. O que o Cérebro possui de verdade são quatro coisas: o cadastro canônico com os ponteiros, o grafo de relações, os sinais calculados e esse conteúdo narrativo sem casa. O resto é consultado e citado.

Uma regra que veio junto e que recomendo: medir antes de cachear. A primeira versão do desenho tinha cache e uma projeção materializada ao mesmo tempo, ou seja, duas cópias do mesmo agregado. Cortamos para nenhuma, com um gatilho explícito de latência para construir a projeção só quando o caminho ao vivo doer de fato.

Anatomia: nove tabelas, nenhuma com dado de fonte

Tabela	O que guarda
Entidades	O cadastro canônico: uma linha por entidade real (cliente, fornecedor), com propriedades e apelidos
Referências	Os ponteiros. Ligam uma linha de painel ou de outra fonte à entidade. É o coração do “índice, não cópia”
Fontes	Quais blocos de quais painéis alimentam a resolução. Agnóstico de domínio
Sinais	A série temporal por entidade, casa única de histórico de métrica
Fila de correspondência	Casos ambíguos, para revisão humana
Fila de fusão de mestre	“Este cliente do cadastro mestre é o mesmo que uma entidade que já existe?”
Rótulos de revisão	Decisões humanas: “nunca ligar estes dois”, “sempre ligar”
Regras	Configuração de negócio: como calcular importância, faixas de valor
Registro de acesso	Uma linha por leitura

As duas filas de revisão são separadas por um motivo que parece burocrático e não é. Uma pergunta “esta linha de chamado é da Acme?”, que é correspondência de um registro a uma entidade. A outra pergunta “a Acme do cadastro mestre é a Acme que já criamos?”, que é fusão de duas entidades. A primeira cria um ponteiro. A segunda pode fundir dois cadastros e migrar histórico. Uma fila comum obrigaria a tela a explicar duas semânticas no mesmo lugar.

Nem toda empresa tem linha

O Cérebro nasceu da base instalada: as entidades vieram da conciliação com o cadastro mestre, ou seja, de quem já fatura. Um lead não tem linha. E reunião com lead é o caso comum, não a exceção.

Por isso a identidade de uma empresa passou a morar também fora das tabelas, em três lugares lidos por uma fonte única de nomes: o cliente declarado na ata da reunião (a pessoa declara, a IA só sugere), o domínio de e-mail ligado a uma empresa (aprendido quando a pessoa confirma o cliente de uma ata; domínio genérico e o da própria casa nunca entram) e o apelido gravado quando um caderno de empresa é juntado ou renomeado. Quando o lead vira cliente e ganha linha no Cérebro, nada precisa ser refeito.

Reconhecer: a cascata e o direito de não adivinhar

“Reconhecer clientes” é o processo que percorre as fontes declaradas e decide, para cada valor encontrado, a qual entidade ele pertence. A pontuação é determinística: nome normalizado (sem acento, sem sufixo societário), raiz de domínio, código exato. Com o resultado, há três faixas.

Pontuação	O que acontece
0,90 ou mais, com margem sobre o 2º candidato	Vincula sozinho
Entre 0,75 e 0,90	Fila de revisão humana; o assistente pergunta ao dono
Abaixo de 0,75	Candidato “sem cadastro”: aparece na revisão para criar ou ligar, não é descartado

A margem é o detalhe que separa confiança de sorte. Dois candidatos empatados em 0,95 não decidem nada. Pontuação alta com dois candidatos igualmente altos é ambiguidade, e ambiguidade resolvida por sorteio produz o pior erro possível: o silencioso. No código, a margem mínima é 0,03 sobre o segundo colocado.

Abaixo do corte, o sistema não adivinha. Pergunta.

A revisão humana treina o sistema. Cada decisão vira um rótulo consultado antes das correspondências seguintes, então a fila encolhe com o uso e o mesmo par ambíguo não volta. “Ignorar” deixa marca permanente, para não reaparecer a cada sincronização.

Quando a entidade vem do cadastro mestre, a cascata segue a força da evidência: documento fiscal primeiro, depois código de cadastro, só então semelhança de nome. Documento igual é praticamente prova. Nome parecido é indício.

Uma nota de honestidade: o desenho original previa um motor de matching probabilístico de mercado. Medimos e descartamos por enquanto. O que roda é um resolver leve e determinístico. Os rótulos da revisão estão sendo acumulados de propósito, para treinar um modelo estatístico quando houver volume.

Outubro: o dia em que ligações confiantes estavam erradas

Esta é a parte que mais me ensinou.

Uma resposta de um agente atribuiu a um cliente objeções de venda que eram de outro. Fomos atrás da causa e parte dela estava no Cérebro: ligações automáticas por nome que a pontuação aceitava e que nenhum humano aceitaria.

Três regras entraram na correspondência:

Regra	O que deixou de ligar sozinho
Campo com vários nomes	Um campo como “Acme, Beta” só liga se os dois forem a mesma entidade; senão vai para revisão
Nome colado a outra palavra	Só casa no começo ou no fim do valor, nunca no meio
Domínio	Terminações compostas, do tipo `.med.br`, são tiradas inteiras antes de comparar (antes, uma delas virava o nome “med”)

Depois, reconferimos todas as ligações automáticas existentes com a regra nova. A automática que a regra não sustenta mais é desligada, com o motivo registrado, e o valor volta para a revisão. Em produção, foram 17 de 174. A ligação que uma pessoa fixou nunca é desfeita por esse processo.

Quase 10% das ligações automáticas estavam apoiadas em algo que não se sustentava. Nenhuma delas tinha gerado alarme. Elas só apareceriam do jeito que apareceu a primeira: como uma resposta errada, dita com segurança, a alguém que confiou.

A lição que levo para qualquer projeto de identidade de entidade:

Nome parecido não é o mesmo nome. Fora da pontuação, a identidade de um nome é a grafia (acento, caixa, plural), nunca a contenção.

Um nome estar contido em outro não prova nada. Tivemos um caso de uma empresa ouvida errado numa transcrição, cujo nome cabia dentro do nome de outra empresa, que não tinha relação nenhuma. Duas empresas de nome parecido que são a mesma se resolvem por ato humano: juntar, ou apelido confirmado.

A conferência diária

Desde outubro, o painel de saúde tem uma seção que refaz as decisões todo dia, sem modelo, pelas mesmas funções que decidiram da primeira vez. São quatro checagens: ligações que a regra de hoje não sustenta, atas cujo cliente o próprio convite da agenda contradiz, respostas das últimas 24 h com atribuição sem lastro, e cadernos com reunião cujo cliente mudou depois.

Cada checagem diz quantas conferiu e quantas acusou. O que não deu para conferir é declarado: falha de leitura vira lacuna, nunca acusação. Quando há achado, os administradores recebem um aviso depois da auditoria da noite, que não repete o mesmo número e sai quando zera. E, por convenção, corrigir um tipo novo de erro de atribuição obriga a acrescentar a checagem dele.

O limite é claro: a conferência diária pega regressão de erros que já conhecemos. Um tipo de erro novo só aparece com amostragem julgada por modelo, que está desenhada e travada até termos duas semanas de conferência diária em produção.

Importância, histórico e proteção

Nem todo cliente pesa igual

O que transforma o Cérebro de cadastro em ferramenta de decisão é a importância. É ela que faz um agente priorizar o chamado certo. A parte difícil é o grupo econômico.

Modo	Como calcula	Quando é o certo
Individual	Cada unidade vale o que é	Filiais que compram e decidem separado
Grupo	Toda unidade herda a maior importância do grupo	O relacionamento é com o grupo: irritar a filial pequena custa o contrato inteiro
Grupo por soma	Soma o valor do grupo e recalcula a faixa	Dez filiais médias somam um cliente grande, e nenhuma parecia grande sozinha

As faixas não são inventadas. São sugeridas por percentil sobre os valores reais da carteira, arredondadas e persistidas como configuração. A política é configuração e não código porque “filial herda a importância da matriz?” é pergunta de negócio, com resposta diferente em cada empresa. O agente que consome não vê a regra. Lê a importância já resolvida.

Uma série que nunca apaga

O Cérebro guarda a evolução de algumas métricas por entidade: valor recorrente, volume de registros e volume de registros críticos. A escrita é orientada a mudança. Se a nova medição é igual, só estende a validade da linha ativa. Se mudou, expira a ativa e insere a nova. A expirada vira ponto do passado e nunca é apagada. Na fusão de duas entidades, a série migra.

Daí sai uma regra de plataforma: esta é a casa única de série temporal por entidade. Proibido criar tabela paralela de histórico de métrica, porque a segunda tabela é a que ninguém lembra de migrar na fusão. E erro no cálculo de sinais nunca derruba o reconhecimento de clientes: identidade é a função principal, histórico é enriquecimento.

Ler é permissão por tipo de dado

A primeira versão era binária: ou o agente lia o Cérebro inteiro, faturamento incluído, ou não lia nada. Isso força uma escolha ruim. Dar dado financeiro ao agente de suporte, ou deixá-lo sem contexto de cliente.

Hoje a leitura é filtrada por faceta, a área a que o dado pertence. São cinco: base, geral, suporte, reuniões e financeiro, esta a única sensível hoje. Há três perfis de leitura: completo (todas), operacional (todas menos a sensível) e desligado (nenhuma, que é o padrão).

A invariante que faz isso durar: o perfil é um conjunto de facetas, nunca um booleano. Uma sexta faceta sensível, como jurídico ou RH, é só mais um item, sem mudança no filtro. Um booleano por área exigiria reescrever a decisão a cada área nova, e é assim que nasce aquele if/elif de vinte ramos que ninguém ousa tocar.

Mais algumas travas: mexer em faceta sensível exige ser administrador. A faceta de uma fonte não é escolhida à mão; sai do sistema de onde a ferramenta lê (o ERP é financeiro). Perfil desconhecido cai no operacional, nunca no completo. E ler não é alimentar: quem alimenta ganha só o seletor de cliente, não a consulta à ficha.

O que o agente recebe

A consulta é composição determinística, sem modelo. Resolve a referência contra entidades e apelidos, monta a ficha (identidade, importância efetiva, matriz e filiais), lista os registros recentes por fonte, lidos ao vivo, e devolve duas coisas que costumam faltar:

Proveniência por fonte: qual painel, qual bloco, qual agente, quando foi consultado. O agente deve citar.
Cobertura honesta: quantos candidatos estão pendentes na revisão. Sem isso, “a Acme tem 3 chamados” pode significar “tem 3 que eu reconheci” e soar como “tem 3”.

Se a referência casa com várias entidades, o agente recebe as opções e pergunta, em vez de escolher.

Para alertas (“me avise quando um cliente importante ficar sem contato”), tomamos uma decisão explícita de não criar um quarto mecanismo. A plataforma já tinha três formas de agir sozinha: Agenda, Regras e Heartbeat. O alerta do Cérebro virou uma extensão das Regras, avaliada por entidade. Anti-repetição, canais, histórico e tela de configuração vieram de graça.

A saúde do Cérebro também foi pensada como triagem, não como mural de métricas. Mede cobertura de clientes, tamanho e idade da fila de revisão (fila velha é abandono, e abandono envenena a cobertura em silêncio), ponteiros órfãos, frescor das fontes e volume de correção manual. Cada número vem com causa e link para resolver.

Os números do desenho

Medida	Valor
Tabelas do Cérebro	9, nenhuma duplica dado de fonte
Corte de vínculo automático	0,90, com margem mínima de 0,03 sobre o 2º
Corte de revisão humana	0,75
Facetas de proteção	5, 1 sensível
Perfis de leitura	3
Modos de importância	3
Conferências diárias	4
Ligações automáticas desfeitas em outubro	17 de 174

E os limites que declaramos: a conciliação com o cadastro mestre funciona, mas ainda é disparada à mão ou por job, não por um conector contínuo. As cinco facetas são fixas para todos. O custo da consulta ao vivo numa carteira muito grande, com muitas fontes, ainda não foi exercitado sob carga.

Como aplicar na sua empresa

Não precisa de plataforma de agentes para começar. Este é o roteiro que eu seguiria:

Escolha um cliente e liste todos os nomes dele em todos os sistemas. Se passar de três, você tem o problema.
Decida o que já é consultável. Para isso, guarde ponteiro, não cópia. Ingira só o que não tem casa.
Crie um cadastro canônico com apelidos e uma tabela de ponteiros com chave estável do sistema de origem, não nome de exibição.
Use pontuação determinística com três faixas e exija margem sobre o segundo candidato no automático.
Grave cada decisão humana como rótulo e consulte antes da próxima correspondência.
Não aceite contenção como identidade. Nome dentro de nome não prova nada.
Reconfira as ligações automáticas sempre que a regra mudar, desligando com motivo. Nunca desfaça o que uma pessoa fixou.
Faça a permissão de leitura por conjunto de facetas, com padrão desligado e financeiro como sensível.
Devolva cobertura junto com a resposta, para que “3 chamados” não minta por omissão.
Tenha uma conferência diária sem modelo que refaça as decisões e declare o que não conseguiu conferir.

Fechando

O erro que mais vejo em projetos de “visão única do cliente” é tratar identidade como problema de integração de dados. É um problema de confiança. Um match errado não quebra nada de forma visível. Ele contamina, em silêncio, toda resposta que cruza fontes.

Por isso o Cérebro da empresa tem tanto mecanismo para dizer “não sei” e tão pouco para adivinhar. A outra metade da memória, o que cada pessoa sabe e ensina aos seus agentes, segue a lógica oposta: é dela, vem ligada por padrão e vale em todos os agentes que ela usa. Isso fica para o artigo sobre o segundo cérebro.