Most corporate AI projects started with assistants that answer questions. The next stage, already under way, is agents that carry out actions: they open tickets, apply discounts, update records and issue orders. That shift changes what an error costs. A wrong answer can be corrected by whoever reads it, while a wrong action enters the system and starts steering other decisions. Which is why 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), becomes a requirement that comes before the first automated action.
When an assistant states the wrong deadline, the person receiving the answer can still check it. When an agent applies a discount to the wrong account, the amount is invoiced, the customer receives the invoice and the finance team starts working from an incorrect record. Correcting it takes a reversal, a conversation with the customer and, in some cases, an accounting review.
The difference between the two scenarios is the trust that processes place in a record. Information written to the ERP or the CRM is treated as true by the steps that follow, and few of them check again what has already been recorded. A Company Brain reduces that risk because it organises the context before the action is written.
A meaningful share of agent errors in a corporate environment starts with identifying the entity. The same company can appear in the CRM under its legal name, in the ERP under its tax id and in the helpdesk under its email domain. If the agent does not know that the three records are one customer, it can apply the right rule to the wrong record.
The Company Brain’s knowledge graph settles that link before execution. It connects the records across the different systems to one another and to contracts, orders and tickets. The agent receives the customer already resolved across systems, with the relationships it needs to weigh the action.
The second source of error is what the terms mean. A policy authorising an extended deadline for customers in good standing can be read in more than one way: finance goes by the original due date, while collections goes by the renegotiation agreement. Two agents consulting the same policy reach opposite decisions about the same customer.
The business ontology records which definition applies in each rule. When the agent consults the policy, it also receives the definition of the term that determines eligibility, and applies the same criterion an experienced analyst would.
An agent that carries out actions combines two distinct capabilities: consulting context, and triggering tools in the company’s systems. The two are usually implemented together, inside the agent itself, which forces every new agent to rewrite the integration, the business rule and the access control.
The Company Brain keeps context outside the agent. Entity resolution, term definitions and permissions sit in a shared layer that any agent consults before acting. The execution tools stay specific to each use case and start from the same understanding of customers, contracts and rules. When a definition changes in the ontology, every agent applies it on its next execution, with no individual review of each one.
An agent that carries out actions operates on someone’s behalf. If it is given unrestricted access in order to work, it comes to see and change records the person themselves could not see. That design tends to appear during the pilot, when the priority is to show a result, and it turns into an obstacle at security approval.
In the Company Brain, the semantic layer applies the permissions of whoever triggered the agent. Access is inherited from the source system, which removes the need to maintain a parallel control inside each agent. When a permission changes in the ERP, it changes for every agent acting on that person’s behalf.
Auditing an automated action depends on knowing why it was taken. A discount applied by an agent has to be tied to the contract clause that authorised it, to the record that confirmed eligibility and to the person on whose behalf it was executed.
In the Company Brain, context is served to the models over MCP, an open protocol that connects models to data sources, and every query names the system and the record it came from. With that trail, the action can be reconstructed months later by somebody who was not there when it ran.
The Company Brain does not remove human review from actions with greater consequence. For irreversible or high-value changes, the recommended design keeps a step where a person approves the execution, with the context already organised for that decision.
Nor does a context layer settle a rule nobody wrote down. If the discount policy depends on case-by-case judgement with no recorded criterion, automation should wait until the area responsible defines one.
As a starting point, the safest choice is a reversible, frequent action, such as updating a field on a record or classifying a ticket. It lets you validate the Company Brain’s entity resolution, term definitions and permission inheritance before automating anything with a financial impact.
Talk to a Strattum expert about entity resolution, business ontology and permission inheritance for the agents that execute inside your company.
