What is an AI ontology - and why it's the only moat you can own

On July 1, 2026, Palantir CEO Alex Karp sat down with CNBC to talk about his company's new partnership with Nvidia - and instead delivered the sound bite that set the enterprise-AI conversation on fire.²

"We have this thing called ontology that now everyone's copying."

- Alex Karp, CEO, Palantir · CNBC, July 1, 2026

Karp's argument, compressed: an ontology is what makes a large language model safe, useful and precise inside a real organization, because it keeps the model from absorbing your data and, in effect, replicating your business. He described enterprise customers as furious with the frontier labs: paying for tokens that produce no value while the labs soak up the operating knowledge (the alpha) of their businesses.²³

The clip went viral because it named something a lot of people had been circling from different directions. Look at what happened in the months around it:

Block. In March, Jack Dorsey and Sequoia's Roelof Botha published "From Hierarchy to Intelligence," an essay arguing that a company needs a world model of its own operations: a live representation of how the company understands itself, its performance and its priorities. Block had just cut roughly 4,000 of its 10,000-plus jobs; the essay's claim is that a rich-enough world model, paired with agents, can carry much of the context that middle management used to hold. And they were blunt that representation alone isn't the point, since a world model that can't act on the world, they wrote, amounts to a database.⁴⁵

Karpathy. In April, Andrej Karpathy published his "llm-wiki" pattern: instead of an assistant re-retrieving from raw documents on every question, the LLM incrementally writes and maintains a persistent, interlinked wiki of what it has learned - knowledge that accumulates instead of being rediscovered from scratch each time. The gist crossed 5,000 GitHub stars within days.⁶

The platforms. Microsoft shipped its "IQ" family, in which Fabric IQ's ontology explicitly "defines core business entities, relationships, properties, rules, and actions" as an enterprise intelligence layer.⁷ Databricks grounded its Genie assistant in governed company data and pushed it toward an agentic coworker at this year's Data + AI Summit.⁸ Salesforce, Snowflake, dbt and Databricks even co-launched a standard, Open Semantic Interchange, so semantic layers can travel between platforms.⁹ ServiceNow built a knowledge-graph layer into its Workflow Data Fabric.¹⁰

And in the builder community, the video essay that prompted this article, by Devin Kearns of CustomAI Studio, pulled the whole picture together from an implementer's seat: whatever you call it, this is one category, and it behaves less like a trend than like business infrastructure.¹

When a defense-software company, a fintech, three hyperscale data platforms and the most-followed AI educator on the internet all land on the same abstraction within a year, the convergence is more than a marketing coincidence. A new layer of the stack is forming.

The word comes from information science. Tom Gruber's 1993 definition of an ontology as an explicit specification of a conceptualization still holds: you write down, formally, what exists in your domain and how those things relate, so that software can reason over it.¹¹ What has changed is the audience. For thirty years ontologies were built for databases and search engines; now they are built for LLMs, because a model with your ontology stops guessing what "the Meridian account" means and starts knowing.

Palantir, the company that dragged the term into boardrooms, describes its Ontology as an operational layer that sits on top of an organization's data and connects digital assets to their real-world counterparts: a digital twin holding both the semantic elements (objects, properties, links) and the kinetic ones (actions, functions).¹² Their shorthand is the best one available: the nouns and verbs of your business.

The structure matters because of what happens without it. Try the alternative, as Kearns does in the video: keep one long running document per client. It works - for one client, for a while. But the context is trapped in that file. The same people appear across five accounts; the same decision pattern repeats across twenty projects; none of that maps across, because prose doesn't have edges. An ontology is what lets context reuse: define the entity types once, define what the relationships mean, and every new event lands in a web that already knows how to hold it.¹

Ontology vs. knowledge graph vs. taxonomy - the ladder

The three terms get blended, but they're rungs on one ladder. A taxonomy is a hierarchy of categories and subcategories, an "is-a" tree. An ontology adds typed relationships, properties and rules: not just "Task sits under Project" but "Task blocks Task," "Person approves Decision," a schema rich enough for inference. A knowledge graph is the ontology populated: your actual customers, actual deals and actual meetings stored as instances, connected by those defined relationships. The ontology is the blueprint; the knowledge graph is the building.¹³

What Palantir's version proved

It's worth pausing on why Karp gets to gloat. Palantir spent nearly two decades doing the unglamorous work, with forward-deployed engineers hand-building ontologies of factories, banks and battlefields, and when LLMs arrived, that layer turned out to be exactly what made them deployable: the model plugs into a structured world it can query and act on, rather than free-associating over raw tables. The market has rendered its verdict: Palantir's Q2 2026 revenue hit $1.9B, up 93% year over year, with US commercial growing 149%, and the company's shareholder letter now openly frames customers as refusing to become dependents of the language labs.¹⁴ You don't need Palantir's software to learn Palantir's lesson: the ontology is what turns a general-purpose model into your system.

Each camp names the concept after the part it cares about. Line the definitions up and the differences are emphasis, not substance:¹

The synthesis, in one sentence: a company world model is centralized, contextualized company data that humans and AI systems can query, reason over, and act from. Keep that definition and you can translate any vendor's pitch back into plain language.

The uncomfortable observation underneath all of this is that the part of the AI stack everyone argues about matters least strategically.

Claude, ChatGPT and Gemini are, structurally, harnesses around models, and both the harnesses and the models are converging. Open-weight models keep closing the capability gap; anyone with a good scaffold can assemble a competitive assistant from parts. Kearns' framing in the video is blunt: the top layer is interchangeable. You can swap models as better ones ship, swap harnesses as better tools emerge, and if your business context lives outside that layer, swapping costs you nothing.¹

What you cannot swap in, from any vendor at any price, is how your business actually runs. Which client is sensitive and why, how decisions really get made between three particular people, what the last four quarters of experiments taught the sales team: all of it took years to accumulate, and an LLM is close to useless without it.

Notice what the economics do over time. Every model upgrade makes the top layer cheaper and more interchangeable - and makes your context layer more valuable, because a stronger reasoner over the same rich context produces strictly better work. The commodity layer depreciates while the context layer appreciates, and that asymmetry, more than any single product, is why the smart money moved to the data layer this year. Build only on the AI layer and you're building someone else's moat - with your effort.

There's a sharper edge to Karp's rant than vendor rivalry. His claim, echoed by the enterprises he sells to, is that the default enterprise AI posture - buy licenses for a frontier chat product, pipe everything through it, train the staff - amounts to a slow transfer of the company's operating knowledge to the model provider.²³ Palantir's shareholder letter this quarter went as far as describing customers in revolt against becoming vassal states of the language labs.¹⁴

Strip the theatrics and a real architectural question remains. The most valuable context in your company is exactly the stuff no frontier model can train on today: the unwritten rules, the decision dynamics between specific people, the client sensitivities, the shorthand - what Kearns calls tribal knowledge, down to the unspoken Slack norm that a message isn't acknowledged until it gets its thumbs-up.¹ Feed all of that, unstructured and continuous, through a single vendor's product, and you should at least ask: who is accumulating the map of how my business works - me, or my supplier?

None of this argues for avoiding Claude or ChatGPT. Enterprise agreements, private deployments and zero-retention APIs exist precisely because buyers pushed. The argument is architectural: own the context, rent the intelligence. If your ontology lives in systems you control, and frontier models are called at inference time with exactly the context slice a task needs, then you keep portability, bargaining power, and the option to swap providers, or drop to open-weight models, without losing a decade of accumulated context. Buying everyone AI seats and running a training day is not a transformation strategy; it's a subscription with homework.¹ (It's also why our builds run in the client's own environment, on the client's own accounts, because ownership of the context layer is the whole game.)

If the ontology idea were only vendor poetry you could safely ignore it, but the failure data argues otherwise.

Read those together and a pattern appears. MIT's much-quoted "GenAI Divide" study found that despite $30–40B of enterprise investment, 95% of organizations were seeing no measurable return - and its diagnosis was not that models are weak, but that deployed systems don't retain feedback, don't adapt to context, and don't improve over time. The gap it describes is one of learning rather than intelligence.¹⁵ Gartner's numbers point the same direction from the data side: through 2026, organizations will abandon most AI projects that aren't supported by AI-ready data, and 63% of organizations admit they don't have the data-management practices AI needs.¹⁶¹⁷ Salesforce's 2026 research adds that 84% of data leaders say their data strategy needs a complete overhaul for AI to succeed - while roughly 90% of enterprise data sits unstructured and untouched.¹⁸¹⁹

Practitioners recognize the failure mode from the inside. Kearns describes it as quiet rot: an agentic workflow ships, works beautifully for six months - then the business micro-shifts. A process changes slightly, a responsibility moves, a goal is rephrased. The hard-coded retrieval logic and prompts that encoded last year's context are now subtly wrong, nobody can say exactly which parts, and the workflow gets abandoned rather than repaired.¹ Connectors don't save you - plugging a chat assistant into ten tools gives it access, not understanding. Which version of the document is true? Which context has degraded? People answer those questions by hand (everyone who's pasted a transcript into a chat window despite having the integration connected knows this), and hand-curation doesn't scale.

Context engineering: the skill behind the buzzword

The craft that emerged around this problem got its name in mid-2025, when Shopify CEO Tobi Lütke proposed retiring "prompt engineering" in favor of context engineering - the art of providing everything a model needs for the task to be plausibly solvable - and Karpathy seconded it, describing the delicate science of filling the context window with just the right information at each step.²⁰²¹ Anthropic later formalized the discipline: curating and maintaining the optimal set of tokens across every inference, treating system prompts, tools, retrieved documents, history and memory as one budget to manage.²²

The connection most coverage misses is simple: context engineering is the practice; the ontology is the asset it draws on. The best context engineer in the world can't curate context that was never captured. And the payoff of structuring it is measurable - in the data.world benchmark, GPT-4 answering business questions over an insurance schema jumped from 16.7% accuracy on raw SQL to 54.2% over a knowledge-graph representation of the same data; on schema-heavy questions like metrics and KPIs, raw-SQL accuracy was literally zero.²³ Microsoft's GraphRAG line of research points the same way: graph-structured retrieval answers the "connect the dots across everything" questions that vector search alone cannot.²⁴

So what does a company brain look like once it is real, rather than a demo or a wiki nobody updates? The version Kearns lays out, and the one we build toward with clients, is event-driven.¹

The unit of truth is the event: an email arrives, a call ends, a deal changes stage, an invoice is paid. Capture it at the source, the moment it happens. Contextualize it on arrival - what is this, who's involved, which account and project does it belong to, does it spawn a task? Then store it in a structured knowledge layer: a knowledge graph, a relational store, a vector index, or (most often) a hybrid. From there it's retrievable - by people, and by agents who receive it pre-contextualized instead of being told to go search twelve tools and figure it out.

Two design choices separate this from a chatbot with plugins.

It behaves as a loop rather than a pipeline. Actions the system takes become new events, and decisions humans make on escalated cases get written back. This is what fixes the six-month rot: the context layer maintains itself, which Kearns calls self-annealing, so you can swap models and even remove scaffolding as models improve, without the harness logic going stale.¹ The infrastructure world has arrived at the same conclusion from its own direction: Confluent's architects argue agents are fundamentally an event-driven-integration problem, in which agents react to changes in business state instead of sitting behind a chat box waiting to be asked.²⁵ And the surge of the agent-memory category (Mem0's $24M raise and its selection as the memory provider for AWS's agent SDK, Zep's temporal knowledge graph, Letta out of Berkeley's MemGPT work) shows the market pricing in that persistent, structured context is not optional.²⁶²⁷

It also knows when not to act. A real world model works as an abstention layer as much as a retrieval engine. If confidence is low or the action is risky under your policies, the correct output is no action - route to a human, record what the human does, learn.¹ This runs against the grain of the models themselves: OpenAI's own research on hallucination shows standard training rewards a confident guess over an honest "I don't know," and Meta's AbstentionBench found that reasoning-tuned frontier models are often worse at recognizing unanswerable questions.²⁸²⁹ Your architecture has to supply the humility your model was trained out of. Design the "don't" branch first, because it is the one that keeps agents out of production incidents. (This is also why our rollouts run shadow mode first, then human-in-the-loop approval, then supervised autonomy.)

The end state Kearns describes is worth keeping as a north star: a business where routine execution - the inbox, the follow-ups, the status updates - is handled end-to-end by agents working from the world model, and humans spend their time in conversations, judgment calls and decisions. Not because a demo said so, but because the context layer finally made reliable delegation possible.¹

You don't need Palantir's budget or Block's headcount so much as a sensible order of work. This is the order of work we follow as an AI agency in Lithuania building for mid-sized companies, and it front-loads the part that stays useful longest:

1. Inventory where data is born

   List your systems of record - CRM, email, Slack, docs, call recordings, tickets, spreadsheets. For each: what events does it emit, and what critical context lives only in people's heads? That second list is your tribal-knowledge backlog.

2. Draft the ontology on one page

   Eight to twelve entity types (customer, deal, project, task, person, meeting, decision, document…), the relationships between them, and the events that change them. Nouns and verbs first; tooling later. If it doesn't fit on a page, it isn't a v1.

3. Pick storage that matches your questions

   Relational for counts and reporting, vector for "find things like this," graph for "how are these connected." Hybrid is normal and unromantic. The schema you drafted matters more than the engine you pick - you can migrate engines, not lost context.

4. Capture events at the source

   Webhooks and APIs from your tools into one ingestion path. Contextualize on arrival: what is it, who's involved, which account, does it create a task. An event classified the moment it happens is cheap; a data lake classified retroactively is a project.

5. Give agents one retrieval interface

   Agents query the world model - not twelve tools with twelve permission models. Pre-contextualized retrieval is what turns "go search everything and guess" into "here is the account history, the open commitments, and the last decision; draft accordingly."

6. Write abstention policies before granting autonomy

   Define confidence thresholds and risk classes per action before an agent can act. Low confidence or high risk routes to a human; the human's call is recorded and becomes training context. Autonomy is then expanded on evidence, one action class at a time.

Start with one workflow - inbound email triage, support replies with account history, meeting-to-CRM capture - prove the loop end to end, then widen. The first workflow is the hardest and the most instructive; the tenth inherits the ontology the first nine built. The compounding is the moat itself: a year from now, the companies pulling away won't have better models than you. They'll have better context. Models can be rented from anyone; the map of your business cannot, and whoever owns it owns the business it describes.

Aurelijus Jakas

Founder · Vertara

Designs and builds custom AI systems for mid-sized manufacturing, logistics, export and professional-services companies in Lithuania and across Europe. Researched with AI tools; written and checked by the author. All articles