Empresas nunca tiveram tantos dados disponíveis. CRM, ERP, data warehouses, documentos, dashboards, e-mails, ferramentas de atendimento e dezenas de aplicações SaaS acumulam diariamente informações sobre clientes, produtos, processos e decisões.
Ainda assim, dar acesso a todos esses sistemas para uma IA não significa que ela passou a entender a empresa.
Um agente pode encontrar uma tabela de clientes sem saber qual campo representa a informação oficial. Pode localizar quatro documentos sobre uma mesma política sem conseguir determinar qual deles ainda está válido. Pode acessar dados de vendas e finanças sem entender que cada área utiliza uma definição diferente para a mesma métrica.
O problema, portanto, é contexto, e não apenas acesso à informação.
A ideia é criar uma base compartilhada de entendimento sobre a empresa. Em vez de cada novo agente precisar reconstruir sozinho como o negócio funciona, diferentes aplicações e agentes passam a operar sobre o mesmo contexto empresarial. É a lógica do que o texto-base descreve como um shared enterprise brain: uma fundação que diferentes agentes podem consultar, aprender e enriquecer com o tempo.
Imagine que um agente tenha acesso ao Salesforce, ao data warehouse e ao Notion da empresa.
Tecnicamente, ele possui acesso a uma quantidade enorme de informação. Mas, quando alguém pergunta “qual é a nossa receita recorrente?”, ainda existem várias decisões que precisam acontecer antes de produzir uma resposta confiável.
Qual sistema contém a informação oficial? Qual tabela deve ser utilizada? Qual definição de receita recorrente vale para aquela pergunta? Aquela definição ainda está atualizada?
Essas respostas representam o contexto que normalmente está distribuído entre sistemas, documentos e pessoas.
É justamente essa camada de entendimento que um Company Brain busca tornar explícita e utilizável por máquinas.
O contexto empresarial pode ser dividido em três grandes dimensões: knowledge, expertise e norms. Em outras palavras, uma IA precisa entender o que a empresa sabe, como o trabalho realmente acontece e quais regras determinam o que pode ou não ser feito.
A primeira dimensão é o conhecimento sobre a própria empresa.
Toda organização possui uma linguagem específica. Termos como cliente ativo, receita, produto, oportunidade ou incidente podem parecer simples, mas frequentemente possuem definições próprias dentro de cada negócio.
Esse conjunto de entidades, métricas, definições, taxonomias e relacionamentos forma o mapa conceitual da organização. É o que permite que humanos e sistemas de IA compartilhem o mesmo entendimento sobre o que os principais conceitos do negócio realmente significam.
Sem essa camada, um agente pode acessar os dados corretos e ainda assim chegar à interpretação errada.
Mas conhecer o vocabulário de uma empresa não é suficiente para operar dentro dela.
Também existe um enorme volume de conhecimento sobre como o trabalho realmente é executado.
Como um lead inbound deve ser qualificado? Como o fechamento mensal acontece? Quando uma exceção de suporte precisa ser escalada? Qual ferramenta deve ser utilizada em determinada etapa?
Esse conhecimento está espalhado por procedimentos, playbooks, tickets, conversas, sistemas e, muitas vezes, pela experiência acumulada das pessoas que trabalham na empresa há mais tempo.
Para um Company Brain, isso significa que documentos são apenas uma parte da resposta. Entender a organização também exige capturar a maneira como o trabalho acontece na prática.
Existe ainda uma terceira camada de contexto: as regras que limitam a ação.
Uma IA pode saber qual desconto faria sentido para um cliente e entender perfeitamente como aplicar esse desconto no sistema. Ainda assim, talvez aquela decisão precise da aprovação de um gerente.
Da mesma forma, determinados dados podem estar sujeitos a restrições de acesso, algumas ações podem exigir intervenção humana e diferentes países podem impor regras específicas sobre onde determinadas informações podem ser armazenadas ou processadas.
Elas determinam não apenas o que é verdadeiro e como algo deve ser feito, mas principalmente o que o agente está autorizado a fazer.
É a combinação dessas três dimensões que transforma informação dispersa em entendimento empresarial.
Um Company Brain precisa transformar esse contexto em algo que agentes e aplicações consigam utilizar de forma consistente.
Para isso, o texto-base organiza a arquitetura em duas grandes partes. Primeiro existe uma fundação de contexto, composta por dados e conhecimento preparados para IA, semântica e ontologia, e skills. Depois existem capacidades responsáveis por descobrir, manter, distribuir e governar esse contexto ao longo do tempo.
A primeira parte responde à pergunta: o que o Company Brain sabe?
A segunda responde: como esse conhecimento continua correto e útil conforme a empresa muda?
Uma tabela, por exemplo, não deveria chegar a um agente apenas como um conjunto de colunas. Informações como descrição, primary keys, caminhos de join, filtros obrigatórios, padrões de SQL e histórico de uso ajudam o sistema a entender como aquele dado deve ser utilizado.
O mesmo vale para conhecimento não estruturado.
Estratégia, posicionamento, princípios, documentos de produto, estruturas organizacionais e guias internos também fazem parte do contexto empresarial. O desafio é identificar quais informações são canônicas, classificá-las e determinar quais devem fazer parte do conhecimento que a IA pode utilizar.
Isso não significa necessariamente copiar toda a informação da empresa para um único banco central.
À medida que protocolos como MCP permitem que agentes interajam diretamente com diferentes sistemas, parte desse conhecimento pode permanecer na origem.
Depois de saber quais informações existem, surge uma segunda pergunta: o que elas significam?
É aí que entram semântica e ontologia.
A semântica estabelece definições compartilhadas. Ela determina, por exemplo, o que a empresa considera um cliente ativo, como determinada métrica é calculada ou quando um incidente deve ser considerado escalado.
A ontologia conecta essas definições. Ela representa as relações entre clientes, contas, transações, produtos, SKUs, inventário e outras entidades do negócio.
Essa conexão é importante porque empresas não funcionam como uma coleção de sistemas isolados. Uma pergunta aparentemente simples pode exigir informações de CRM, produto, financeiro e atendimento ao mesmo tempo.
Sem uma representação dessas relações, o agente precisa tentar reconstruir esse entendimento a cada nova tarefa.
Com um Company Brain, essas relações passam a fazer parte do contexto compartilhado.
Ainda existe uma diferença entre entender uma empresa e saber trabalhar dentro dela.
Uma definição pode explicar exatamente o que significa margem bruta. Ela não explica como a empresa realiza o fechamento mensal.
É por isso que Skills são uma parte importante dessa arquitetura.
Uma Skill representa uma forma reutilizável, versionável e testável de executar determinado trabalho. Pode incluir quando um processo deve começar, quais etapas devem ser executadas, quais regras precisam ser respeitadas, como lidar com exceções e quando uma aprovação humana é necessária.
Em vez de o conhecimento operacional permanecer escondido em um documento ou na cabeça de algumas pessoas, ele pode se tornar parte do contexto que diferentes agentes utilizam.
Esse ponto muda significativamente o papel do Company Brain.
O desafio é que grande parte desse conhecimento nunca foi formalmente documentada.
Para entender como uma empresa acredita que funciona, seus documentos podem ser suficientes. Para entender como ela realmente funciona, é necessário observar os sistemas em que o trabalho acontece.
É essa a função de Context Mining.
O contexto pode ser encontrado em sistemas como Salesforce e ServiceNow, plataformas de dados como Snowflake e Databricks, ferramentas de conhecimento como Notion e Confluence, conversas em Slack e e-mail e também nos rastros deixados pelo próprio uso desses sistemas. Query history, padrões de utilização, traces de agentes, avaliações e correções humanas também revelam como a organização realmente funciona.
Isso permite identificar situações que dificilmente apareceriam em um único documento.
Sales e Finance, por exemplo, podem estar utilizando definições diferentes para ARR.
Em outro cenário, quatro documentos podem trazer regras diferentes para uma mesma situação. A IA pode localizar os documentos, analisar quais são mais recentes e preparar possíveis respostas. Mas a decisão sobre qual versão será considerada canônica continua pertencendo a um humano.
A lógica é importante: a IA faz o trabalho pesado de descoberta; humanos resolvem ambiguidades.
Descobrir procedimentos é ainda mais difícil do que descobrir definições.
Muitos dos processos mais importantes de uma organização nunca foram escritos formalmente.
O texto apresenta diferentes maneiras de capturar esse conhecimento. Uma atividade pode ser executada uma vez junto com um agente e, depois, a própria IA pode analisar a sessão para identificar um padrão repetível. Logs de sistemas podem revelar fluxos de processo.
A observação de operadores experientes pode revelar workflows reais, enquanto entrevistas estruturadas podem trazer à tona exceções e regras de decisão que não aparecem nos sistemas.
O objetivo não é transformar automaticamente tudo que foi observado em verdade empresarial.
Esses sinais geram candidatos a contexto, que ainda precisam ser avaliados antes de entrar no Company Brain.
Se o contexto começa a orientar o comportamento de agentes, ele não pode continuar sendo tratado como um conjunto de prompts e instruções espalhadas.
Ele passa a ser infraestrutura.
Por isso surge a necessidade de um Context Development Lifecycle: um processo para construir, testar, revisar, aprovar, publicar e aprender com o contexto utilizado pela organização.
A IA pode assumir grande parte do trabalho inicial.
Humanos entram onde julgamento e responsabilidade são necessários: resolvendo ambiguidades, adicionando conhecimento tácito e decidindo o que pode se tornar canônico.
Essa abordagem também permite lidar com um problema particularmente importante: mudanças.
Imagine que a empresa redefina seu ICP. Essa decisão pode afetar um agente de SDR, o lead scoring, campanhas de marketing, playbooks comerciais e diversas avaliações internas.
O Company Brain precisa conseguir identificar o blast radius dessa mudança: quais outros contextos, agentes e workflows dependem daquela definição e precisam ser revisados.
Assim, contexto deixa de ser apenas informação armazenada e passa a possuir dependências, versões e responsáveis.
Outro componente essencial de um Company Brain é sua capacidade de aprender com o uso.
Para isso, é importante distinguir diferentes tipos de memória.
Semantic memory e procedural memory possuem outra função. Elas representam respectivamente o conhecimento durável da organização e a forma como o trabalho deve ser realizado. Por isso, pertencem ao contexto compartilhado da empresa.
Essa distinção permite transformar experiência em conhecimento.
Uma correção feita durante uma interação pode inicialmente valer apenas para aquela conversa. Se a mesma correção aparece repetidamente, é avaliada e validada, ela pode se transformar em uma preferência oficial.
Uma exceção recorrente pode virar uma política.
Um workflow que repete bons resultados pode se transformar em uma Skill.
É esse processo que cria compounding learning loops: cada interação produz sinais que podem melhorar o contexto compartilhado e, consequentemente, melhorar o desempenho dos próximos agentes.
Ele herda o que a organização aprendeu.
Construir todo esse conhecimento não gera valor se ele permanecer isolado.
O Company Brain precisa conseguir entregar o contexto relevante no momento em que uma decisão está sendo tomada.
Isso pode acontecer dentro de um copilot, um sistema de busca, uma ferramenta de analytics, um workflow, um editor de código, uma aplicação empresarial ou diretamente dentro de um agente.
Também não existe uma única forma de consumir esse contexto.
Alguns sistemas podem utilizar MCP. Outros podem acessar APIs, SQL, mecanismos de busca, vector retrieval, graph traversal ou combinações dessas abordagens.
Isso significa que a arquitetura não deveria depender de uma única interface. O importante é possuir um contexto canônico que possa ser traduzido para o formato que cada aplicação precisa.
O mesmo conhecimento pode alimentar diferentes agentes e aplicações sem precisar ser recriado em cada uma delas.
Quanto mais agentes começam a depender do Company Brain, mais importante se torna saber se o contexto disponível continua correto.
É aí que entram governance e observability.
Uma organização precisa conseguir saber quem validou determinada definição, quando ela foi atualizada, de onde veio, quais sistemas dependem dela e qual versão está sendo utilizada.
Também precisa detectar drift: situações em que a realidade mudou, mas o contexto não acompanhou.
Sem esse controle, o Company Brain corre o risco de se transformar em mais um repositório cheio de artefatos desatualizados e contraditórios. Com governança, o contexto pode se tornar uma infraestrutura certificada, versionada e continuamente melhorada.
Conforme empresas adicionam IA às diferentes áreas, surge outro risco: cada produto começar a construir sua própria versão da empresa.
O agente de atendimento cria seu contexto sobre clientes. Um sistema de memória guarda informações separadamente.
Individualmente, cada solução pode funcionar bem.
Mas a empresa termina com diferentes context islands.
O aprendizado feito em uma aplicação não beneficia necessariamente as demais, e diferentes agentes podem acabar trabalhando com definições contraditórias sobre o mesmo negócio.
O texto-base argumenta que uma verdadeira camada empresarial precisa ser compartilhada. O contexto precisa conseguir circular entre diferentes agentes, produtos e ecossistemas para que o aprendizado realmente se acumule.
Esse é um dos papéis centrais do Company Brain: criar uma base comum para que diferentes sistemas entendam a mesma empresa.
Várias tecnologias existentes resolvem partes importantes desse problema.
Semantic layers ajudam a padronizar métricas e dimensões. Sistemas de memória permitem que agentes preservem informações de interações anteriores.
Mas nenhuma dessas capacidades, isoladamente, representa todo o problema.
Um Company Brain precisa conectar dados e conhecimento, representar significado e relações, capturar procedimentos, aprender com as interações, entregar contexto para diferentes aplicações e manter tudo isso governado ao longo do tempo.
É justamente a combinação dessas capacidades que muda a natureza da infraestrutura.
A primeira geração de aplicações empresariais de IA esteve muito focada em conectar modelos aos sistemas existentes.
Esse continua sendo um passo necessário.
Mas acesso não é entendimento.
Para realmente operar dentro de uma organização, a IA precisa saber quais informações são confiáveis, o que elas significam, como diferentes conceitos se relacionam, como o trabalho acontece e quais regras precisam ser respeitadas.
Trata-se de transformar o conhecimento acumulado pela organização em uma infraestrutura compartilhada que humanos, agentes e aplicações possam utilizar.
Quando isso acontece, cada novo sistema de IA deixa de precisar descobrir a empresa novamente.
Ele começa com aquilo que a organização já sabe.
Agende uma conversa de 30 minutos. Mostramos a Strattum operando.
