In short
An agent is preparing a customer's renewal proposal and needs the current discount. The CRM holds the discount the salesperson negotiated, the signed contract holds another and the ERP price list applies a third. The agent uses the first one it finds, and the proposal goes out wrong. Knowing which system speaks for each piece of information is what systems of record are about. With agents, that decision has to be written down, and recording it is one of the jobs of the Company Brain, the layer that knows the company: what data exists, where it lives, how it connects and who may see what.
A system of record is the system the company recognises as the official source of a type of information. The CRM is usually the record for customers and opportunities, the ERP for billing and accounting, the HRIS for people and contract management for clauses and terms.
Other systems hold copies, and corrections flow from the official record towards them. That is why the term is associated with the idea of a source of truth.
For a long time, each department chose its own systems of record. Point-to-point integrations copied data between them, and each copy aged at a different pace.
The next stage was analytical centralisation. Data warehouses and lakehouses began to gather data from every system, with semantic models and governance rules. That repository shows what happened, while operations continue in the source systems.
The arrangement worked because the one crossing the systems was a person. The billing analyst knew that the address in the CRM is often out of date and checked it in the ERP. The rule lived in her experience.
In an analysis published by Jamin Ball in the Clouded Judgement newsletter in December 2025, the argument is that agents raise the bar for what is expected of a good system of record.
The agent crosses several systems in the same flow, from order to collection, and writes changes: it opens orders, issues bills, updates records. A wrong piece of data read at the start of the flow spreads to the end and enters other systems looking like confirmed information.
Without the analyst's experience, it needs an explicit rule about which system owns each piece of information and what to do when two of them disagree.
Disagreement between systems of record is common. The HRIS, the payroll and the access management system can show different totals of active employees, because each one handles leave, interns and the month's departures in its own way. Each number is right under its own rule, and the agent needs to know which one to use for each question.
The hierarchy of truth settles this per attribute. In a customer record, each field can have a different owner:
Besides the owner, the hierarchy needs conflict rules. If the CRM has a more recent address than the ERP, the rule can say to follow the owner, flag the disagreement to a person or block the action until it is corrected.
The analysis describes operational systems becoming state machines with APIs that receive the final state through well-defined boundaries. The data warehouse, together with the metrics layer and governance tooling, starts to work as a truth registry that has to encode the precedence and meaning of each piece of data, with semantic contracts and control planes that tell agents how to read and write safely.
The agents talk to this layer. They read context through it and write the final state to the system that owns the information, which remains the official record.
The Company Brain fills that position. It connects CRM, ERP, HRIS and contract management once. The knowledge graph links the same customer's record across the four systems, and the business ontology records, for each attribute, the owning system and the conflict rule. The semantic layer applies this hierarchy when it translates the question into the right query.
The systems of record stay untouched. The Company Brain does not replace the CRM or the ERP and does not copy the databases into a new repository. The data stays in the company's environment, and the agent receives via MCP, at the moment of the question, only the slice it needs, with the permissions inherited from the source system.
The hierarchy also stays with the company. It is recorded in the ontology, outside any model, and survives a change of LLM vendor. Every answer points to the origin of each attribute, such as the address coming from the ERP and the account owner coming from the CRM.
Deciding the owner of each attribute is a decision only the company can make. Finance and sales may dispute where the discount comes from, and the choice needs someone with authority over both processes. The hierarchy points to the official source, and the quality of the data in the systems of record remains each department's responsibility.
Legacy systems without an API need a write interface before they can receive changes from an agent. Sensitive actions, such as changing a discount, go through a person's approval.
The practical starting point is the first flow in which an agent will write to a system, such as contract renewal or billing. For each attribute the flow reads or changes, you record the owning system, the conflict rule and the person responsible for the rule.
This map usually fits on one page. Recorded in the Company Brain ontology, it serves the next flow, which only adds the new attributes.
