Key takeaway
- Prescribed ontologies describe how the organisation should work. Learned ontologies capture how it decides. Why AI agents need both, and how to start.
What is the difference between a prescribed and a learned ontology? A prescribed ontology is defined top-down and describes how the organisation should work. A learned ontology emerges bottom-up from captured decisions and shows how it actually works, including the exceptions and overrides. AI agents need both: prescribed structure is the floor, and learned structure adds the context and judgment that real decisions depend on.
The 60-second brief
- The pattern: enterprises spend 18 months and millions on a canonical data model. Agents try to use it and fail, because the organisation does not work the way the model says.
- Two ways to build structure: prescribed (top-down, how things should work) and learned (bottom-up, how they actually work).
- Why prescribed fails agents: static, built for reporting not reasoning, blind to edge cases, and often a political compromise.
- The answer: a hybrid. Prescribed ontologies are the floor; learned ontologies add the context, exceptions and judgment agents need.
- How to start: instrument decisions, extract entities, find patterns, name them, validate them with outcomes, repeat.
The $2M Ontology Nobody Uses
A large enterprise spends 18 months and $2M on a canonical data model. Consultants interview stakeholders, architects draw diagrams, committees debate definitions. The result is a beautiful ontology of everything the organisation should know about itself. Then agents try to use it, and fail. Sales uses "customer" differently from finance. Support has edge cases nobody modelled. The exceptions that drive 80% of real decisions exist nowhere in the schema.
The prescribed ontology describes how the organisation should work. The learned ontology captures how it actually does.
Two Ways to Build Structure
- Prescribed (top-down): interview stakeholders, model entities, define canonical terms, publish, enforce. It assumes you can anticipate everything, standardise definitions and keep structure stable. It works for regulatory reporting, GAAP-defined finance and industry standards such as HL7 and FHIR.
- Learned (bottom-up): capture decisions as they happen, extract entities and relationships from traces, find patterns, surface emergent structure, refine with feedback. It assumes definitions vary by context and that edge cases are where the value lives. It works for operational decisions, exceptions, cross-functional processes and anything involving judgment.
A prescribed ontology tells an agent how things were defined in 2022. A learned ontology tells it how people actually decide, with what evidence, under what constraints, including the exceptions nobody documented. That gap between schema and truth is what I explored in Your AI Agent Didn't Fail. Your Infrastructure Did.
A Real Example: Customer Health
The data team publishes a canonical formula in the semantic layer:
Customer Health Score (prescribed) =
Usage_Score × 0.4
+ NPS × 0.3
+ Support_Ticket_Trend × 0.2
+ Payment_History × 0.1Then reality. Sales: "a customer is at risk when the champion leaves or stops answering emails." Support: "a great score can still churn; we see it in ticket tone." Finance: "two late payments make them a risk regardless of NPS." An account manager: "after a customer reorganisation, all bets are off for six months."
Capture the actual risk decisions and a learned structure appears: champion status, email response rates and meeting cancellations, ticket sentiment, reorganisation windows, heavier payment weighting, and the prescribed score used as a baseline but overridden in 40% of cases. The formula is not wrong. It is incomplete.
Why Do Prescribed Ontologies Fail for Agents?
- Static in a dynamic world. Products launch, markets shift, regulations change, exceptions become rules. By publication, the ontology is outdated.
- Built for reporting, not reasoning. Optimised for consistent dashboards, not for ambiguity, exceptions or judgment.
- Edge cases are excluded, and that is where value lives. For agents, edge cases are most real decisions.
- Political compromise, not ground truth. The definition of "customer" reflects who won the argument. Everyone agrees on it and nobody uses it.
How Structure Emerges
| Step | How structure emerges from use | What happens |
|---|---|---|
| 1 | Capture decisions | What was decided, on what evidence, under which policy |
| 2 | Extract entities | Concepts people actually reference, repeatedly |
| 3 | Identify patterns | "Champion departure" in 40% of discount decisions |
| 4 | Surface and name | Champion status becomes a first-class concept |
| 5 | Validate with outcomes | Do predictions on learned signals hold? |
| 6 | Iterate continuously | New decisions add signal; the business changes |
The schema is not defined upfront. It emerges from the walks.
A single captured decision might read: renewal approved at a 20% discount; health score 72; champion leaving in 30 days; competitor pitching; standard policy overridden for champion departure; customer retained and upsold six months later. Across hundreds of these, "champion status", "competitive threat level" and a taxonomy of override reasons become explicit concepts.
Prescribed Versus Learned, Side by Side
| Dimension | Prescribed | Learned |
|---|---|---|
| Source | Architect interviews | Actual decisions |
| Timing | Defined upfront | Emerges over time |
| Edge cases | Excluded | Core value |
| Updates | Manual, infrequent | Continuous |
| Politics | Embedded | Bypassed |
| Completeness | Aspirational | Actual |
| Agent utility | Baseline | Decision-ready |
The Hybrid Approach
Prescribed ontologies still matter: for regulatory compliance, cross-system identifiers and a baseline vocabulary. The right design layers learned structure on top:
| A hybrid ontology: the prescribed floor, the learned ceiling (top to bottom) | What it holds |
|---|---|
| Agents | Reason with both: standard definitions and real decision context |
| Learned layer | Emergent patterns, override reasons, contextual definitions, change over time |
| Prescribed layer | Canonical entities, standard definitions, compliance (GAAP, HL7, FHIR) |
| Raw data | Systems of record, events, transactions |
Prescribed ontologies are the floor, not the ceiling.
Learned ontologies capture four things prescribed ones cannot:
- Contextual definitions: "customer" means pipeline to sales, any contact to support, revenue recognition to finance and active engagement to success.
- Override patterns: when the health formula does not apply, and with what weight.
- Decision rationale: discounts above 15% are granted for strategic accounts, competitive pressure or multi-year commitments, in measurable proportions.
- Temporal context: "at-risk" was redefined in Q3 after three churns slipped through with good scores.
The semantic-layer side of this argument is in The Semantic Layer Is Necessary. It Is Not Sufficient.; the representation gap is in Beyond Context Graphs.
The Strategic Opportunity
"Data is the new oil" was the last decade's thesis. "Structure that learns" is this decade's. The next platform company will not have the best prescribed schema. It will capture decisions across the enterprise, extract emergent structure, deliver it to agents at decision time and improve it continuously. That is what decision memory and feedback loops make possible.
Building Learned Ontologies in Practice
- Instrument decisions in the systems you already have: approval workflows, ticket resolutions, CRM stage changes.
- Extract entities that appear repeatedly in traces, and the attributes people actually use.
- Identify patterns: which conditions lead to similar outcomes, and which exceptions recur.
- Surface and name emergent concepts and override taxonomies.
- Validate with outcomes: do agents using learned context decide better?
- Iterate continuously. The ontology is never done.
The Diagnostic
| Question | Prescribed | Learned |
|---|---|---|
| When was it last updated? | "2022" | "Yesterday" |
| Does it capture exceptions? | "No, those are edge cases" | "Yes, that's core" |
| Do teams actually use it? | "For reporting" | "For decisions" |
| Does it reflect how work happens? | "How it should happen" | "How it does happen" |
| Can agents use it for judgment calls? | "For basic queries" | "For real decisions" |
If your ontology does not capture how decisions are actually made, including the exceptions, overrides and judgment calls, your agents are working from an incomplete map.
The winning company will not have the best schema. It will have the schema that improves itself.
Your turn: in what share of decisions does your team override the official definition?
Find the Structure Your Decisions Already Contain
ElixirData Context OS captures decision traces and turns the patterns in them into context that governed agents on ElixirClaw can use at decision time. In a Context Workshop, XenonStack works with your data and business leaders to take one decision type, such as renewals or discount approvals, and compare the official definition with how your teams actually decide. Related reading: Entity Resolution: The Foundation Nobody Wants to Build, AI Ontology: Why Context Is Becoming the Competitive Frontier, and 2026 Will Be the Year of Context and Ontology.
Book a Context Workshop | Explore ElixirClaw Agentic OS
Frequently Asked Questions
What is a prescribed ontology?
A top-down model of entities and definitions, built from stakeholder interviews and then published and enforced. It describes how the organisation should work.
What is a learned ontology?
Structure that emerges bottom-up from captured decisions: the entities, patterns, exceptions and override reasons people actually use.
Why do prescribed ontologies fail AI agents?
They are static, built for reporting rather than reasoning, exclude the edge cases that make up most real decisions, and often reflect political compromise rather than ground truth.
Should enterprises drop prescribed ontologies?
No. They remain the floor for regulatory compliance, cross-system identifiers and a baseline vocabulary. The learned layer sits on top of them.
How do you start building a learned ontology?
Instrument decisions in existing systems, extract recurring entities, identify patterns, name the emergent concepts, validate them against outcomes and keep iterating.
This article first appeared in Navdeep Singh Gill's LinkedIn newsletter, AI + Human = Human Squared.
Explore the XenonStack Platform and Agent Network
Platforms: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AutonomousOps · CohortIQ · AI Aviator · SAIF Aviator
AI agents: AgentAnalyst · AgentEvaluation · AgentForce · AgentGRC · AgentHR · AgentInstruct · AgentLabel · AgentPixel · AgentQA · AgentRAI · AgentScrum · AgentSearch · AgentSketch · AgentSRE
XenonStack: xenonstack.com · xenonstack.ai · xenonstack.ae · xenonstack.jobs
Explore the XenonStack platform family: ElixirData · ElixirClaw · ElixirHub · NexaStack · MetaSecure · Neural AI · AgentGRC · AgentSRE · AgentAnalyst · AgentInstruct · AgentRAI · AgentScrum · AgentSearch · AgentForce · AI Aviator · SAIF Aviator · CohortIQ · XenonStack AI · XenonStack UAE
