Operational AI glossary.

Operational AI runs a company’s operations in production, owned by the people who depend on it.

These are the definitions we use, written so each one has an edge. A term that only says what something is can be swapped for anyone else’s. A term that also says what it is not can be argued with, which is the point.

Every entry is defined here and argued somewhere else. The link under each one goes to the page that makes the case, so nothing on this site has to be said twice.

The category, in full
The category

What operational AI is, and what it rests on.

The distinction is not technical sophistication and it is not scale. It is whether the system is load bearing, which is to say whether the business would notice if it stopped. Almost everything sold as AI fails that test, because it sits beside the operation rather than inside it. Operational AI is specifically not a pilot, not a chatbot, and not a model licence.

The category, in full

The useful, ordinary case, and worth doing. It is simply a different thing. Applied AI produces an output when asked; operational AI produces output continuously without being asked. Applied AI sits beside the operation in a tool someone opens; operational AI sits inside the pipeline the business already runs on. If it stops, applied AI makes a task slower and operational AI makes the business notice the same day.

The category page

Deliberately blunt, because almost every other measure of AI maturity can be satisfied without anything actually changing. Usage, satisfaction and hours-saved surveys can all look healthy around a system nobody would miss. Load bearing is binary, and it is asked about the operation rather than about the tool.

Where the test comes from

Which definition of revenue is the right one. Why a number is calculated one way and not another. Which of two disagreeing reports to trust. Most of it was never written down and some of it lives in one person's head. It compounds: every year of undocumented decisions makes the next automation harder. You cannot automate what nobody can explain, and a model given vague context produces confident, wrong output faster than a person would have.

The category page

The discipline behind level four. It is not prompt engineering, and it is not wiring an agent framework to an API. The work sits in the specification and the tests: the spec is the argument, the tests are the proof, and the model does the typing. What makes it engineering rather than experimentation is that behaviour is defined before it is built and verified after, so the system can be changed by someone who was not in the room when it was written.

The category page

It is not an archive. An archive is judged by how much it keeps, a brain by how little it makes the model rule out. A brain that is not maintained is a snapshot: accurate on the day it was built and quietly wrong every day after, until the people relying on it learn not to.

The paper

Mechanical work with clear success criteria: whether a link still resolves, whether two pages contradict each other, whether an index still matches the directory. It does not need a frontier model, which matters when the checks run every day. It is the part that decides whether everything else was worth doing.

The paper
The four levels of adoption

Where an organisation actually sits.

AI is absent, or confined to a feature someone opens occasionally. The knowledge of how the business runs lives where it always did: in heads, in spreadsheets, and in pipelines nobody owns. Nothing about the operation is written down in a form a system could act on.

People use AI on their own initiative, mostly to draft and summarise. Output improves in pockets and none of it is captured. Nothing compounds because nothing is written down, so removing the individual removes the gain. Measured by what is actually written down, this is where most organisations are, including many that place themselves at level three.

The work itself is rebuilt around AI rather than assisted by it. Context, specs and tests are documented, so the same capability can be run repeatedly by anyone rather than only by the person who invented it. Output stops scaling with headcount and starts behaving like an asset: build it once, deploy it across domains.

Agents carry defined work day to day against documented context, and the human job moves from producing to reviewing. The organisation's knowledge lives in the system, so it survives the people who built it. This is what we mean by operational.

How the work is done

The method, named.

The three layers an operational system stands on. Tools are a commodity and were never the constraint, context is undocumented and is the whole job, and people are the ones who own it after we leave. The claim in the word is that the three fail together: the best model against undocumented context produces confident nonsense, and perfect documentation nobody on your side can change is on loan rather than in production.

The category page

Same repo, same tools, same constraints, building alongside the people who know how the operation runs. It is not staff augmentation, and it is not consulting with a shorter feedback loop. The defining property is that the engineer owns the whole lifecycle, design through deployment through keeping it stable, rather than handing over a recommendation and leaving.

How we deliver

The spec is the source of truth and it exists before a line of code does. That order is what makes AI-assisted work reliable, because a model is only as good as the context it is given and a precise spec is that context. The work becomes reviewable before it is built rather than after. And a spec is an asset: build it once and it deploys across domains, so output stops scaling with headcount.

How we deliver

Not a documentation drop and not a training day. Logic is versioned, every metric has one definition, and the team is trained on the same tools the system was built with. The test is whether they can change it without asking us what it does: a system nobody on your side can modify is on loan, not in production.

Production

It is what makes an engagement scopeable in weeks rather than quarters, and it is what lets us say no to ideas that are interesting but not load bearing. A capability that cannot be placed on it does not get built.

The problem phase

Not a demo environment, and nothing ships from it untested. It is where specs get proven before they touch production. The distinction matters because a sandbox running on synthetic data proves nothing about a real operation.

The prototype phase
Work we turn down

Terms we use to say no.

A proof of concept answers whether something could work. By the time that has been answered, the same effort would have shipped the thing itself. If the deliverable is a verdict on whether to proceed, someone else should run it.

The definition

The most common thing sold as enterprise AI, and the clearest example of what operational AI is not. Switch it off and the operation continues exactly as before, which is the whole diagnosis.

The definition

It makes individuals faster and leaves the organisation exactly where it was, because nothing gets written down and nothing compounds. Whatever the programme cost, the organisation ends it at the same level it started.

The definition
Trusted by
Novo Nordisk FondenDanske BankCarlsbergDHLPas Normal StudiosBauer Media OutdoorNTGCurrentumDanske SpilDCAIDKBSGreenpeaceIIP DenmarkMT HøjgaardTeklaTeliaVivinoLovableDatabricksMicrosoftSnowflake
Contact

Change how
you operate.

Tell us where you’re stuck. If operational AI can change the outcome we’ll show you how, and if it can’t, we’ll say so.

Talk to us