The company has three AI agents running. One answers support tickets, another builds account briefings before the sales call, the third reads contracts. Each one connected its own sources, keeps its own history, and figured out on its own that this one customer shows up under three different names in three different systems. None of the three knows what the other two learned. What is missing between them is a Company Brain: the layer that knows the company — what data exists, where it lives, how it relates, and who is allowed to see what.
An agent's memory today is usually three things: its own conversation history, its own vector index, and a handful of rules written into the prompt by whoever built the project.
When someone in support teaches the support agent that the SLA clause in force is the one in the amendment, not the original contract, that correction becomes an instruction inside that one agent. The sales agent keeps citing the old deadline the following week.
This repeats for every ambiguous term in the business. What counts as churn, what counts as an invoiced order, who is the same company when the tax ID sits in the ERP and the legal name sits in the CRM. The company pays three times for the same modeling, and the three versions drift apart over time. A question that crosses two agents comes back with two answers, and nobody can say which one is right.
Storing keeps the document available. Remembering requires knowing that this ticket belongs to the same customer as the contract expiring in March and the order that was late last week. That relationship is what an isolated agent cannot produce on its own, because it lives across systems it never sees in full.
A Company Brain models that relationship in three pieces. The knowledge graph holds the business's entities and the links between them: customer, contract, ticket, order, person. The business ontology holds what each term means in this specific company, because "active customer" has one definition in sales and another in finance. The semantic layer translates the natural-language question into the correct data, with the correct permission.
Modeled once, that set stops being one agent's property and becomes infrastructure for the next ones.
The architecture decision behind the sharing is to serve context instead of copying it. The brain is exposed to models and agents through an open protocol for connecting models to data sources: MCP.
In practice, every agent asks the same place. The support agent asks for that sender's contract in force. The sales agent asks for that account's ticket history. Both get the slice the question requires, assembled over the same graph, with the same definition of each term. The data stays inside the company's perimeter, and no copy of the base ever enters the model provider.
When someone corrects the ontology, the correction holds for all three agents at the same time. The learning stops dying inside the tool where it happened.
This is where the math changes for whoever decides where to put next quarter's engineering.
Speed of implementation: the sources are connected once. The second use case starts from the graph and the ontology that already exist, with no new round of integration to open. The third starts from the second, with no data or AI team paying the integration cost again.
Cost: context that arrives organized is smaller context. Fewer tokens per call, less prompt rework, and the chance to run the same task on a cheaper model, because the work of figuring out what matters moved out of the model's reasoning and into the layer that prepares the data.
The objection shows up fast. If every agent reads from the same place, someone ends up seeing what they shouldn't.
Permission comes from the source system. Through the agent, each person receives only the data their profile already sees in the ERP or the CRM, and the sales agent never becomes a back door into the invoice the salesperson never had access to. No new project writes access control from scratch.
Every answer also points to which system the data came from, which lets you check it before acting on it.
Modeling an entity and settling the definition of a term is work for people who know the business, and the first version of the ontology will be wrong somewhere. That gets corrected with use, as real questions show where the modeling does not match the operation.
The brain also does not invent what nobody recorded. If the shipping step only exists in a spreadsheet filled in at the end of the day, the graph has a hole right there.
And agents keep their own conversation memory. The history of that specific interaction belongs to that agent. What becomes common is the structure of the business underneath it.
Take a term two of your agents treat differently today and write down which definition holds. Then list the five or six entities that show up in almost every question the operation asks. That is the starting cut, and it fits into a few weeks of work.
At Strattum, that is how we come in: a real question, the sources it requires, and context modeled to also serve the next agent. If you want to test the cut for your own company, reach out here.
Talk to a Strattum expert about the starting cut: the terms, the entities and the sources it requires.
