Published 29 October 2026. Every tool behaviour and study result below was read from its source on 29 October 2026.
An agent's memory needs the three layers that data architects have relied on for years, a glossary, a taxonomy and an ontology, but it needs them in that order and in much smaller doses than an enterprise data team would build. The glossary (what each type means, and which names point at the same thing) does most of the work: in a September 2026 paper from IRT SystemX, adding a one-line definition to each entity and relation type in the extraction prompt raised Gemma3's strict entity-extraction F1 from 0.42 to 0.57 and its relation-classification F1 from 0.51 to 0.70, with the list of types unchanged. A small taxonomy of memory categories comes next. A full ontology, with typed relationships and rules about which entities may connect, earns its cost once the agent has to answer questions that a pile of retrieved sentences cannot, such as "every open item for this account", "which of these is no longer true" or "what has this customer never asked for".
Questions about sets, absence and change are where the evidence for ontology-structured memory is strongest. In MOOSEDev, an August 2026 paper from Trivyn, a coding agent (GPT-5.x family) with a typed project graph built on two small OWL ontologies, 20 classes and 51 properties in total, scored 1.00 on set-completeness questions where a Mem0 memory scored 0.18 and flat notes scored 0.08, 0.98 on negation questions against 0.06 and 0.00, and 0.98 on supersession questions against 0.27 and 0.12. GPT-5.4-mini graded every answer and each score is the mean of three passes; the paper does not state a total question count. On plain relevance questions the graph and Mem0 came out roughly level, so the typed structure bought nothing measurable there; its gains sit entirely in the questions that need counting and traversal.
Glossary, taxonomy and ontology, defined for agent memory
The three words come from data architecture, where they describe layers of shared meaning on top of a data catalogue (the governed, queryable version of those layers is usually called a semantic layer). Each one maps onto a specific job inside a memory pipeline.
| Layer | What it holds | The standard that models it | What it does for agent memory |
|---|---|---|---|
| Glossary | A definition for each term, one preferred label and its aliases | SKOS prefLabel, altLabel, definition | Tells the extractor what a type means, and tells entity resolution that "Sarah", "Sarah Chen" and "my manager" may be one person |
| Taxonomy | A hierarchy of categories, each a kind of its parent | SKOS broader and narrower | Sorts memories into categories (preference, commitment, contact, event) so retrieval can filter and rank by kind |
| Ontology | Entity types, typed relationships, which types each relationship may connect, identity rules | OWL 2, or typed Pydantic models in most agent tooling | Constrains what extraction may produce and what resolution may merge, and lets retrieval follow relationships |
| Knowledge graph | The actual instances: this user, this company, this deal | Property graph or RDF store | The memory itself, organised by the layers above |
A glossary answers "what does this word mean here". A taxonomy answers "what kind of thing is this". An ontology answers "how may these things relate, and when are two of them the same thing". Neo4j's explainer puts the relationship between the last two well: the knowledge graph is what you build, and taxonomies and ontologies are the blueprints. W3C describes OWL 2 as "an ontology language for the Semantic Web with formally defined meaning", which is more formality than almost any agent memory needs; the memory tools that accept an ontology today mostly express it as a handful of typed classes in code. Designing and maintaining that layer over time is its own discipline, which we call graph engineering.
For the storage side, our posts on what a graph database is and on knowledge graphs against vector search for agent memory cover the storage engine and the retrieval trade-off between graphs and embeddings.
Does agent memory need an ontology at all?
Plenty of agent memory runs without one, and for loose personal facts that is a reasonable default. Mem0's graph memory documentation says the graph forms "without you defining any schema", infers links between entities from co-occurrence, and does not assign typed, labelled relationships, so it will not record an edge such as "manages". For an assistant that needs to remember that a user is vegetarian and lives in Pune, untyped extraction plus good retrieval is enough.
Schema-free extraction fails in a predictable way once the memory grows. When an LLM is free to invent its own types, the same kind of thing comes back under different labels across conversations, relationships flatten into generic "related to" edges, and the graph ends up behaving like an expensive vector index. The MOOSEDev authors reach a version of this from the other side; their lessons section notes that capturing records without discipline reduces the graph to parity with free text. Structure only pays when extraction is held to it.
A practical test is the shape of the questions the agent must answer. If every question is "find the facts most similar to this one", similarity search over well-extracted statements will do. If questions ask for complete sets, for what is missing, for what replaced what, or for paths across people and accounts, the agent needs types it can count and relationships it can follow, and that means an ontology of some size.
How an ontology constrains extraction
An ontology constrains extraction in two places: what the extractor is told it may produce, and what code accepts after the model has answered. Prompting alone gives hints; enforcement in code gives guarantees.
LangChain's LLMGraphTransformer shows the minimal form. allowed_nodes lists the entity types (an empty list allows any type), allowed_relationships takes either relationship names or (source, relationship, target) tuples, and strict_mode defaults to True. The tuple form is the important one, because it encodes a rule the model would otherwise break: a Person may WORKS_AT an Organization, but an Organization may not WORKS_AT a Person.
Graphiti, the open-source engine behind Zep, takes entity and edge types as Pydantic models plus an edge_type_map that lists which edge types are allowed between each pair of entity types, for example ("Person", "Company"): ["Employment"]. Where a pair has no mapping, Graphiti keeps the predicate the model extracted, without a custom schema. An excluded_entity_types list stops a type from being extracted at all, which is a cheap way to keep memory away from things it should never hold.
Cognee works from a formal ontology file instead, parsing anything RDFLib can read (RDF/XML, Turtle, N-Triples, JSON-LD) or a Pydantic DataPoint model, and after matching it walks rdfs:subClassOf hierarchies to attach the parent classes of each matched entity. OntoGr Agent Memory, a small Apache-2.0 library, keeps a per-tenant catalogue of entity types, relation types, attributes and aliases, and puts each relation type's allowed source and target patterns both into the prompt and into code that checks the output.
IRT SystemX's result explains why definitions belong in the extraction prompt and not only in the schema file. Their baseline prompt already listed all 16 classes and 21 relations by name; what moved F1 was adding what each one means and which types each relation connects. The study ran on 80 manually annotated French electricity-grid incident reports with locally hosted 7B to 32B models, and scored output against the human annotations with no LLM judge (the paper's sentence names Gemma3 without a size, and its tables put the 0.42 and 0.57 figures on Gemma3 27B), which makes it a clean measurement of the glossary layer doing its job.
How an ontology constrains entity resolution
Entity resolution decides when two mentions are one entity, and an ontology narrows that decision in three ways: it gives canonical names to match against, it says which types may ever be merged, and it says which properties identify an entity.
Cognee's ontology documentation is precise about the first. Each name is lowercased, its spaces are replaced with _, and it is compared against the ontology's classes and individuals with Python's difflib at a 0.8 similarity cutoff; a match is replaced with the ontology's canonical label, and the node is flagged ontology_valid. Two documents that say "Acme Corp" and "ACME Corporation" can then resolve to the same canonical node without a separate deduplication step.
OntoGr layers its resolution as a ladder: an exact URI match, then a strict key or alias match, then fuzzy matching, and, only for pairs that remain ambiguous, a model verdict. A type-family policy decides which entity types may merge at all, and merges are reversible. Zep's set_ontology endpoint lets each entity type declare identity properties, the fields that decide whether two extracted entities are the same.
Type constraints prevent the most expensive resolution errors in agent memory, which are cross-type merges. Without them, "Jordan" the colleague and "Jordan" the country can collapse into one node when the surrounding text is short and the embeddings sit close together. With a rule that a Person never merges with a Location, the pair never reaches the similarity check.
What happens to a fact that fits no type
Every ontology-aware tool has to choose between keeping what does not fit and dropping it, and the default matters more than the schema.
| Tool | Default | Strict behaviour |
|---|---|---|
| Cognee | annotate: unmatched nodes are kept as extracted, flagged ontology_valid = False | strict: a node is dropped unless its type matches a class or its name matches an individual, and edges touching it go too. Chunk search still returns the original text, and an empty ontology raises an error |
| Zep | Unmatched entities and edges are added unclassified, favouring recall | Strict ontology drops unmatched entities and discards edges outside the configured edge types |
| OntoGr | Configurable | strict drops unknown labels, preferred drops them and queues them for review, open registers them as new types |
LangChain LLMGraphTransformer | strict_mode=True | Output limited to the allowed node and relationship types |
Sources: Cognee docs, Zep docs, OntoGr README, LangChain reference, all read on 29 October 2026.
For agent memory the permissive default is usually right, with one change: unmatched facts should land somewhere a person looks. OntoGr's preferred mode is the pattern worth copying, because a fact that fits no type is either noise or a sign that the ontology is missing something, and only a review step tells you which. Strict mode is the right call for regulated fields, where storing an untyped fact is worse than losing it.
Which layer an agent memory needs at which scale
Modelling effort should track the number of distinct meanings the memory has to keep apart, not the volume of data.
| Situation | What to model | Why |
|---|---|---|
| One assistant, one user at a time, personal facts | Glossary and entity resolution: aliases, a canonical name per person and place | The commonest failure is one person stored as several; types barely matter |
| Many users, one product domain | Add a taxonomy of roughly 5 to 10 memory categories (preference, commitment, contact, event, document) | Retrieval can filter and rank by kind, and retention and deletion can apply per category |
| Agents that must answer set, absence or change questions | A small ontology: typed entities, typed relationships with allowed source and target, identity properties | These questions need counting and traversal, which is where MOOSEDev's typed graph beat flat memory |
| Many tenants, several agents, or regulated data | A shared core ontology with per-tenant extensions, strict mode on sensitive types, a review queue and versioning | Tenants mean different things by the same words, and a schema change has to be auditable |
MOOSEDev is a useful calibration for the third row. A whole coding domain, codebase structure plus architecture knowledge, fitted in 20 classes and 51 properties, and because those ontologies are domain-level rather than project-level, a new codebase needed no new schema, only a new instance graph. Zep's default set is smaller still: nine entity types (User, Assistant, Preference, Location, Event, Object, Topic, Organization, Document) and two edge types, LOCATED_AT and OCCURRED_AT.
The cost of over-modelling
An ontology that is too detailed costs more than one that is too thin, because its failures are quiet.
Type confusion. Every additional type is another decision the extractor can get wrong, and overlapping types make the decision ambiguous by design. Zep's own guidance is to start with a small number of generic types, use few fields and short definitions, add one type at a time while checking the graph after each change, and keep types mutually exclusive so each item has one correct type. It also caps each type at 10 fields.
Silent loss. In strict mode, anything the ontology did not anticipate disappears from the graph. A user mentioning a new kind of commitment, a competitor's product or a child's allergy produces no error; the fact simply is not there when the agent needs it.
Migration. Graphiti applies custom types only to new episodes, and previously ingested data has to be re-ingested into a new graph to receive them, although new optional attributes can be added to existing types without migration. In a memory that has been accumulating for months, every type change is a re-extraction bill, and the old and new parts of the graph disagree until it is paid.
Tokens and latency. Formal structure can make some queries more expensive, not less. MOOSEDev reports that answering one 122-item completeness question through SPARQL cost between 78,000 and 167,000 tokens, against roughly 35,000 for targeted retrieval. The structured answer was complete and the cheap one was not, which is the trade an ontology buys, but it is still a trade.
Upper ontologies. Industry vocabularies such as Schema.org, FIBO for finance and SNOMED CT for healthcare are built to describe entire industries. Loading one whole into an extraction prompt buries the definitions that matter under thousands that do not. Take the subset your agent's questions touch and keep the rest as reference.
How many types to start with, and in what format
Start with the categories your agent's retrieval and deletion rules already need, usually somewhere between Zep's nine defaults and MOOSEDev's 20 classes, and add a type only when a real question fails without it. Write a one-sentence definition for each type and each relationship, because the definition is the part the IRT SystemX study measured.
On format, OWL and RDF give you formal reasoning, standard editors such as Protégé and reuse of public vocabularies, at the price of a second modelling language on the team. Pydantic models keep the schema next to the code that calls the extractor, and Graphiti and Cognee both accept them. For most agent memory the Pydantic route is easier to maintain; reach for OWL when you need to import an existing industry ontology or run a reasoner over the result.
An agent's glossary is per user and per tenant
Enterprise glossaries are written once and governed centrally. An agent's glossary is partly personal: "the Q3 deck", "my manager" and "the usual order" mean something different for every user, and the meaning shifts when the user changes jobs or the deck gets a new version. Two design consequences follow.
Aliases and canonical names have to be learned per user and stored inside that user's scope, never in a shared table where one person's "my manager" could resolve to somebody else's. And the shared ontology should hold types and relationship rules, while the instances and their aliases live in a scoped graph. For many tenants, a shared core with per-tenant extensions keeps one hospital's meaning of "department" from leaking into another's, and an owner on each side (a platform team for the core, the tenant's admin for the extension) keeps changes reviewable.
Time is the other half of meaning. A fact can be true, then superseded, and a good ontology gives supersession a typed relationship instead of overwriting the old fact. Our knowledge graph vs vector search guide covers the two clocks (when a fact was true, and when the memory learned it) that make "as of" questions answerable. Volodymyr Pavlyshyn's essay on ontologies for agent memory makes a related point about the open-world assumption: a fact missing from memory means the agent does not know it, not that it is false, and an agent that treats absence as falsity will contradict users with confidence.
Grounding is not correctness
An ontology makes memory consistent. It does not make it right. A fact extracted into a valid type, through a valid relationship, can still be wrong, and an ontology can reject a correct fact as easily as an incorrect one, which is why Cognee's strict mode prunes only the extracted graph and leaves the original text searchable.
The test that works is the one data teams use for semantic layers: keep a set of questions with known answers, run them after every ontology change, and compare. For agent memory that set should include at least one question per relationship type, some questions whose correct answer is "I do not know", and some about facts that changed. Our guide on how to test agent memory sets out the harness.
Hand-written ontology or a generated one
Writing the ontology by hand gives the most control and costs the most attention, and the cost recurs with every schema change. LLM-generated ontologies are now common: Cognee describes generating an ontology from the documents themselves, and MOOSEDev's ontologies were generated in a workbench and then refined by hand. The second step is the one that matters. A generated schema that nobody reviews inherits every quirk of the documents it was learned from.
Maximem Synap takes the generated route with a review gate. It generates a memory architecture for each agent from a description of what that agent does: what to extract, how aggressively, into which categories, how memory is scoped and stored, and how it is retrieved and ranked. Anthropic's Claude Opus authors that architecture, two further frontier-model judges check it, and it is never applied until a person approves it; it is versioned and can be rolled back. Entity resolution runs on top, so "my manager", "Sarah" and "Sarah Chen" collapse into one person across conversations and channels, and a genuinely ambiguous match goes to a review queue rather than being guessed. Memory is isolated by account, tenant, user and conversation by default, and an organisation with a deeper shape, such as hospital, department, clinician and patient, can model it using its own names. The result is that two teams running the same code get different extraction and different categories for a healthcare agent and a food-delivery agent, without either team writing a schema, and their agents stop asking customers to repeat what they already said.
Frequently asked questions
What is an ontology for agent memory?
An ontology for agent memory is the set of entity types, relationship types and rules (which types each relationship may connect, and which properties identify an entity) that the memory pipeline uses to decide what to extract from conversations and when two mentions are the same thing. It sits above the knowledge graph that holds the actual facts.
What is the difference between a taxonomy and an ontology for AI agents?
A taxonomy is a hierarchy of categories in which each item is a kind of its parent, and an agent uses it to sort and filter memories. An ontology adds typed relationships between entities and rules about them, which lets extraction be constrained and lets retrieval follow paths such as person, to employer, to open deal.
Is a glossary the same as an ontology?
No. A glossary defines terms and records their synonyms; an ontology models how things relate. In agent memory the glossary layer has a measurable effect on its own: in the IRT SystemX study, adding definitions to each type raised strict entity-extraction F1 from 0.42 to 0.57.
Does Mem0 or Zep support a custom ontology?
As of 29 October 2026, Zep accepts custom entity and edge types (Pydantic models in Graphiti, set_ontology in Zep's API) with an optional strict mode, while Mem0's graph memory documentation says it builds its graph without a schema and does not assign typed relationships. Cognee accepts OWL files and Pydantic models.
How many entity types should an agent memory ontology have?
Start with as few as your retrieval and deletion rules need, typically between five and twenty. Zep ships nine default entity types and advises adding custom types one at a time; MOOSEDev modelled an entire coding domain in 20 classes and 51 properties.
What is the risk of a strict ontology?
Facts that fit no type are dropped without an error, so the agent forgets things nobody anticipated. Use strict mode for regulated fields, and a permissive mode with a review queue everywhere else.
Does an ontology improve agent memory accuracy?
On questions about complete sets, negation and superseded facts, the MOOSEDev study measured large gains for an ontology-structured graph over Mem0 and flat notes; on simple relevance questions the two were roughly level. An ontology improves consistency everywhere, and accuracy on the kinds of questions that need structure.
