← Home

AI Agents, Ontologies, and Personal Context

How a small ontology can connect years of emails, messages, and documents through stable identities, relationships, and source links.

August 2026

I recently watched Frank Coyle’s Why Agentic Systems Need Ontologies talk. In the architecture Coyle describes, the model handles language and the surrounding application holds the durable structure of the domain. The model works out what a request means and proposes an action. The ontology defines the entities, relationships, and rules the application uses to evaluate that action.

That division of labor is relevant to a problem I have been exploring with my own data. Years of email, messages, documents, and notes contain a detailed history of people, projects, decisions, and commitments. A model can search those records remarkably well. Yet each new query may still require it to work out that two names refer to the same person, a project changed names, one decision superseded another, or a promised follow-up remains open.

What is missing is continuity between those queries. Creating that continuity requires a structured layer that can preserve stable identities and relationships over time while keeping each accepted fact connected to its source. That leaves a design question: how can the layer be built without making the language model the database, the rule engine, and the final authority over its own output?

What an ontology contributes

The structured layer I have in mind is an ontology: a controlled model of a domain. It names the kinds of things that exist, the relationships they can have, and any rules that follow from those definitions. Tom Gruber’s widely used formulation calls it a formal specification of a shared conceptualization. The practical value lies in making an application’s assumptions explicit and reusable.

A graph supplies a convenient storage shape: nodes connected by named edges. The ontology supplies the agreement about what those nodes and edges mean. A personal context system might begin with a small vocabulary:

Subject Relationship Object
Person participatesIn Project
Message mentions Person
Message records Decision
Commitment ownedBy Person
Commitment about Project
Decision supersedes Decision

Once accepted, these relationships give later queries context that the model otherwise has to reconstruct from surrounding text. An email address, a contact record, and the name “Jen” can all resolve to the same stable identifier. A project can retain its earlier names. A commitment can point to the message that created it and the later message that closed it, and so on.

Creating those stable identifiers requires entity resolution. Extracted mentions such as “Jen”, “Jennifer Wu”, a misspelled surname, and an email address may all refer to the same person. The mentions can be clustered using similarity metrics over spelling and embeddings, together with shared contact details, overlapping projects, and repeated appearances alongside the same people. Strong evidence may support an automatic merge. When only a first name or approximate spelling matches, the cluster can remain a candidate until another source confirms the identity.

A useful ontology can remain small. It needs to cover the facts repeatedly used for retrieval, reasoning, or action, rather than every concept that appears in the archive. People, projects, decisions, commitments, and source records are a useful starting set because they recur across tools and over long periods of time.

The model and the symbolic layer

Once the vocabulary is defined, the language model and ordinary code can take responsibility for different parts of the system. Coyle places this combination under the broad label neuro-symbolic. The neural part handles language and uncertain pattern matching. The symbolic part uses explicit representations that ordinary code can query and check. For personal context, the language model can extract candidate entities and relationships from prose, resolve likely aliases, and turn a natural language question into a structured request.

The symbolic layer keeps stable identifiers, relationship types, provenance, and domain rules. Ordinary application code decides whether a candidate fact may enter the graph and whether a proposed action may reach a tool. The same structured layer then helps retrieve context for the next request.

Two flows showing a language model extracting candidate facts from source records into a validated knowledge graph, then using that graph and its source links to answer a question or propose an action
The model proposes structure during ingestion and uses accepted structure during retrieval. Deterministic checks remain on both paths.

This division leaves language interpretation with the model while the application controls what becomes part of the record. Suppose an email says, “I’ll send the migration checklist on Friday”. The model can flag it as a possible commitment and propose an owner, project, and source message. Before saving it, the application checks that those details are known, the status is one the system recognizes, and there is enough confidence in the extraction. Later queries can retrieve the accepted commitment directly instead of interpreting the email from scratch each time.

A query that depends on current state

Once the archive contains many such records, I might ask, “Show me every open commitment for the billing migration, including promises made before the project was renamed, and link each one to its source”. A conventional retrieval augmented generation (RAG) system may produce a good answer to this question. However, there is no guarantee that similarity search will retrieve every relevant passage, so one or more commitments could be missed. A message that closes a commitment may also use very different language from the message that created it.

One of the accepted commitments might be stored in JavaScript Object Notation (JSON) like this:

{
  "id": "commitment:billing-cutover-checklist",
  "type": "Commitment",
  "owner": "person:jen-wu",
  "about": "project:billing-migration",
  "status": "open",
  "recordedIn": "email:7f2c9a",
  "observedAt": "2026-03-12T16:40:00Z"
}

about connects this commitment to one stable project identifier, even when the source messages use different project names. recordedIn and observedAt preserve where and when the promise appeared. If a later message says the checklist was sent, the model can propose that it closes this same commitment, and the application can attach that update to the identifier in id.

The query can now enumerate every accepted commitment attached to the canonical project and select the ones whose current status is open. Passage retrieval still supplies the original messages so the model can explain the result and cite its sources. The graph preserves the joins and current state using identities and relationships defined by the ontology, so the answer does not depend on similarity search retrieving every creation and closure in one pass.

A more elaborate RAG pipeline could reconstruct those joins during each query. For an occasional question, that may be the simpler design. When identity, aliases, status, and provenance recur across many questions, preserving the accepted relationships avoids resolving them from scratch each time and gives later actions a consistent view of the archive.

The accumulated structure is also something I can explore directly. A visual graph lets me move from a person to the projects we shared, from a project to the decisions that shaped it, and from an old commitment to the messages that eventually closed it. Those connections are difficult to see in a chronological inbox. Seeing them together provides a broader view of how people, work, and decisions fit together over time.

Inference and validation need separate tools

The example so far needs only explicit relationships and application checks. Ontology languages can also derive facts from declared relationships. Coyle shows how Resource Description Framework (RDF) Schema, commonly called RDFS, and the Web Ontology Language (OWL) provide this kind of inference. If teaches has a domain of Teacher and a range of Student, then the statement “Alice teaches Sam” also establishes those types. A transitive relationship can produce a longer chain without storing every derived edge.

OWL assumes that its knowledge may be incomplete. If a commitment has no recorded owner, the reasoner treats the owner as unknown rather than declaring the record invalid. The same behavior appears with functional relationships. If ownedBy is declared functional and a commitment has two recorded owners, the reasoner may conclude that both identifiers refer to the same person. An application that expects missing or conflicting owners to fail therefore needs a separate validation rule.

That validation layer needs different semantics. For requirements that should fail when a fact is absent or malformed, the Shapes Constraint Language (SHACL) or ordinary policy code is a more direct fit. A SHACL shape can require that every commitment have exactly one owner and one source. Application code can enforce rules such as permitted status transitions, access control, and whether an action requires human approval.

Coyle summarizes his layering as “Pydantic at the door, ontology at the ledger”. I recommend making the checks explicit:

  1. Shape: Parse the model’s output into expected fields and types.
  2. Meaning: Resolve identifiers and verify that the proposed relationships belong to the domain model.
  3. Policy: Check permissions, state transitions, provenance, and other application rules.
  4. Execution: Let ordinary code perform the accepted write or tool call.

A proposed record might contain every required field yet refer to an unknown project. After that identifier is resolved, the requested action may still violate access policy. Keeping the checks separate lets the application reject each failure for the right reason and ensures that a well-formed model response does not become automatic permission to act.

Retrieval still begins with the sources

Accepted facts still have to lead back to the records that support them. One query might begin with embedding search to find a passage with similar meaning. The graph can then expand from that passage to known aliases, related people, and connected projects. If the query includes a remembered name, identifier, or phrase, exact text search can narrow the result further. A practical context system can combine all three methods according to what the question provides.

Microsoft’s graph based retrieval augmented generation system, GraphRAG, illustrates part of this approach. It uses a language model to extract entities, relationships, and claims from text, then keeps links from those structures back to their source text units. That graph is already useful for retrieval. Stable domain definitions and constraints turn selected parts of it into a more formal ontology.

Regardless of which retrieval method finds an answer, provenance keeps the structure honest. The graph should help locate evidence and organize it for the model. It should not hide which relationships came from source records, which were inferred by rules, and which remain uncertain model extractions.

Where the extra structure earns its place

Whether this extra structure is worthwhile depends on the questions the archive needs to answer. Finding a remembered sentence or summarizing one email thread fits full text or embedding search. Data that already lives cleanly in a relational system is usually best queried there. An ontology becomes more useful when the same people, projects, events, and commitments appear across heterogeneous sources and their relationships recur in many questions.

The hardest maintenance problem is identity. If two people are merged by mistake, their projects, commitments, and permissions become tangled. If one person is split across several identifiers, later queries see only fragments of the history. Since every relationship hangs from these identifiers, an early resolution error can spread far beyond the source message that caused it.

The graph also has to represent change over time. Projects are renamed, decisions are superseded, and the vocabulary evolves as new sources arrive. Access rules must travel with the extracted facts, since moving a relationship from a private document into a shared graph should not make it more widely visible.

Formal reasoning can amplify a bad assertion just as easily as a good one. Every extracted fact should retain its source and time. Low confidence relationships can remain candidates until corroborated or reviewed. Sensitive edges need at least the protection of the documents from which they came.

A narrow scope makes these risks easier to manage. An ontology built around recurring questions is easier to test than a grand model of an entire life or organization. Its value can be measured through concrete tasks: better retrieval across aliases, accurate timelines, fewer duplicate commitments, and safer tool calls.

A practical starting point

Those limits suggest a narrow starting point. For personal context built from emails, messages, files, and notes, I recommend beginning with people, projects, decisions, commitments, and source records. The initial ontology should define their identifiers and a handful of relationships. Each extracted assertion should carry provenance. The model can propose additions, while deterministic checks decide what becomes accepted context.

That foundation leaves room to add richer inference only when a real query requires it. Suppose a query must show only the documents available to members of a project. The system can then infer access from project membership, using a rule written for that concrete need. Later rules may recognize that a decision supersedes an earlier one or that a commitment has become overdue, but each belongs only when it answers another question the system actually needs to ask.

The practical test is whether the structure keeps paying for itself across questions. A message addressed to “Jen” should still connect to Jennifer Wu, to the project that later changed names, and to the commitment she closed months afterward. If the archive can preserve that chain and show the source of each link, it offers a durable and inspectable account of how its people, projects, and decisions developed over time. That’s the direction I plan to keep exploring with my own data. The results so far have been genuinely encouraging.

Sources