Ainary

Ontology for AI agents: the best time to start is now

An agent that answers differently on the second run is not a system. It is a demonstration. The distance between the two is not a modelling problem, and no prompt will close it — which is the practical case for building an ontology for AI agents before building anything else on top of them.

The layer beneath carries everything above it. Swap the plates on top and the work still lands — because the structure was never in them.

The evidence is not ambiguous. Roughly 95% of enterprise AI pilots deliver no measurable value, and the crossing into production tends to fail for organisational reasons rather than technical ones. Ungoverned AI work does not scale, and the reasons are unglamorous: it is not reproducible, it leaves no audit trail, and it drifts differently for every person who touches it.

None of that is a capability gap. It is a structural one — and structure is the part that can be fixed without waiting for anything or anyone.

The word “ontology” carries enterprise baggage: consultants, workshops, a diagram nobody maintains. At founder scale it means something considerably smaller. Database schemas plus discipline. It is not designed on a whiteboard; it is harvested from work that already happens.

Five moves. One task. One afternoon.

1.0The five moves

Harvest · Home · Edges · Gate · Version

Revised, not finished — the map stays true to the work01Harvestwhat exists02Homeone place, one name03Edgesonly what answers04Gateyou approve05Versiondated, never deletedFIG 1.0

FIG 1.0 — Harvest · Home · Edges · Gate · Version.The heavier outline marks the one step that stays human.

  • 01 — HarvestHarvest, don't design.List the object types the business already uses: customers, offers, projects, reports, standards. This is not the construction of a new world. It is the written record of the existing one.
  • 02 — HomeOne home and one name per type.Every object type gets exactly one permitted place and one naming convention. This single move removes the most common source of drift — before anything is automated.
  • 03 — EdgesWrite down the connections that matter.An offer hangs on a customer. A report hangs on a decision. Record only the edges that answer a question actually being asked. The rest becomes maintenance.
  • 04 — GateDefine one gate.One point at which a human approves. The model produces and flags what it is uncertain about — it never approves itself. One gate is sufficient to begin. Nine gates is a bureaucracy.
  • 05 — VersionVersion from day one.Every change dated and explained. A changelog is what makes it possible to reconstruct, six months later, not only what the system does but why it does it that way.
The machine worksYou decide
2.0What it makes possible

The same task, before and after

Consider something small and entirely ordinary: a report that has to reach a customer as a PDF, in the company’s corporate identity. Every organisation has a version of this task. Here it is, run two ways.

Before — the good demo
  • The model is asked for the report. It produces something reasonable.
  • The formatting is almost right. The gap is closed by hand.
  • A month later, the same request returns a different structure and a different tone.
  • Two versions now exist. Which one the customer received is a matter of memory.
  • The file lives in a downloads folder, connected to nothing.
  • Nobody else can run this. On close inspection, neither can its author.
After — one linked chain
  • The report is an object. It has one home and one name.
  • The CI is a standard, and it carries a version. The export obeys it.
  • The export is an action. It runs against the standard, never freehand.
  • A human approves before it leaves. That is the gate, and it is the only one.
  • The PDF is filed, linked, and traceable back to the run that produced it.
  • Next month it runs identically. So can a colleague.

FIG 2.0 — Nothing here is exotic. It is five objects that know about one another.

What that buys — the actual return

  • Repetition.The second run matches the first. That is the entire distance between a demonstration and a workflow.
  • Delegation.Someone else runs it and gets the same result, because the standard sits in the system rather than in one person's head.
  • Proof.When a customer asks what happened, the run can be shown: the input, the standard applied, the approval, the output.
  • Compounding.The next workflow reuses the same objects. The second task is faster than the first. The tenth is considerably faster.
  • Model independence.Swap the model — one to plan, another to execute — and the output remains inside the standard, because the standard was never inside the model.
Models change. Processes don’t. That is the whole bet.

The PDF in this example is not hypothetical. It was produced by exactly this chain — gated, logged, and traceable. The artifact is the proof of the process.

One run, five objectsSanitized demo
Object
Reportlives in exactly one place, named by convention
Standard
CIversioned; governs typography, colors, layout
Action
PDF exportruns against the standard, never freehand
Gate
Approvalhuman · before every write
Asset
CI PDFfiled, linked, traceable to the run

The same chain carries sales, finance and content. Only the objects change.

3.0Start small

The first value arrives with the first linked object

No map of the company is required. What is required is two things that know about each other.

That is the whole of it, and it is why this is worth beginning today rather than scheduling for a quarter that will not arrive. An ontology pays from the first link, not from the last one. Connect a report to the standard it must meet, and that report is better tomorrow. Nothing else needs to exist yet.

One qualification, stated plainly: for a genuinely one-off task — never repeated, never audited — this does not amortise. Do it by hand and move on. The rule is narrow and it holds: ontology first for everything that repeats, and everything that has to be trusted. In most weeks, that covers more ground than expected.

The first afternoon
  1. One task that repeats.Not the largest. The one that was most irritating this week.
  2. The objects it touches.Usually three or four, in plain language. That list is already an ontology.
  3. A home and a name for each.One place, one convention. Most of the drift disappears at this step.
  4. The two or three edges that carry the work.The rest can wait until a real question demands them.
  5. A gate before the irreversible step.The single moment where a human should look — before something is sent, published, paid, or deleted.
  6. A version number and a date.Version 0.1 is a complete ontology. It is simply a small one.

By the end of that afternoon, one task runs from zero to one — reliably, repeatably, with a record of what happened. Not a pilot. A working piece of the company.

From there it grows the way it should have been built in the first place: outward from work that already runs. Each subsystem added compounds against the ones already in place, because they share a language. There will never be a day on which the ontology is finished — and there never needs to be.

The value does not arrive when the map is complete. It arrives the moment the first two objects know about each other.

Book a pilot.

01 See a live output02 Run a two-week pilot on your worst workflow03 Keep what works, or walk away
Book a pilot Or keep running a hundred half-finished tasks by hand.

Built in public

One system. Your team, at scale.

Get updates before anyone else. No noise.

Building in Public →