Pillar guide

Ontology for AI agents

A typed, queryable knowledge graph your AI agents plug into instead of building. The full corpus from the Oxagen engineering team, ordered by the decisions a team faces in the order it faces them — plus answers to the top questions developers and CIOs ask.

Most production AI agents in 2026 still ship with a flat vector index over chat history. It demos well and breaks at scale. A typed ontology — entities, relationships, types, workspace-scoped — gives agents structural queries, multi-hop traversal, and deterministic recall that vector retrieval alone cannot deliver.

The 17 posts below are the corpus we have written about that layer. They are grouped by the decisions a team faces in the order it faces them: what it is and why, how to design it, how to integrate it, how to build and evaluate against it, and how to ship and operate it in production. If you are reading this end-to-end, that is roughly the optimal order.

A. Foundations

What it is, why agents need it

Start here if you are new to the idea that an AI agent's memory should be a typed graph, not a flat vector index of chat history.

B. Schema + graph design

The decisions that shape the ontology

Concrete schema patterns, entity-resolution strategies, and the anti-patterns that silently break recall in production.

C. Integration

How agents actually query the graph

The protocol layer — MCP-native access, retrieval strategy, and where existing agent frameworks fit the typed-memory model.

D. Build + evaluate

Zero to measured working system

Walkthroughs for standing up a real agent against a typed graph, plus the eval harness that tells you whether it is actually getting better.

E. Ship + operate

The production surface

Deployment checklists and failure-mode catalogues drawn from what breaks first once the system meets real traffic.

F. Adjacent reading

Tangentially related pieces

Context from the builder side of the house — tools we evaluate, and how we think about the team building the infrastructure.

Frequently asked

The questions developers and CIOs ask

Answers short enough to quote, structured so search engines can lift them directly. If a question is missing and you would ask it in a sales conversation, open an issue on GitHub and we will add it here.

What is an ontology for AI agents?

A typed knowledge graph of entities and relationships that an AI agent reads from and writes to, instead of a flat vector index of chat history. Every node has a type, every edge has a type, every workspace has its own schema, and traversal works in multi-hop structural queries rather than single-shot semantic similarity.

How is an ontology different from vector RAG?

Vector RAG ranks text chunks by semantic similarity and is good for "what does this remind me of". A typed ontology returns entities and relationships via structural queries and is good for "who works with whom at which company". Most production agents need both primitives, not one or the other.

Do I need Neo4j to use this?

Oxagen is Neo4j-backed because multi-hop traversal at workspace scale favours native graph storage, but the contract your agent sees is the Model Context Protocol — not Cypher. The agent never writes a graph query directly; it calls typed tools the MCP server exposes.

How does an agent query the ontology?

Over MCP. Agents running in Cursor, VS Code, Claude Code, Windsurf, or Codex see the workspace graph as a set of typed tools — query nodes by type, traverse relationships to a depth, write new observations back. Each client has a one-line installer.

Why a typed schema? Can the LLM not infer structure on the fly?

Typed schema makes recall deterministic and auditable. A CIO signing off on an agent decision needs to point at which nodes, which edges, and which workspace produced the answer — auto-discovered structure fragments at scale and cannot be reviewed.

What is the relationship between ontology and agent memory?

The ontology is the memory. An agent's four memory types — facts, episodes, skills, preferences — all live as typed nodes and edges in one workspace-scoped graph, which is why a single retrieval surface can answer them coherently.

Is a typed ontology only useful for self-improving agents?

No. A static agent with a well-designed typed graph outperforms a self-improving agent with a bad flat memory. Self-improvement becomes tractable only once memory is typed; until then reflection writes back into a surface that cannot reliably be queried later.

When is a knowledge graph overkill?

When the workload is single-hop semantic lookup with no cross-entity reasoning and the corpus is small enough that precision at the top-k is already acceptable. A vector index is lighter and sufficient in that regime.

Can I run Oxagen on my own infrastructure?

Yes. Hosted, dedicated-database, and bring-your-own-cloud (BYOC) deployment modes are available. The MCP contract is identical across all three, so an agent does not change when the underlying deployment mode does.

How do I evaluate whether the ontology is working?

Track memory recall precision and recall, edge-path explainability, and the agent's task-success delta with and without the graph attached. The eval post in the Build + Evaluate cluster walks through a harness you can lift directly.

Plug a typed graph into your agent instead of building one

Workspace-scoped, MCP-native, Neo4j-backed. Deploy hosted, on a dedicated database, or in your own cloud — the contract does not change.