Why Is Ontology Making a Renaissance? A 1990s Concept Revived by Palantir and AI Engineers

1. A "Future‑Dead" Concept

In 1998 Tim Berners‑Lee presented the Semantic Web vision: every web page annotated with RDF metadata so machines could understand relationships. The community believed that universal RDF tagging would let search engines return semantically correct answers. W3C issued RDFS, OWL, SKOS standards and many internet giants created semantic‑web teams.

However, the dream collapsed quickly. Projects such as CLIP (an RDF crawler) and Sindice were discontinued in 2006, SPARQL usage dwindled after 2010, and Google’s Knowledge Graph in 2015 signaled a shift to a different approach. By 2020, ontology repositories on GitHub showed almost no growth, and mentioning ontology in 2020 often provoked the question “are you still doing a PhD?”.

2. Why Now?

AI engineers are building agents at an unprecedented scale. Internal Slack data shows that the number of Agent‑related demos at the 2025 AI Engineer World’s Fair was three times that of 2024, and more than half of the fastest‑growing GitHub projects are Agent frameworks.

Agents suffer from "semantic inconsistency": they lack a shared business definition, so the same question can yield different answers, and the same business rule behaves differently across data sources. As Frank Coyle explained, LLMs excel at probabilistic reasoning but need logical guardrails—exactly what ontology provides.

3. What Is Ontology?

Oxford Semantic Technologies defines ontology as a description of classes, properties, and relationships in a domain. Coyle simplifies it to "data as graphs". For engineers, ontology is a business‑semantic layer that maps every noun (entity) and verb (relationship) in a domain.

Examples:

Banking: entities Customer and Account , relationship Customer holds Account , action Freeze Account .

E‑commerce: Product → SKU hierarchy, action Apply Discount , state transition Shipped .

Healthcare: Diagnosis precedes Prescription , constraint Allergy , container Insurance Code .

When an Agent asks "Can I prescribe drug A to this patient?", it first checks the ontology graph for the presence of a diagnosis, whether the allergy set contains the drug, and whether the insurance code covers it. This approach is orders of magnitude cheaper than fine‑tuning a model to internalise business rules, and it is explainable and auditable.

4. Neo4j’s Three‑Layer Ontology Architecture

Neo4j CEO Emil Eifrem described an enterprise‑grade ontology as three stacked layers:

Business‑Facing Ontology : natural‑language concepts (Customer, Product, Order) for product managers, sales, legal.

Technical Ontology : metadata for engineers (data source, table schema, field meaning, physical location).

Execution Traces : runtime signals from agents (decision paths, results, error logs) for SRE and MLOps.

These layers form a "smarter shared substrate" that lets agents share a common semantic foundation while preserving separate vocabularies for business and engineering teams. IBM’s 2018 study showed that a two‑layer ontology survived 5 years at a 73 % rate versus 19 % for a single‑layer design.

5. Thin Agents Are Better

Eifrem argues that agents should become "thin": instead of each agent carrying its own hard‑coded connectors to ERP, CRM, and databases (a "thick" agent), they rely on the shared ontology layer. This decouples knowledge assets from the model, enables easy multi‑agent collaboration, and reduces onboarding time from months to days, cutting POC budgets roughly in half.

6. Opinions from Other Experts

OpenLink founder Kingsley Idehen described ontology as the "business constitution" that gives language a computable context, enabling LLMs to reason over precise entity types and relationships. He built an agent‑rdf‑memory system that stores RDF traces after each agent run, allowing the next run to start from remembered semantics.

AI engineer Prasenjit Sarkar proposed that agents could auto‑update the ontology when they encounter edge cases, but warned that unchecked self‑modification could create divergent business definitions, so any auto‑updates must be traceable and reversible.

7. Why Ontology Died in the 1990s

The primary cause was maintenance cost: a full business ontology can contain thousands of classes and tens of thousands of relations, and every business change required a manual update. A DARPA‑funded study (DAML) found that over 80 % of surveyed enterprises stopped maintaining their ontologies after the initial effort.

The practical remedy is a three‑tier governance model: a core layer maintained by domain experts, a standards layer (e.g., Schema.org, FOAF, Dublin Core) reused as‑is, and an extension layer where agents can propose temporary definitions that must be reviewed before becoming permanent.

8. Ontology vs. Related Technologies

RAG vs. Ontology : RAG retrieves documents (string match); ontology provides constraint satisfaction and links concepts.

Agent Frameworks (LangChain, CrewAI) vs. Ontology : frameworks dictate execution; ontology defines what can be executed.

Neurosymbolic AI vs. Ontology : ontology supplies the symbolic side that complements LLMs' neural reasoning.

Vector DB vs. Ontology : vectors match "looks similar"; ontologies enforce "is the same kind" with precise axioms.

In short, ontology is the "business constitution" for AI systems.

9. What This Means for Engineers

Vibe‑coding is over; the next wave values structured business semantics.

Do not reinvent ontologies—reuse existing standards like Schema.org, FOAF, Dublin Core.

Focus on building "AI business" rather than just AI applications; the real value lies in encoding business rules in an ontology that agents can query.

10. A 6‑Week Minimal Viable Path

Weeks 1‑2 : Identify up to 30 core business entities from an existing data dictionary.

Week 3 : Model these entities, attributes, and relationships in Protégé (OWL editor) and express constraints with SHACL.

Week 4 : Auto‑generate the technical ontology from existing APIs using tools such as nl2shacl or OntoGPT.

Week 5 : Choose a non‑critical agent, replace its system prompt with a real‑time ontology query, and compare accuracy before and after.

Week 6 : Deploy the same pattern to a second agent; once proven, the approach can be reused across the organization, reducing marginal cost dramatically.

This effort is a P0.5 project—once the pipeline works, every agent can reuse the ontology, cutting development effort and improving reliability.