Em resumo
Um diretor de vendas aprova, para uma renovação, um desconto acima do teto previsto na política. O CRM passa a mostrar o novo valor. O motivo fica na conversa da aprovação: o cliente recebeu proposta de outro fornecedor, e outra conta do mesmo setor teve condição parecida meses antes. O context graph, ou grafo de contexto, é a estrutura que registra esse porquê e o liga às entidades e ao tempo. Ele estende o grafo de conhecimento do Company Brain, a camada que conhece a empresa: quais dados existem, onde vivem, como se relacionam e quem pode ver o quê.
CRM, ERP e helpdesk são sistemas de registro. Eles guardam o estado: o valor do contrato, o prazo de pagamento, o limite de crédito, a prioridade do chamado. Quase nenhum guarda por que aquele valor foi aceito naquele caso.
Exceções, aprovações, precedentes e o cruzamento de informações entre sistemas ficam em conversas, e-mails e na memória de quem decidiu.
Em dezembro de 2025, Jaya Gupta e Ashu Garg, da gestora Foundation Capital, descreveram os rastros de decisão como a camada que os sistemas de registro deixam de fora. No texto, eles chamam de context graph a estrutura formada por esses rastros acumulados ao longo das entidades e do tempo.
Uma regra comercial define o desconto máximo por faixa de contrato. Um rastro de decisão registra o que aconteceu em um caso: qual política se aplicou, qual exceção foi pedida, quem aprovou, com base em qual precedente e com quais dados à vista. Alguns exemplos:
Cada rastro liga uma decisão às entidades que ela afetou, ao momento em que aconteceu e às informações consultadas. Acumulados, os rastros formam o context graph, e o precedente passa a ser pesquisável: quando uma exceção parecida foi concedida, por quem e com qual justificativa.
O grafo de conhecimento representa as entidades do negócio e as relações vigentes entre elas: este cliente assinou este contrato, que originou estes pedidos.
O context graph usa as mesmas entidades como âncora e acrescenta um tipo de nó, a decisão. Cada decisão aponta para as entidades que afetou, para a regra em vigor, para a exceção concedida e para a pessoa que aprovou. As duas estruturas dependem uma da outra, porque um rastro sem a entidade certa só é recuperado por semelhança de texto.
Um agente que opera apenas com regras resolve bem o caso típico. Diante da exceção, ele aplica a regra ao pé da letra ou completa a lacuna com a continuação mais provável, e o resultado diverge da prática da empresa.
Com acesso aos rastros, o agente recupera casos anteriores parecidos e os apresenta a quem decide, com a política vigente e os dados que sustentaram cada aprovação. A decisão de exceção continua humana. O agente prepara o caso, a pessoa aprova, ajusta ou recusa, e o rastro registra quem decidiu e por quê.
O argumento central dos autores é de arquitetura. O rastro existe no momento em que a decisão é tomada: quais dados foram consultados, qual política foi avaliada, qual exceção foi pedida e quem aprovou. Quem está nesse caminho de execução registra o context graph enquanto a decisão acontece.
Um sistema que lê os dados depois, por ETL (cargas periódicas para o data warehouse), recebe o estado final. Ele vê o contrato com desconto acima do teto e não vê a conversa que justificou o desconto. O porquê se perde na passagem.
Um rastro de exceção de crédito pode conter a situação financeira do cliente e trechos de conversa interna, e herda a sensibilidade de todas as fontes que consultou.
No Company Brain, o histórico das interações e das decisões é registrado junto às entidades do grafo de conhecimento. Uma aprovação de desconto fica ligada ao cliente, ao contrato, à oportunidade e à pessoa que aprovou, com data e sistema de origem. A ontologia do negócio define o que cada tipo de decisão significa.
A permissão é herdada do sistema de origem. Um rastro que cita dado do ERP volta só para quem já vê esse dado no ERP. Os rastros ficam no perímetro do cliente, e o recorte necessário é servido via MCP ao agente que prepara a próxima decisão, com a fonte de cada informação.
Trata-se de uma direção de arquitetura, construída processo a processo: o context graph ganha valor conforme mais decisões passam pelo fluxo em que o registro acontece.
O ponto de partida recomendado é um processo com decisões repetidas e muitas exceções, como aprovação de desconto, liberação de crédito ou concessão de prazo. O primeiro passo é mapear onde a aprovação acontece hoje e quais dados quem aprova consulta antes de decidir.
Em seguida, o fluxo de aprovação passa a registrar cada decisão com justificativa, aprovador, política e entidades. Nas semanas seguintes, a equipe verifica se os precedentes recuperados ajudam quem decide a próxima exceção.