Ontology, Epistemology, and Axiology: The Three Questions Every AI Agent Has to Answer

TL;DR

Every AI agent silently answers three questions each time it acts: what exists in my world (ontology), how do I know it's true (epistemology), and what am I meant to value (axiology). Get one wrong and the agent doesn't break. It works perfectly, at speed, on a wrong picture of your business.



That's how one pair of trainers gets promised to three customers on a Saturday morning. An agent adds speed and confidence to whatever your business already believes, so a cleverer model rarely fixes it. Map what exists, ground the agent in verified data, and name the real goal along with its constraints. An hour with a whiteboard, before you write a single prompt.

Saturday, 9:47 in the morning. Somewhere in your business, the webshop has just sold the last size 8 of your best trainer – the same pair a click-and-collect customer reserved an hour ago, the same pair a shop assistant is, at this exact moment, boxing up for someone at the till. Three channels, three confident promises, one pair.

You know this moment. Every retailer with shops and a website knows this moment. Nobody planned it; it emerged, the way weather does, from systems that each hold a slightly different opinion about what's on the shelf.

Now give those systems a voice and a licence to act. That, stripped of the marketing, is what an AI agent is. The intelligence is real – a good agent reasons, plans, works through problems nobody scripted for it. But it aims all of that at whatever picture of your business you hand it. Hire the sharpest operations manager in the country, give them last Tuesday's stock report, and you'll get confident, well-reasoned, wrong decisions faster than before. If your systems disagree about that pair, the agent will promise it to a fourth customer – politely, fluently, and at scale

When agents fail inside a company, they rarely fail for the reason people expect. The model is fine. The integrations are fine. Even the barcode scanner is having a good day. What breaks is older and stranger than any of that. It's philosophy.

I've built automation for the best part of a decade, and the sharpest lens I've found for getting agents right comes from three words most of us last heard in a lecture hall and happily forgot. Ontology. Epistemology. Axiology. They're not decoration – they are, more or less, the three great branches of the subject.

What exists?

How do we know?

What matters?

Philosophers have spent two and a half millennia on those questions because they're hard. Your systems integration project has been rediscovering them the hard way since go-live.

Every agent you put to work answers all three, silently, each time it acts:

1. What exists in the world I work in? (Ontology)
2. How do I know what I know, and should anyone trust it? (Epistemology)
3. What am I meant to value, and how far will I go to get it? (Axiology)

The 9:47 pair is a failure of the first. Nearly every agent failure I see traces back to one of the three, and almost always because nobody asked the question out loud. So let's ask them out loud – with the philosophy taken seriously, the research behind each claim, and enough shop-floor detail that you'll recognise your own Saturday mornings.

First, what we even mean by "agent"

A quick definition, because "agent" has become the most abused word in tech. Strip away the marketing and the research community broadly agrees on the shape of the thing. An AI agent perceives its environment, reasons about what it finds, then acts to reach a goal – often across many steps, often reaching for tools along the way (Russell & Norvig, 2020; Franklin & Graesser, 1996). The recent surveys keep drawing the same line between an agent and an ordinary chatbot: an agent chases an outcome rather than handing back an output. It plans, it uses tools, and it carries a task from start to finish without you steering every turn (Sapkota et al., 2025; Piccialli et al., 2025).

Look closely and you'll spot a loop in that description – perceive, reason, act. Piccialli and colleagues (2025) frame it as perception, cognition, action, and it maps almost perfectly onto our three questions. The agent's picture of the world is its ontology. The way it handles knowledge and doubt is its epistemology. Its goals, and what it'll do to reach them, make up its axiology. I'm not straining for a metaphor here; it's one idea wearing two outfits, one cut in Athens and one in a research lab.

Worth being honest about where this sits in 2026. The hype has never been louder, and the numbers underneath it tell a quieter story: across nearly 2,000 organisations surveyed globally, around 88% now use AI somewhere in the business, up from 78% a year earlier – yet only about 23% have scaled an agent into even one function, and a slim 6% report real value across the enterprise (McKinsey & Company, 2025). If you've deployed something and quietly suspect it isn't paying for itself, you are not the exception. You're the large majority, and the reason is rarely the model.

Ontology: what your agent thinks exists

Start with the oldest question. Aristotle spent a good part of his career sorting reality into categories – substances, quantities, relations – on the conviction that before you can reason about the world you must settle what's in it (Aristotle, Categories). Twenty-three centuries later, Wittgenstein compressed the stakes into one line: "the limits of my language mean the limits of my world" (Wittgenstein, 1921). Whatever your vocabulary can't distinguish, your reasoning can't handle.

Computer science borrowed the word deliberately. Tom Gruber defined an ontology as "an explicit specification of a conceptualization" (Gruber, 1993), later sharpened to a formal, explicit specification of a shared conceptualization (Studer et al., 1998) – the academic way of saying: write down what exists, and the rules between the things, precisely enough that a machine can reason over it.

Here's the same idea in the language your systems already speak. Every ERP and WMS ships with a unit-of-measure table, and at some point somebody sat down and decided what the base unit is, what the supplier sells in, and how the two convert. Nobody schedules that meeting as a metaphysics workshop. That's what it is. A UOM table is an ontology in Gruber's exact sense – a formal, explicit specification of what counts as one thing and how the things relate. Retailers have been doing ontology engineering for decades under a duller name.

The trouble starts where two systems answer the same question differently. Is the navy version of that trainer the same product as the white one, or a different one? Ask your ERP and your webshop separately; enjoy the argument. What is stock? Your system says 3. But 3 what – on-hand, available-to-promise, allocated to an unpicked online order, sitting in the returns cage until someone checks it in, or on a display foot in the window? Those are five different kinds of existence, and if your agent's world contains only "stock: 3", it will sell the same pair four times with total confidence.

And what, philosophically speaking, is a customer? The loyalty card that buys in your shops and the email address that orders on your site are, to your systems, two strangers – and at your returns desk, one increasingly annoyed human being. Retail has chased the "single view of the customer" for two decades; it remains the industry's Loch Ness monster, frequently sighted, never photographed. That's not a data problem wearing a fancy name. It's an ontological dispute between your systems about what exists.

Nothing here is peculiar to retail, incidentally. Wherever two systems name the same thing differently – a patient and a service user, a candidate and a placement, a job and a ticket – the same dispute is running underneath, waiting for something to act on it

Your agent inherits every one of those disputes. It never works with your business as it is; it works with its model of your business. Hand it a model that's wrong, thin or fuzzy, and every decision downstream carries the flaw. The agent didn't oversell the 9:47 pair because it failed. It oversold that pair because its world contained "stock" but not "allocated", and it followed that map exactly. A map with one aisle missing.

I watch teams skip past this more than any other step. They agonise over which model to license and never ask the question underneath: does the agent hold a coherent picture of the world it's about to act in?

The research is unusually clear about the fix. Let a large language model loose and it fabricates roughly as often whether the truth lives in a database or a buried PDF, because it has no principled way to tell the two apart (Stardog, 2024). The cure is to ground it – tie the agent to an explicit model of the domain. A structured knowledge graph is really just your ontology with the data poured in, and once an agent reasons over one, accuracy climbs hard. One clinical study cut hallucinations by 61% that way (Farahani et al., 2026). A telecom team saw graph-grounded retrieval beat plain retrieval by 14.3% and an ungrounded model by 21.6% (Ahmed et al., 2026). Industry analysis citing Gartner puts the average gain above 54%, though that figure travels second-hand and I'd treat it as directional rather than precise (Atlan, 2026).

What does that mean on a Monday morning? Before you write a single prompt, sketch your domain model. Name the objects your business runs on – product, variant, location, order, customer – and, for each, the states it can occupy and the moves that are legal between them. An order can be paid, picked, collected, refunded; stock can be on-hand, allocated, in transit, on display. The good news is you won't start from a blank page: your item master, your UOM table and your status codes are already a partial ontology, written years ago by whoever configured the system. The work is dragging it into the open, reconciling the places where two systems disagree, and writing down the rules that currently live only in a supervisor's head. It's an afternoon with a whiteboard, and I'd argue it's the most valuable afternoon of the whole project.

Two habits protect that work afterwards. Don't let the model invent your taxonomy – leave "available" undefined and it will improvise a fresh meaning every time, none of them matching the stockroom. And match the rigour to the stakes: a friendly product recommendation can run on loose retrieval, but anything touching money, stock promises or a customer commitment belongs on structured, verified data. Then keep the whole thing alive, because ranges change, channels multiply, and a frozen ontology rots. Treat the domain model as an asset you tend, never a document you file and forget.

What one actually looks like

People nod along to "sketch your domain model" and then stare at a blank page, so here is the whole thing for a click-and-collect flow. This is not an extract. It's the lot.

Objects: product, variant, stock, order, location, customer.

States a variant's stock can occupy: on-hand, allocated, in transit, on display, quarantined.

Rules:

• Available-to-promise equals on-hand minus allocated. The agent quotes that number to customers and no other.
• Allocation happens at payment, not at basket.
• A return enters quarantined, never on-hand, until a human checks it in.
• A variant is a distinct sellable thing. Navy 8 and white 8 never share stock.
• An order moves paid → picked → collected, or paid → picked → refunded. It never moves backwards.
• Display stock is visible to shop staff and invisible to the webshop.

Six objects, five states, six rules. Any agent grounded in that can't make the 9:47 mistake, because "available" now has exactly one meaning and the agent has no path to the other four. Yours will look different, and it should. What matters is that it fits on a page and that two people from different departments both agree it's true.

Where to stop

The obvious objection: this sounds like a six-month data-modelling exercise before anyone ships anything. It isn't, and if it becomes one, someone has lost the plot.

Model only the slice the agent touches. If the agent answers stock questions, you need stock, variants and locations – you do not need a canonical definition of "customer" before you start, however much the enterprise architects would enjoy the meeting. The test is narrow and practical: can the agent make a decision it shouldn't be able to make? If yes, that rule belongs in the model. If no, leave it out and get on with it. An ontology that covers your whole business and never ships is worth considerably less than one that covers a single workflow and goes live on Thursday.

Epistemology: how your agent knows – and whether anyone should believe it

The second question is as old as the first. Plato worried at it in the Theaetetus: what separates knowledge from mere true opinion? The answer the tradition settled on – knowledge is justified true belief – held up for the better part of two thousand years (Plato, Theaetetus). You know something if you believe it, it's true, and you have good reason for believing it.

Then, in 1963, Edmund Gettier wrote three pages that broke it. He showed you can hold a belief that is justified and true and still not know anything, because the justification and the truth only met by accident (Gettier, 1963).

If that sounds abstract, you've lived it. A customer asks your agent whether the size 8 is in stock. The agent checks the inventory system – the system of record, the justified source – and reads 3. There are three. The answer is true. Except the feed froze on Tuesday, and the number has read 3 ever since. Stock moved all week. This morning, by pure coincidence, the shelf holds three again. Justified belief, true answer, no knowledge – the number was right by luck. Gettier would have loved your stockroom. Next Saturday the same process, with the same confidence, gives you the 9:47 pair.

That's the heart of machine epistemology. A large language model produces fluent, confident prose, but fluency was never justification. An agent that lands the right answer for the wrong reason turns Gettier's accident into a daily occurrence. It looks like knowledge. It's a coincidence in a good suit.

The gap runs through everything customer-facing. Ask the agent whether that jacket runs small and it can answer two ways: pull the fit notes and the returns-reason data – justified, checkable – or pattern-match from a thousand other jackets and guess. Ask it your returns policy and it can quote the actual document, or invent "30-day returns" when yours says fourteen. In the chat window the two answers look identical. One of them is knowledge; the other only resembles it – and nobody finds out which until a customer turns up on day twenty-five holding a screenshot.

There's a word for the failure everyone now knows: hallucination. And here's the part owners need to make peace with, because it isn't the part anyone wants to hear. Hallucination is not a bug that some vendor patches away next quarter. Researchers at the National University of Singapore proved it formally – there will always be truths a computable model can't learn, so any model you lean on as a general problem-solver will, sooner or later, produce a confident falsehood (Xu et al., 2024). You aren't waiting for a flawless model. You're designing a system that stays useful while one of its parts runs occasionally, fluently wrong.

The good news: the field that named the problem has been busy on the cure. One lively strand of research, epistemic AI, sets out to build systems that know when they don't know (Manchingal & Cuzzolin, 2025). Newer techniques such as semantic-entropy detection can flag when an answer is probably a confabulation and catch a real share of hallucinations before a customer ever sees them (Farquhar et al., 2024). The shift underneath it all is a change of goal – stop chasing a mythical 100% accuracy and start engineering honest doubt, an agent that says "let me check that with a person" rather than bluffing through.

This is why I talk to clients in hard numbers rather than vibes. An agent that's right 90% of the time and one that's right 99.5% of the time aren't really 9.5 points apart. The first you have to double-check, which saves you nothing; the second you can let act, which changes the economics of the whole operation. And you almost never close that gap by buying a cleverer model. You close it with better epistemology: grounding, retrieval, a layer that verifies, and a human standing at exactly the right checkpoint.

The design brief follows from that. Assume the agent will be wrong sometimes and build for that day – the real question was never "will it hallucinate" but "what happens when it does", so the safety net comes before the feature. Where a mistake costs real money – a stock promise, a refund, a price – put a human at the point of commitment, not at the end of the process. The distinction matters more than it sounds. A human reviewing everything the agent produces is a proofreader, and you've bought an expensive way to do the same work twice. A human signing off only the handful of actions that bind you to a customer is a control, and the agent does everything up to that line unsupervised. The first arrangement saves nothing. The second is where the money is

Beyond that, make the agent show its working – a claim it can't source is a rumour, and you should treat it as one. Reward an honest "I don't know" over a confident guess, since the gap costs almost nothing while the guess can cost a customer. And measure the error rate like any other number on the board: sample the answers, score them against the shelf, watch the trend.

Axiology: what your agent values – and how far it'll go to get it

The third question is the one your dashboard cannot answer, and there's a precise reason why. In 1739 David Hume noticed that writers kept sliding from statements about what is to conclusions about what ought to be, as if the second followed from the first. It doesn't. No pile of facts, however tall, contains an instruction (Hume, 1739). Your analytics stack is a magnificent engine of is – sell-through is, footfall is, conversion is. What the business ought to chase is not in the data. Somebody has to choose it. Hume never ran a shop, but he named your KPI problem three centuries early.

Axiology is the branch that studies exactly that – value, worth, what deserves pursuing. In a person it lives inside morality and motivation. In an agent it gets brutally literal: which objective is it chasing, and what's it prepared to do on the way?

This is the question that decides whether your helpful automation turns into a liability. Stuart Russell named it the value alignment problem: the work of making an agent's goals match what its humans want (Russell, 2019). His warning is sharp. Pair a highly capable machine with people who can't specify their wishes perfectly, and you've all but guaranteed trouble, because the agent does what you said and never what you meant. Russell reaches for King Midas to make it land – Midas got the exact wish he asked for, and it destroyed him (Gabriel, 2020).

Here's the everyday version. Your people carry a messy, unspoken sense of what's worth wanting; a decent shop manager knows "hit the target" was never permission to discount the margin into the floor, though nobody wrote that rule down. An agent carries no such instinct. It values what you measure, not a shade more, and it pursues that measure with a literal-mindedness that would get a person marched out past the stockroom.

Watch it happen. Trading is soft, so you point the agent at one number: get conversion up. It obeys, beautifully – and it discovers, within days, the one lever that always works. The discount. Conversion climbs, the dashboard glows green, and the margin leaks out quietly underneath, because you asked for conversion and said nothing about protecting the price. Every metric on a retail dashboard has an evil twin like this. "Never go out of stock" buys deep and buries your cash in the stockroom. "Clear the ageing lines" bundles dead stock with your bestsellers and trashes full-price sell-through. "Close support tickets faster" refunds everyone – customer delight, at the P&L's expense. None of these agents is malfunctioning. Each is doing axiology, faithfully chasing the value you wrote down instead of the one you held in your head.

It did precisely what you asked. Print that sentence on the box.

The gap between an instruction's letter and its spirit is where most of the real work of deploying an agent safely lives. Researchers have circled two broad ways to close it, and both leak a little. You can try to specify the right objective up front, which gets hard fast because human values run tangled and lean on context. Or you can let the agent learn your values from what people do and say (Hadfield-Menell et al., 2016; Gabriel, 2020). The workhorse of that second approach, reinforcement learning from human feedback, does work – but it tends to average everyone's preferences into a bland middle, which can sand away the specific values that make your brand distinctive (Blair et al., 2024). And a harder question sits above the maths entirely: deciding which values an agent should hold is a matter of judgement, not engineering, especially in a world where people disagree about what counts as good (Gabriel, 2020).

For an owner, the translation is simple, if a little unnerving. You are choosing your agent's values whether you realise it or not, and the moment you accept the vendor's defaults, you've adopted the vendor's values.

So pin the objective down properly, constraints and all – not "get conversion up" but "get conversion up at full price, from customers who'll come back". Those constraints spell out your values. You cross Hume's gap either deliberately or by accident, but you cross it. Name plainly what the agent must never do: invent a discount, promise stock it can't see, quote a delivery date the warehouse hasn't confirmed. Watch any metric that spikes suspiciously, because a sudden jump usually means the agent found the evil twin. And keep your brand's voice in the loop – a premium retailer cares how the agent makes the sale every bit as much as whether it closed, so write that into the objective from the start.

How this scales: from the single store to the chain

The three questions never change. What shifts with size is the stakes, the resources you can throw at each question, and – frankly – where the easy wins are hiding.

The single shop (roughly 1–20 people)

Your ontology is simple and that is your advantage: one till, one stockroom, one range, one person who understands every corner of it. A clean domain model is a single sitting's work, no data team required.

Build the agents that hand the owner their hours back – product questions, order status, restock alerts, review replies, the supplier chase. Keep a human across anything that promises a customer something, because you don't yet have the volume to absorb a public mistake. And encode your values deliberately: at this size your taste is the brand, and an agent that sounds like every other chat bubble on the internet throws away the only advantage you have over the chains.

The multi-store SME (roughly 20–250 people)

This is the sweet spot, and the band we focus on. A few shops, a website, a warehouse; a POS, an ERP and an ecommerce platform that were each told a slightly different story about the business. There's enough moving here that a coherent ontology pays off within a quarter – and the firm is still nimble enough to sidestep the committee paralysis that grinds the big chains to a halt.

The pattern that separates the firms getting value from the ones stuck in pilots has nothing to do with which model they picked. It's whether they rebuilt the workflow around the agent or bolted the agent onto the workflow they already had. The most recent global survey of nearly 2,000 organisations puts the split at roughly 55% of high performers redesigning their processes from the ground up, against barely 20% of everyone else (McKinsey & Company, 2025).

For an SME that gap is the whole game. Don't automate a broken click-and-collect flow; fix its ontology first – what "available" means, who owns the allocation, when the shop floor finds out – and then automate it. You'll know you've done it properly when the process is simpler after the agent arrives than it was before. If it's more complicated, you've added a participant rather than redesigned the work.

The chain (250+ people)

Ontology turns brutal first. Stock truth scatters across a dozen systems that barely talk, merchandising and ecommerce contradict each other on basic definitions, and "what is a customer" honestly has five answers depending on which department you ask. Here a formal knowledge graph stops being a nice-to-have and becomes the foundation, and grounding agents in one governed knowledge layer is what separates the chains that scale from the ones marooned in pilot purgatory (Stardog, 2024).

Epistemology hardens into governance – audit trails, incident logs, risk tiers – and axiology becomes a question of who answers for the outcome. The payoff compounds across every shop and channel, but only for the minority who treat agents as a transformation to lead rather than a feature to switch on.

A framework you can run tomorrow

Strip the Greek away and here's the checklist I run before launching any agent for a client. It takes an hour, and it has rescued more projects than any model upgrade I've ever shipped.

1. Ontology – define the world. List the core objects, the states they can sit in, and the rules that connect them. If you can't draw it on a whiteboard, your agent can't reason over it.
2. Epistemology – plan for being wrong. Decide how the agent earns its facts, how it flags doubt, and where a human signs off. Write the safety net for the day it errs before you ship.
3. Axiology – name the real goal. State the objective, the constraints, and the flat "nevers". Make sure the number you reward is the outcome you want, not a proxy the agent can game.

Run those three, in order, and you've done sharper thinking than most companies spending ten times your budget.

Back to Saturday, 9:47

Same shop, a few months on. The webshop takes an order for the last size 8 – and the agent checks available-to-promise, not "stock", sees that a click-and-collect order already holds that pair, and offers the navy in an 8 with next-day delivery instead. The customer takes it. Nobody gets a grovelling refund email, no shop assistant has to un-box a pair, and the margin stays where you left it. Same Saturday. Three questions answered on purpose instead of by accident.

That, in the end, is the whole argument. The AI market in 2026 is louder than it has ever been, and almost all of that noise concerns models – the one layer you don't control, and the one that gets cheaper and more interchangeable by the month. The parts you do control are the philosophical ones: how clearly you've mapped what exists in your business, how honestly you've faced the limits of what a machine can know, and how deliberately you've decided what it should value. Aristotle, Gettier and Hume settled the questions worth asking; your systems just made them urgent. You rent the model. You build the ontology, the discipline around truth, and the values – and those are what turn an agent into a lasting advantage rather than an expensive experiment.

So here's the concrete next step, and it costs you nothing but an afternoon. Take the workflow you were about to hand to an agent. Write down its objects, its states and its rules on one page, the way I did above. Then show that page to somebody in a different department and see whether they agree it's true. Most of the time they won't, and the argument that follows is the single most valuable thing you'll get out of the whole project.

If you'd rather not run that afternoon alone, that's the piece I do with clients – a fixed-scope session that produces the page, the disagreements it surfaces, and a straight answer on whether an agent is worth building at all. Sometimes it isn't, and I'd rather tell you that before you spend the budget than after.