In any company running more than one system, some information shows up in two places with different values. The CRM records one contract amount, the ERP records another and the month-end spreadsheet records a third. An AI agent consulting all three has to decide which one holds, and that decision is usually taken without anyone noticing. The Company Brain, the layer that knows the company (what data exists, where it lives, how it relates and who is allowed to see what), makes that decision explicit and checkable.
Divergence does not necessarily point to a data-entry error. Each system records the information at the moment and for the purpose that belong to it. The CRM holds the amount negotiated when the opportunity closed. The ERP holds the amount actually invoiced, after adjustments, taxes and amendments. Both are correct within their own context, and they answer different questions.
The problem appears when the question does not say which context matters. Asked what a customer’s contract is worth, a similarity search returns both records as equally relevant, and the model picks one of them without signalling that another existed. A Company Brain starts from the recognition that both values may be correct.
The answer starts by defining, attribute by attribute, which system has authority over each piece of information. The customer, as an entity, exists in several systems. The invoiced amount belongs to the ERP, the deal stage belongs to the CRM and the SLA in force belongs to contract management.
That assignment is recorded in the business ontology. When a question involves the contract amount, the ontology says which definition the question asked for and which system answers for it. If the question is ambiguous, the Company Brain returns both values, each with its origin, and leaves the choice with whoever asked.
In some situations the divergence is itself the information that matters. The gap between the contracted amount and the invoiced one can point to a billing error, a discount that was never recorded or an amendment that never reached the ERP.
The knowledge graph keeps both records tied to the same entity, each carrying its source system and its update date. A reconciliation query walks those links and lists the divergences alongside the documents backing each value. Controlling then decides whether to correct the invoice, bill the difference or amend the contract.
Beyond the origin, the date matters. A contract renegotiated last week may not be reflected in the ERP yet, and a record updated in the CRM may hold more recent information than the billing system does. Without knowing when each value was recorded, there is no way to apply a rule that gives precedence to the most current one.
For every piece of information, the Company Brain keeps the source system and the moment of the last update. A question about a contract’s current state takes the most recent version recorded in the system with authority over that attribute, and a historical question takes the value in force on the date asked about. The same structure makes it possible to reconstruct, months later, what information was available when a decision was taken.
Some divergences can be settled by rule, such as giving precedence to the most recent value or to the system with authority over the attribute. Others call for a human decision, because they turn on a commercial or contractual reading.
Either way, the rule needs an owner. Whoever decides that the ERP amount prevails over the CRM one in revenue reporting is taking a business decision, and it has to be recorded and reachable by anyone reading the result. In the Company Brain, those rules sit in the ontology, next to the definition of each attribute. Without that record, every tool applies whatever criterion its vendor configured, and two reports on the same revenue arrive at different numbers.
Holding information from different origins side by side also affects access control. One customer can carry widely readable data, such as the deal stage, and restricted data, such as the contract margin. A permission defined per document, or for the entity as a whole, is too coarse for that case.
In the Company Brain, each piece of information carries the permission of the system it came from. The salesperson sees the deal stage they already see in the CRM, and the finance analyst sees the invoiced amount they already see in the ERP. Context is served to the models over MCP, an open protocol that connects models to data sources, and every answer reaches the model filtered by the permissions of whoever asked.
The Company Brain does not correct the source. If the ERP holds a wrong value, the context layer flags the divergence, and the correction has to happen in the source system, by the team that owns it. Using the context layer as the place to correct things creates a third version of the information and makes the original problem worse.
Defining authority per attribute also takes upfront work from the business areas. As a starting point, pick an attribute that comes up again and again in results meetings, such as the contract amount or the renewal date, and record which system answers for it and in which questions. That record is the first entry in the Company Brain’s ontology.
Talk to a Strattum expert about the Company Brain, business ontology and the rules that decide which value prevails.
