In short
Many companies come to the subject with an AI agent already chosen and one question still open: where to start organising the context it will consume. To build a Company Brain, a company goes through steps that mix connecting systems, agreement between business areas and access rules, and each one has a point where the project tends to stall. The Company Brain is the layer that knows the company: what data exists, where it lives, how it relates and who can see what.
The technical side has well-known components, from connecting the sources to delivering to the model. The timeline is usually set by the decisions that depend on people outside technology, such as sales and logistics agreeing on when a delivery is late.
AI management references follow the same order. The AI risk management framework published by NIST in 2023, once governance is in place, starts with the function that maps the context in which the system will operate, before measuring and managing. Building a Company Brain follows similar reasoning: first the business scope, then the technology.
Each of the seven steps has a requirement and a frequent mistake.
The question that opens the work of building a Company Brain needs to be recurring, have an owner and cross two or three systems. One example is knowing which orders from large customers are on credit hold and have a delivery promised for this week. The common mistake is choosing a question that is too broad, such as understanding the customer, which defines neither sources nor entities.
The question points to the systems: the delivery promise in the CRM, the credit hold in the ERP, the dispatch schedule in logistics. This step requires read access negotiated with technology and security. It tends to stall when access to an old system depends on an approval with no clear owner.
The same product can have a code in the ERP, a free-text description in the CRM and another reference in logistics. Before linking records in the knowledge graph, you have to recognise which of them represent the same thing. Merging two different items contaminates every answer that follows, which is why ambiguous cases go to someone from the business area.
For sales, an on-time delivery is one that arrives on the date promised to the customer. For logistics, it is one that leaves on the date scheduled with the carrier. The ontology records which definition applies to each question and who is accountable for it. The common mistake is leaving the choice to the technical team, which has no authority to defend it.
The semantic layer translates the natural-language question into the right records and terms. Permissions come from the source system: whoever cannot see the credit limit in the ERP does not get it through AI either. The difficulty appears when access rules live in old profiles or in spreadsheets maintained by hand.
Context reaches the agent through MCP, the open protocol that connects models to data sources, with the origin of each piece of information indicated. The common mistake is connecting several agents before the first one is in use.
Measurement tracks real usage, corrected answers and questions left unanswered. Expansion picks the next question by the sources and definitions it reuses. Whoever skips measurement expands on a foundation nobody has validated.
Some choices come up every time a company decides to build a Company Brain, and they all depend on experience:
At Strattum, the forward deployed engineer (FDE) works inside the company, alongside the business areas, during the deployment. They know the platform inside out and help choose which questions work as a first scope and where entity resolution tends to fail.
Decisions stay with the company. The FDE lays out the alternatives, records what was decided in the ontology and connects the sources. What they build stays in the customer's environment, and the second use case starts from what the first one left resolved.
Three conditions sustain the project. A sponsor with the authority to unblock access and arbitrate definitions. Sources accessible through an API or database. Reserved time from the people who know the process, because they are the ones who validate entities and terms.
The Company Brain reduces wrong answers caused by missing context. Answer quality still depends on the master data at the source, and an ERP with duplicated products needs cleaning before or during the project.
The first practical step is to write down the candidate question and list the systems it touches and the terms that cause debate between the areas. That exercise shows the size of the effort to build a Company Brain for that scope.
Strattum holds diagnostic conversations about that first scope: which question to choose, which sources it requires and which definitions need an owner. For companies deciding where to start, it is a way to see the path with people who know the platform inside out.
