Every business already has an operating system. It lives in the ERP's tables, in the CRM's pipeline stages, in a shared mailbox, in a planner's spreadsheet, and above all in the heads of the people who know which rule applies when. AI systems work when they are built on that model. They fail when each one is built on a fresh extract and a prompt.
Five layers, one model
We describe the model in five layers, from the bottom up.
Systems. The ERP, CRM, PLM, mailboxes, documents and live feeds the company already runs. Nothing is replaced and nothing is migrated. Data reads up into the model, and approved actions write back down through a gate.
Meaning. The objects the business talks about, with their properties and the links between them: customers, orders, parts, invoices, suppliers, contracts, shipments. This is the layer that makes the model reusable. A part is a part whether the use case is quoting, procurement or engineering change.
Motion. The actions the business can take and the rules that bound them: approval thresholds, contract terms, walk-away floors, hold and release conditions. Typed, versioned, and tested on the company's own history before they touch a live process.
Judgment. The models that extract, match, forecast and draft, the evaluations that hold them to a quality floor every week, and the scenarios that show what a decision would do before anything writes back.
The loop. People and agents work on top. A person approves what matters, approved actions write back, and every decision returns to the model as data. That last step is why the model sharpens with use.
Why this compounds
The first use case has to build part of every layer: connect the systems, model the objects it touches, write its rules, set its evaluations. That is real work, and it is why a first system takes a quarter rather than a fortnight. The second use case inherits all of it. The objects are there, the connections are live, the approval gate is configured. It adds its own rules and models and ships in weeks. By the fourth or fifth, the marginal cost of a new use case is mostly the time it takes to agree the baseline.
This is the difference between buying tools and building an asset. A stack of point solutions gets more expensive and more fragile with each addition. A model of the business gets cheaper to extend and harder to replace.
Governance is a property of the model, not an afterthought
Because every system reads and writes through the same layers, governance can be built once: permissions on objects, an audit trail with the source behind every fact, human approval on any action above a threshold, and the whole thing running in the client's own tenant and region. Each new use case inherits the controls rather than negotiating them again with security.
What it asks of the client
Two things. First, access: to the systems, and to the people who know the rules, for a few hours a week during the build. Second, a decision about ownership: the model, the data and the intelligence layer belong to the client, in their tenant, from day one. We build it with them, not around them. That is a harder commercial model for a vendor than a licence, and it is the only one we think survives contact with an operation.