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: Uma infraestrutura unificada de contexto é a camada que fica entre os sistemas da empresa e os agentes de IA. Ela decide o que o agente sabe no momento da pergunta. Antes de implementar, oito pontos merecem avaliação: cobertura das fontes, modelagem das entidades do negócio, forma de atualização, latência na hora da consulta, capacidade em volume, observabilidade da qualidade do contexto, interface com os agentes e governança. Quem define esses requisitos antes do primeiro agente evita refazer a integração a cada novo caso de uso.
Cada agente de IA precisa de contexto: o histórico do cliente para o agente de vendas, a política vigente para o agente de atendimento, o contrato e o centro de custo para o agente financeiro. Sem uma camada comum, cada projeto monta a própria integração, com o próprio índice e a própria regra de permissão. Em pouco tempo a empresa tem cinco versões do mesmo cliente.
A infraestrutura unificada conecta as fontes uma única vez e serve o mesmo contexto a todos os agentes. A disciplina que estuda como montar esse contexto se chama engenharia de contexto, assunto do texto O que é context engineering?.
Company Brain (cérebro operacional do negócio): camada que conecta os sistemas da empresa uma única vez, organiza dados, memória e conhecimento e entrega esse contexto a qualquer agente de IA, com as permissões de cada pessoa.
O Company Brain da Strattum é uma infraestrutura desse tipo. Os critérios abaixo usam a arquitetura dele como referência.
A lista de conectores do fornecedor é o começo da conversa. A regra de negócio de muitas empresas mora em planilhas, e-mails, sistemas legados e ERPs customizados que ficam fora do pipeline de dados oficial, como descreve o texto As fontes que ficam fora do pipeline.
Na avaliação, vale separar três grupos: sistemas estruturados (CRM, ERP, atendimento, bancos e warehouses), documentos (SharePoint, Drive, Confluence, Notion) e conversas (Slack, e-mail). O Company Brain conecta os três, incluindo TOTVS e SAP, o que pesa em empresas brasileiras.
Quando CRM e ERP informam valores diferentes para o mesmo cliente, o agente precisa saber qual fonte vale para cada atributo. Isso exige uma ontologia: a descrição das entidades do negócio, como Cliente, Contrato, Produto e Ticket, e das relações entre elas.
No Company Brain, a ontologia é escrita em YAML, versionada em Git e revisada em pull request, como qualquer código da empresa. O Memory Worker lê o catálogo de dados, resolve as entidades entre sistemas e grava o resultado no grafo. A pergunta para o fornecedor é quem mantém a ontologia depois da implantação e como uma mudança é revisada.
Carga noturna atende bem a relatórios gerenciais. Um agente que responde sobre um chamado aberto há dez minutos precisa de dado atualizado de forma contínua. Vale perguntar como a plataforma detecta mudanças em cada fonte e qual o atraso esperado entre a mudança na origem e o contexto disponível para o agente. No Memory Graph do Company Brain, a atualização acontece sem batch noturno.
A latência que o usuário sente soma a recuperação do contexto, a montagem do prompt e a resposta do modelo. Contexto mal organizado aumenta o prompt, o que deixa a resposta mais lenta e mais cara. Contexto organizado em entidades permite entregar ao agente só o que a pergunta exige.
Na prova de conceito, vale medir três coisas com perguntas reais: o tempo de recuperação, o tamanho do contexto enviado ao modelo e o consumo de tokens por resposta. O último número define o custo da operação em escala e mostra se é possível usar modelos menores na maior parte das tarefas.
A escolha do motor de grafo, do índice e da infraestrutura determina quanto a camada aguenta antes de ficar cara. O texto A escolha técnica do motor de grafo mostra como a Strattum avaliou custo e capacidade em volume. Para projetar ingestão, memória, disco e custo antes do contrato, a Strattum disponibiliza uma calculadora de capacidade.
Monitorar se a plataforma está no ar não diz se o contexto está certo. A observabilidade útil responde se há perguntas recorrentes sem resposta na base, se dois documentos se contradizem e se uma resposta validada pelo time volta a ser usada.
O Knowledge, parte do Company Brain, roda um lint de cobertura que identifica perguntas recorrentes sem resposta e detecta contradição entre fragmentos antes de incorporá-los. Respostas validadas pelo time são reabsorvidas como fragmentos indexados.
O padrão de mercado para expor contexto a agentes é o MCP (Model Context Protocol). Na avaliação, importa quais ferramentas o servidor MCP expõe, se ele está em produção ou em preview e se as APIs permitem que aplicações internas usem o mesmo contexto. O Company Brain expõe o grafo como três ferramentas MCP (search_entity, get_entity_context e run_cypher) e oferece APIs para aplicações internas. O guia de engenharia de contexto do Google Cloud é uma boa referência sobre como agentes consomem esse tipo de ferramenta.
Permissão, citação e auditoria custam pouco quando entram na arquitetura e muito quando entram depois. A infraestrutura precisa aplicar a permissão da fonte antes da recuperação, citar documento e versão em cada resposta e registrar cada consulta. No Company Brain, os três controles fazem parte do núcleo, e a plataforma inteira roda na nuvem do cliente.
Uma prova de conceito útil usa um caso de uso real, com perguntas que hoje exigem cruzar pelo menos dois sistemas. Escolhemos esse formato nos projetos da Strattum porque ele expõe de uma vez os problemas de cobertura, modelagem e permissão. Os engenheiros da Strattum (FDE) trabalham dentro da operação do cliente desde o início do projeto para modelar a ontologia e conectar as fontes.
Para planejar a infraestrutura de contexto da empresa com o time da Strattum, acesse strattum.ai/contato.