How we build a company's ontology

Six layers, a handful of rules and one procedure: the model we write down before any agent runs. And the moment we tell a client that something far cheaper is enough.

The agent a company actually wants does work. It processes the order that came in by email. It blocks the shipment that should not leave. It prepares the credit note and finds someone to sign it.

To do that safely, software needs something almost no company has written down: a model of how its business runs.

We build that model before we build any agent. We call it the ontology: the company's operating model written down. What things exist, what functions compute on them, what actions may change them, and who signs each one.

What we call an ontology, and where the word comes from

The word is borrowed. Every data platform now sells something that sounds like it: the semantic layer, which is a dictionary of metrics. Each one is defined once, so every tool computes it the same way.

It comes from the architecture Palantir built for governments and multinationals, whose documentation insists on one point: an ontology integrates data, logic, action and security. We apply it somewhere else. A mid-size company has no data department and no three years ahead of it. It has an ERP, where orders, invoices and stock live. It has a CRM, where customers and complaints live. It has a spreadsheet somebody maintains by hand. And it has one person who already knows how the whole thing should work.

Building on that takes a different approach, and it is the one we use.

The semantic layer keeps its promise: everyone reads the same numbers. What it does not carry is the authority to touch any of them. And that is exactly what our agents are hired for.

A metrics dictionary describes. An ontology also authorises.

The six layers we build, and in what order

Conversation is the only layer anyone notices. Five more stand under it. Each one works only because the one below it does.

At the bottom we connect, each system by its own route. Then we model, which means writing the business down for machines. Then we replicate into a twin whatever has to be crossed: a mirror copy where two tables that never met can finally sit side by side.

The other three stand on those. Agents execute. Governance holds every write until someone signs it. And conversation is where people ask.

The stack is valuable before it is finished, and that saves clients money: a model with functions answers a customer's available credit long before any agent writes anything.

How we authorise every change to a client's systems

One rule governs the entire write side: nothing writes to a client system except through a typed action.

A typed action is a change declared before any agent may run it. Its definition carries everything it needs to be safe: parameters, validations, who may run it, whether someone must sign first, how long the result can be undone, and an idempotency key.

That key is a fingerprint that makes a repeated operation run only once. A boring example shows it. An order arrives by email, the agent processes it, and the mail server delivers the message twice. Without the key, the order is created twice. With it, the second attempt dies quietly.

A duplicated order does more damage to trust than a month of wrong dashboards.

Who computes the figures, and why never the model

An improvised total is the fastest way to lose a finance director. Language models read intent well and calculate badly, and it has been measured: in 2023 they got 55 and 59 per cent of three-digit multiplications right, and in 2024 one extra sentence in the wording dropped accuracy by up to 65 per cent. Today's models score better; the error still shows up when the problem gets harder.

Hence the second rule: a language model never calculates a figure.

Every number a person sees comes out of a deterministic function, which returns the same result from the same data. The model only presents it.

Questions come at two levels and our functions do too. A base function reads one thing: the unpaid invoices, the credit limit. A high-level function composes several and returns the answer with its breakdown.

Ask for a customer's available credit and you see the limit, minus unpaid invoices, minus pending orders. Every line of it in view. The client wants to see the subtraction, and the day someone disputes the figure, they dispute one invoice.

Illustrative design figures, not a client's: they show the shape of the breakdown, which is what gets argued about when someone argues.

Splitting the functions splits the answers too. The list of pending orders is data and returns as it is. "Which of these looks at risk" needs the model, and that part is labelled as its reading, next to figures it did not compute.

How we join data from systems that never talk to each other

The hardest everyday questions cross two systems that have never met. Which customers with unpaid invoices opened a complaint this month. The CRM knows about complaints. The ERP knows about invoices. And there is no place where those two tables can be joined.

Our answer is a twin: a mirror database holding copies of only the tables the model needs. Each copy declares its cadence, because freshness has a price. Balances, every thirty minutes. Catalogues, once a day.

Whatever must be current to the second is fetched live from the source. The state of an order placed this morning, for instance. Documents already work this way in our product: manuals and web pages go into a searchable index that answers with citations.

Connecting is the least glamorous part. When a client's ERP has no API, we put a small computer in their office running a private MCP server, a connector that exposes the agreed queries. It reaches the database locally and feeds the twin through an encrypted tunnel.

The twin is read-only for every agent. Anything wrong in a replica gets fixed in the source system, through an action, never in the copy.

Where it lives is the first question any legal team asks. Each client has their own database, isolated from the rest, on our infrastructure inside the European Union. The twin is a separate schema inside that same database, close enough to join in one query.

The credentials are not kept there. They sit in a separate store, so a full dump of a client's database exposes no password at all.

And when a source stops syncing, the twin says so. The answer arrives stamped: this balance is from 05:12, the ERP has not synced for three hours.

Which part of the company gets modelled first, and how

Modelling the whole company first is the most common way to fail, and the failure is on record: Gartner expects over 40 per cent of agentic AI projects to be cancelled by the end of 2027. We measured it on an open-source ERP so we could show the number: a fresh Odoo 19 has 134 tables, and with eight modules of an ordinary ERP on top (sales, purchasing, stock, accounting, manufacturing, CRM, people and projects) it grows to 644. A model that mirrors all of them takes so long that, by the time it is done, nobody remembers what it was for.

We build in the opposite direction. The procedure fits in six steps.

A generator runs that procedure and people decide. They confirm what it gets right, correct what it misreads, and say what stays out.

The model changes the way code changes: on a branch somebody reviews before merging. Nobody edits the live model of a company that is running on it.

The three kinds of agent we build on top

The ontology exists so agents can stand on it. We build three kinds.

Agents that answer, citing where every claim comes from. Agents that watch, firing on a schedule or an event, opening a case when something drifts. And agents that act, executing work end to end and stopping for a signature wherever a rule demands one.

Each kind earns the next. First answer. Then watch. Then act.

How an agent gets corrected, and what we keep from each sector

When a person corrects an agent twice on the same point, that becomes a stated fact, attached to the customer it belongs to. That customer wants delivery on site rather than at their office.

The fact carries where it came from, it expires on a date, and anyone can read it or delete it from that customer's own page. An agent that learns in private is an agent nobody can correct.

Vertical agents work with one sector's vocabulary and rules. One that processes orders for an industrial distributor has to know what a customer-specific price agreement is. One for an insurer has to know what risk appetite means.

That sector knowledge is the barrier and we keep it. We keep the shape, never the contents: each client's data lives in their own database, and their names, their customers and their figures never leave it. The second industrial distributor starts from the sector map, not from the first one's company.

The five controls in the govern layer

A large company worries little about software that answers badly. It worries about software that acts badly, and that is not a quirk of theirs: among European companies that considered AI and did not adopt it, in the latest Eurostat survey, 71 per cent cited a lack of in-house knowledge, 52 per cent a lack of clarity on legal consequences and 49 per cent data protection. The technology not being useful to them came last, at 21 per cent.

The govern layer decides whether the rest deserves trust, and its brakes act in an order.

The first is the one most often skipped, and the most expensive to skip: measuring and freezing what the task costs today. Intuition is no substitute, and that has been measured. In a trial with sixteen experienced developers, they believed AI had made them 20 per cent faster and they had been 19 per cent slower.

Rehearsing on old records is cheaper than weeks in shadow, but those records arrive incomplete. A comparison run this week is one anybody can check.

The snapshots are chained by hash, so each one carries the fingerprint of the one before it. Months later, an August order is audited with August's numbers.

And it stops being a preference of ours the moment the case falls under the high-risk annex of the European AI Act, which applies from August 2026.

The remaining rules are in the report: the undo window, the closed menu of rejections, the model exportable from day one, and how external content is treated, as data and never as an order. That last one is not spare caution: prompt injection is number one on the OWASP risk list, and still was in August 2026. Silence never signs either: a case that expires without an answer is not executed.

Four of our systems running today, with their limits

None of the above is a plan. Three of these models are running and one is open to the public, each with its figures and its declared limit published, and each sits on a different rung of the ladder.

The logistics one watches an automated warehouse in real time, with twenty-four rules over live data from the warehouse manager and the ERP: over thirty million operations on record and 460,000 locations. The thresholds come from measuring that same data. Its limit is written down, and it is the limit of an agent that watches: it detects, explains and warns, and it never moves an order or changes a priority.

The B2B one recalculates the health of 29,000 customers every night over more than fourteen million sales lines, and warns the salesperson when an account breaks its rhythm. The rhythm is each customer's own, measured over their last two years. That decision belongs in the model rather than in the query behind a report: one threshold for everyone would have called half the customer file dormant.

The support one climbs a rung and already drafts replies. Each type of enquiry carries its own autonomy level, from suggested draft to verified reply, and levels rise only with approval and drop by themselves when quality falls. A negative tone or a legal mention always goes to a person.

And one faces the public: a specialist shop's assistant answers on catalogue and terms, and starts defined procedures against the shop's ERP, a return among them.

The three internal ones share the same first step, the one this piece describes: writing down what data exists, what processes move it, and what rules govern it.

Three mistakes of ours, and what they changed

Everything above is written after getting it wrong. Three of those mistakes explain why the procedure has the steps it has.

The greeting in the wrong language. An assistant facing the public answered the first message in Spanish even when the visitor had written in another language, and only got it right from the second message on. The cause was not translation: language was treated as a property of each message rather than of the visitor. It is now session state with a written precedence, and that precedence is tested against cases before anything is switched on.

The inbox nobody copied in. A support agent was designed to read a corporate inbox that people were supposed to copy in. For weeks, almost no mail arrived. The system worked perfectly and had nothing to read, because it depended on a new human habit, and a new habit is not data: it is an assumption. Since then, when a phase depends on someone changing a routine, that gets written down as a risk before the work starts.

The key that belonged to accounting. At a manufacturer selling through subsidiaries, the field that looked like the customer identified who gets invoiced, not who buys. The distinction their sales team uses every day was recorded nowhere. That is the failure we have seen most often, and it is the entire reason for the second step of the procedure: read a real sample of records before naming anything. Column names lie.

When we tell a client they do not need an ontology

Many of the companies that ask us for agents only need the cheaper thing, and we say so in the first conversation. When the pain is two dashboards disagreeing about last quarter, a semantic layer closes the case with far less machinery.

The deciding question is a different one. Does software have to prepare or execute any of the decisions the company runs every day? If the answer is yes for even one, reporting tools stop being enough.

There is a fair objection to that frontier, and we hear it from well-informed clients: semantic layer vendors are adding agents and writes, so the line moves every year. It does move.

What survives is the checklist. When a semantic layer grows typed actions, deterministic functions, human signatures and a tamper-evident record of what was done, when and on which data, it has become an ontology, whatever its pricing page calls it.

The four phases, and what the client keeps after each one

It starts with one source connected and read. That alone answers questions that today cost someone an afternoon in a spreadsheet, and it happens before a single entity has been named.

Then the model gets written around the first agents, ten to twenty-five entities. The same questions start being answered with the company's own words instead of table names.

The first agent only answers, citing where each figure came from: nobody has signed anything and nothing has been written anywhere. The first typed action comes later, with whoever signs it, its undo window and its budget.

At every one of those steps the model is exportable and documented. If we stop on step two, the company keeps the map of itself that it did not have before. That map is worth the same whether we build on it or somebody else does.

An afternoon's exercise, with no software

The first exercise we run with every client costs one afternoon and no software.

Write down the five decisions your company executes every day. Releasing a blocked customer. Approving a discount. Reordering stock. Next to each one, note how it gets done today: which screen, which person, which signature.

Most companies will run both layers for years: the one that explains the business and the one that can touch it.

That list, in plain language, is the first draft of an ontology.