Every vendor can rent the same model. Your moat is somewhere else.
Matías Bonvin· Updated
A model can be bought by many companies. The useful question is what remains yours after the first implementation: resolved data, operating rules, tested connectors and a team able to run the workflow.
Make company context reusable
Ontology is a word designed to lose the room, so here is the version that survives a board meeting. An ontology is a written map of your business. What things exist, how they connect, and which combinations are forbidden. A payment settles an invoice. That invoice belongs to a supplier. A discount above a threshold needs a signature. Write those rules down precisely enough and software can follow them without you in the room.
Models differ in quality, latency, cost and deployment constraints. Replacing one still requires evaluation. Keeping company context and interfaces portable gives you options when those tradeoffs change.
Data quality is a concrete implementation dependency. Check source ownership, identity matching, permissions and update frequency before relying on an agent to use the records.
You already own an ontology, by the way. You just keep it badly.
A payment left your account on Tuesday and settles an invoice. The invoice belongs to a supplier. The supplier is the company whose account manager you have been emailing for two years. Except the name is spelled three different ways across your inbox, your bank feed, and your ERP, and the contract that sets the price sits in a thread somebody would have to go and find. You hold the links in your head. That is why you can tell whether the payment was correct and your software cannot.
Here is where you need to be careful, because two completely different products are now sold under the same word, and the cheap one's reputation is doing the expensive one's selling.
The first product is a folder of notes. Documents, conventions, decisions, chunked and vectorised so a model can search them. Ask it a question and it retrieves whatever sounds most like an answer. The second has typed entities, business constraints, and rules that get checked when data arrives rather than when somebody asks. Client assigned to contract, order contains parts, parts produced on a machine the contract also covers. Slow to build. It survives contact with a business that changes.
A buyer comparing quotes has no way to tell which of the two is in the room, because the vocabulary gives no help at all.
A retrieval layer can supply evidence but does not enforce transaction integrity. Preventing a duplicate refund requires authorization, idempotency and validation in the executing system. A typed business model helps, but it does not replace those controls.
Now the part of the pitch that should make you slow down.
The sales motion goes like this. Your data is your durable advantage. Models cannot replicate it. Therefore bring it to us, and we will model it into an ontology that mirrors how your company runs. Every step of that is true except the therefore.
It skips a layer. Between "you own valuable data" and "so hand it over" sits the actual work: cleaning, resolving which supplier in the bank feed is the same company as the one in the ledger, enriching the records, embedding your business rules so they get applied on arrival. That layer is where the value gets made. And if it happens in a vendor's format, on a vendor's side of the fence, the value transfers along with the data. You have secured nothing. You have rented your own advantage, from the party best placed to raise the rent.
I have written before about companies that lease a capability and call it a transformation. This is the same trap wearing better vocabulary. An architect draws the map, builds the first structures on it, and hands you the keys and the blueprints. A tenant pays every month to keep living inside a map of his own company.
A mid-market company may have a small internal IT team, an external partner or both. Scope the first workflow to the operating capacity that will remain after launch.
Refuse the big bang. Nobody needs their whole company modelled in year one. Take the one operation that already hurts, the reconciliation that eats your finance team's Fridays or the quoting process that depends on one man's memory, and model that. Which entities, which links, which rules, which combinations are forbidden. Ship it. Let it pay for itself. Keep the modelled part, because the next operation gets cheaper once the shared context exists.
Two conditions make it yours. The resolved data lands in your database, in a format you control, on infrastructure you could move. And the model layer on top stays swappable, so when the next generation arrives you take the upgrade instead of renegotiating your own memory back from a supplier.
Keep export, access and a tested handover in the agreement. Optional managed support should preserve those rights rather than make them depend on renewal.
A 30-minute Strategy Session can examine the first workflow and recommend what needs mapping or testing next.
Look at your case
Bring one knowledge or control problem. A 30-minute Strategy Session helps identify what needs mapping or testing next.
Request a Strategy Session →