In short
A system that gets quotes from suppliers, opens on-call incidents or sends a copy of an invoice queries systems, carries out actions and chains steps until the task is done. Systems like this are called AI agents. Building one that works in a demo has become quick. Taking it to production and keeping it correct as the data, the business rules and the model change is the longer job, and it depends on the context that arrives at each step. That context is what the Company Brain organises: the layer that knows the company, meaning what data exists, where it lives, how it relates and who can see what.
AI agents are systems in which a language model plans the steps of a task, calls tools and reads the result of each call. Based on that result, the system selects the next action. The cycle repeats until the task finishes or a limit stops the run.
The pattern took shape in 2022, when researchers from Princeton University and Google proposed interleaving the plan generated by the model with actions in external tools, in a paper called ReAct. For a purchase requisition, the agent reads the internal request, checks the approved suppliers, requests quotes, compares lead time and price and puts together the requisition for approval.
The three terms show up together and describe different systems:
The architecture varies between frameworks, and the same building blocks recur in every AI agent:
The anatomy of AI helps locate the problem. The mouth is talking with AI, such as chat and summaries. The hands are acting with AI, with the agent that writes into the system. The eyes are observing with AI, such as transcription and document reading. The brain and memory are the Company Brain.
AI agents are hands, and hands without a brain act on incomplete data. A collections agent that only queries the ERP sends a copy of an invoice the customer paid the day before, because the payment is still only in the bank statement. The collection notice reaches the customer, and someone has to explain and undo it.
In the pilot, this error rarely shows up, because someone follows every run. In production, volume grows, exceptions appear and nobody checks every step. That is where many projects stall.
What the agent was missing was the link between records. In the Company Brain, the knowledge graph links the invoice to the payment, the customer and the contract, even when each record lives in a different system. The business ontology defines what an open invoice means at this company, with the reconciliation rule agreed between collections and the controller's office. That context reaches the agent via MCP, the open protocol that connects models to data sources.
The prototype proves the task is possible with prepared questions and a slice of data exported the day before. Moving to production depends on decisions the prototype usually leaves for later.
Each step of the cycle is a call to the model, with the history of the earlier steps in the window. When the agent has to search several systems to build the picture, each search becomes one more call, and the text sent again grows with every round. Token cost rises with the number of steps.
With the context already resolved by the Company Brain, the agent receives the invoice linked to the payment in a single query. That cuts search steps, reduces the text in each call and makes it possible to run some of the steps on a cheaper model.
Every tool exposed to the agent is a possible action. A collections agent needs to look up invoices, look up payments and generate an invoice copy. A generic tool for writing to the ERP widens what it can do wrong without widening what the task requires. Narrow tools also make testing easier, because each one has known inputs and outputs.
An agent with a broad service credential sees everything the credential reaches, whoever triggered it. With permissions inherited from the source, the agent triggered by an analyst sees what she already sees in the ERP. Every piece of data used points to its source, which makes the action auditable.
A wrong action costs more than a wrong answer. An improper refund or a duplicated requisition creates rework and, sometimes, contact with the customer. Actions such as payments, contract changes and external communication go through human review: the agent prepares the action with the sources that support it, and a person approves it. Looking things up and drafting run without approval, because they can be undone.
The first agent works best on a task that repeats every week and whose action can be undone without harm, such as putting together a purchase requisition for approval. Frequency produces volume to measure accuracy and cost. Reversibility limits the damage of each error while the operation gains practice.
In production, four things change at once. Questions arrive written by real people, with abbreviations and requests that mix two subjects. The data becomes today's data, with incomplete records and fields filled in different ways. Business rules change by decision of whoever owns them, without warning the team that built the agent. And the model vendor releases new versions.
An agent that answers resellers about price, payment terms and volume discounts shows the effect. Three months after launch, the price list has changed twice and the discount policy has gained a regional exception. The routine of whoever runs AI agents in this situation looks more like that of a product team than that of a project with a delivery date. It has six fronts:
Without a named owner, each area assumes the task belongs to the other, and the agent keeps answering with last quarter's rule.
Model and prompt change when someone decides to swap them. Sources change for reasons unrelated to the agent: the ERP gains a field, finance creates a new payment term category, sales starts recording the discount somewhere else in the CRM.
The most expensive effect is the silent break. When finance splits the standard payment term into two new categories, the agent that looked up the old category keeps answering. The answer comes out fluent, with no technical error and with the wrong condition, while the availability dashboard shows the system as healthy.
This kind of failure in AI agents only shows up when someone compares the answer with the rule in force. That is why the evaluation with real questions runs even when nobody has touched the agent.
When each agent has its own integration with the ERP and its own rules in the prompt, every change at the source means reviewing all of them. With three agents consulting the commercial policy, the same change is made three times, by different teams, on different dates.
In the Company Brain, the definition of payment terms lives in the business ontology, linked to the ERP records by the knowledge graph. When finance creates the new categories, the area updates the definition once, and the AI agents that query the term via MCP receive the new rule on their next query. The next agent also starts from this layer, with no new integration per system.
Permissions follow the same logic. If a regional manager loses access to a product's margin in the ERP, the agents stop delivering that margin to him, with no adjustment to each one.
When investigating an error, traceability shortens the path. Every answer shows which records were read and which definition was applied, and whoever runs the agent can tell whether the problem is in the source, the rule or the prompt.
The Company Brain delivers what the sources record. If the ERP posts the payment late, the context arrives late, and the fix happens at the source.
The decision on each rule stays with the area that owns it, and someone has to record the change in the ontology when it happens. Continuous evaluation is still needed too, because a correctly updated definition still produces bad answers if the agent's prompt assumes the old rule.
The practical starting point brings the task and the operation together. Once the frequent, reversible task is chosen, the sources it depends on are listed and connected to the Company Brain before the agent is built. Then three definitions go into the plan:
The second agent reuses the connected sources, the part of the context the first one left resolved and the same evaluation routine.
