O meio que falta no conhecimento da empresa
Três camadas, e não uma
Fale com qualquer pessoa sobre “conhecimento da empresa” e a expressão faz trabalho demais. Ela colapsa três coisas bem diferentes, que vivem em lugares diferentes e decaem em velocidades diferentes. Separe-as e a lacuna fica óbvia.
A primeira camada são os seus sistemas de registro. Clientes no Salesforce ou no HubSpot, pessoas no Workday, cliques no GA4, dinheiro na contabilidade. São dados estruturados que vivem em linhas, e o setor passou trinta anos ficando bom nisso. É governado, consultável e quase sempre correto. E também fica no lugar. Não temos interesse em reconstruir isso.
A segunda camada é o conhecimento canônico. O seu preço, o seu posicionamento, a visão da empresa, a resposta a “qual é a nossa posição sobre X”. É o pensamento durável que um time faz uma vez e consulta por anos. É governado em outro sentido: quem acabou de entrar não reescreve a missão em silêncio. Wikis, Notion e Guru tratam isso razoavelmente bem, e a onda recente de montagens de “brain da empresa” mira sobretudo aqui. Escrevemos sobre essa onda em Agentes precisam de um brain em que possam escrever.
Depois há a terceira camada, e quase ninguém está olhando para ela.
A camada operacional que ninguém mantém
A terceira camada é o conhecimento operacional. O que de fato está acontecendo com um cliente agora. Quem no time acabou de aprender uma habilidade nova. A pergunta em aberto parada numa corrente desde terça. O problema de suporte que um cliente repete e que ainda não virou chamado nenhum.
Esse conhecimento nasce nas comunicações. Muda de hora em hora. E hoje é mantido mal ou não é mantido, o que é estranho, porque a ausência dele causa dano mensurável.
Imagine alguém de vendas saindo de uma boa reunião. O novo cargo e o telefone do contato fluem para o CRM, porque essa parte é estruturada e existe um formulário para ela. Mas os planos de crescimento do cliente para o ano que vem, as três dúvidas que ele está pesando, a renovação sobre a qual está discretamente nervoso, nada disso vai para lugar nenhum. Fica na cabeça de uma pessoa e em algumas linhas de um resumo que ninguém lê. O próximo colega a tocar a conta entra às cegas, pergunta algo que o cliente já respondeu, e o negócio fica em risco. Multiplique isso por cada conta e cada passagem de mão.
É a camada operacional vazando, todo dia, em toda empresa.
Por que você não resolve isso do jeito antigo
Você não conserta a camada operacional com as ferramentas que consertaram as outras duas. Ela tem forma, só não uma forma rígida: é organizada em torno das coisas com que você se importa, um cliente, um concorrente, um colega, mas o que você sabe sobre cada um é prosa, e não campos.
Não vai caber em linhas do jeito que os sistemas de registro cabem. “O cliente parece hesitante com o prazo da migração e volta sempre à residência dos dados” não é um campo. Não há lista suspensa para isso, e no instante em que você tenta forçar uma, perde aquilo que tornava a informação útil.
Também não vai sobreviver à curadoria manual do jeito que o wiki sobrevive. Uma página canônica sobre o seu preço vale ser escrita à mão porque é verdadeira por um ano. Uma nota operacional está velha no dia seguinte ao que você a escreve. Peça que as pessoas a mantenham em dia à mão e elas não vão, porque o serviço é interminável e ingrato, e elas têm trabalho de verdade. A literatura de base de conhecimento tem nome para o que vem depois: sistemas morrem de envelhecimento, e os times acabam com verdades paralelas, duas páginas que discordam e ninguém certo de qual acreditar.
Então o único jeito de sustentar conhecimento operacional é parar de tratá-lo como algo que uma pessoa escreve. Ele precisa ser mantido continuamente e automaticamente, a partir das mesmas comunicações em que nasceu. É um problema genuinamente difícil, e não vamos fingir que está terminado. É a direção que estamos construindo.
Como fica quando funciona
O ponto de manter essa camada é que o resto do sistema pode se apoiar nela.
Um fluxo pode ler notícias de concorrentes e parceiros toda manhã e escrever o que mudou no brain, para quem lidera não ser a última pessoa a saber do movimento de um rival ao entrar numa conferência. O conhecimento se acumula; não é um relatório que passa rolando num canal e some.
A camada operacional também deixa a sua automação mais esperta, porque as duas metades se compõem. Quando a Sofia termina um curso de aprendizado de máquina, esse fato cai no brain. Na próxima vez que uma tarefa de aprendizado de máquina chegar, o fluxo que encaminha trabalho já sabe que a Sofia é a pessoa certa, sem ninguém atualizar uma regra à mão. O conhecimento alimenta a automação, e a automação, por sua vez, segue produzindo mais conhecimento que vale guardar.
E aquela pessoa de vendas do começo? O próximo colega abre a conta, e o contexto já está lá, escrito a partir das correntes em vez de preso na cabeça de uma pessoa.
Uma fronteira clara, de propósito
Uma coisa em que somos deliberados: isto não é um CRM, e não está tentando virar um.
Dado transacional fica nos sistemas de registro dele. A camada um não se mexe. A camada operacional fica entre o CRM e o wiki, guardando o contexto vivo para o qual nenhum dos dois foi feito. O registro do contato fica no Salesforce. A página de preços fica no wiki. O que está acontecendo com este cliente esta semana, quem sabe o quê, a pergunta ainda aberta na corrente, é isso que mantemos no meio. Traçar essa linha com clareza não é uma limitação pela qual nos desculpamos. É a posição.
Karpathy estava certo em dizer que uma base de conhecimento mantida por um LLM é um artefato que acumula, e a tendência de brain da empresa que veio depois é uma ideia real e inteligente. A peça que ainda falta é a camada do meio, aquela que é rápida demais para curar e desestruturada demais para esquematizar. Ninguém é dono dela ainda. É onde estamos construindo.