Obsidian as a mini-Ontology: prototyping a Context Graph for AI agents

AI models are getting better at reasoning, writing code and using tools. But in real systems a less glamorous problem often matters even more:

the agent does not know where the right information is.

It may have access to repositories, tickets, incidents, deployments, documentation, datasets and internal conversations. If all of those arrive as isolated sources, the agent behaves like a person without a map: search, open, read, backtrack and search again.

Uber recently published numbers that make the cost of this problem visible. Its AI Context Graph contains roughly 24 million nodes and 80 million relationships, spanning 86 node types and 117 edge types, with data from more than 30 internal systems. In one experiment, the same model answered correctly in 38 seconds with graph grounding; without it, the agent spent more than 20 minutes searching and still reached the wrong conclusion.

That suggests a powerful idea for much smaller teams:

we may not need to begin with an enterprise knowledge graph. We can begin by explicitly representing the entities and relationships an agent needs to understand.

One unexpectedly useful tool for experimenting with that pattern is Obsidian.

Three ideas that are converging

Uber, Palantir and Obsidian come from different worlds, but together they reveal three levels of the same problem.

1. Obsidian: linked knowledge that humans can read

Obsidian stores notes as Markdown files inside a vault. Internal links connect notes, while Graph View visualizes those connections as nodes and lines.

That already gives us a minimal structure:

note          -> node
[[link]]      -> relationship
property      -> attribute
vault         -> knowledge universe

It is not an enterprise ontology. But it is a very cheap way to begin making relationships explicit.

2. Uber: structured context so agents do not search blindly

Uber’s AI Context Graph connects services, engineering teams, pull requests, incidents, architecture documents, deployments, datasets and historical table usage.

The key difference is not simply that Uber has “a lot of data.” The agent can navigate a representation where relationships already exist:

service
  ├── owned_by -> team
  ├── deployed_to -> production
  ├── affected_by -> incident
  ├── modified_by -> pull request
  └── consumes -> dataset

Instead of asking the model to rediscover those relationships on every run, the system provides them as infrastructure.

That is Context Engineering beyond the prompt.

3. Palantir: when the graph becomes operational

Palantir’s Ontology goes much further. It models objects, properties and links, but also logic, actions and security.

Conceptually:

data
  ↓
objects + properties + relationships
  ↓
logic
  ↓
actions
  ↓
operational systems

That distinction matters.

A knowledge graph can say:

PR #742 -> modifies -> payment service

An operational ontology can additionally represent:

payment service
  -> can be deployed through
  -> Deploy action
  -> under defined policies

So saying Obsidian “is like Palantir Ontology” would be an overstatement.

Saying Obsidian can serve as a prototype of the mental model is much more useful.

Turning a vault into a small Context Graph

Imagine a software project with repositories, issues, PRs, technical decisions and incidents.

A starting structure could look like this:

Knowledge/
├── systems/
├── components/
├── repositories/
├── teams/
├── decisions/
├── incidents/
├── issues/
├── pull-requests/
└── deployments/

Each file represents an entity.

For example:

---
type: component
status: production
owner: Platform
depends_on:
  - "[[Publisher]]"
  - "[[YouTube API]]"
runs_on:
  - "[[Oracle Runner]]"
related_issues:
  - "[[Issue 290]]"
---

And in Markdown:

# Thumbnail Pipeline

Generates the episode thumbnail.

## Relationships

- depends on [[Storyboard]]
- runs on [[Oracle Runner]]
- notifies through [[Telegram Bot]]
- modified by [[PR 293]]

For a human, this is documentation.

For an agent, it begins to become a navigable model of the system.

The important leap: do not maintain the notes manually

If the experiment depends on someone manually maintaining hundreds of notes, it will die quickly.

The interesting part is automating ingestion.

GitHub
Docs
Issues
PRs
Incidents
Deployments
        │
        ▼
   extractor
        │
        ▼
normalization
        │
        ▼
Obsidian Vault
        │
        ├── Markdown
        ├── properties
        └── links

An agent such as Codex or Cursor could traverse existing documents and build the first version of the vault. Another process could then keep it synchronized with source systems.

But there is one crucial rule:

relationships need semantics.

Producing thousands of backlinks is not enough.

[[Service A]] -> [[Team B]]

says that a connection exists.

owner: [[Team B]]

says what that connection means.

That small change moves the vault closer to a real semantic model.

Obsidian as the interface, not necessarily the backend

This is where the most interesting architecture may emerge.

Obsidian does not have to be the final retrieval system.

It can become the human-readable layer:

                 ┌───────────────┐
                 │    Obsidian   │
                 │ human-readable│
                 └───────┬───────┘
                         │
                canonical knowledge
                         │
        ┌────────────────┴────────────────┐
        │                                 │
        ▼                                 ▼
     SQLite                         Graph / JSON
        │                                 │
        └──────────────┬──────────────────┘
                       ▼
                Retrieval service
                       │
                       ▼
                    Agents

The vault makes knowledge easy to inspect, correct and discuss.

A structured representation underneath enables:

fast queries;
typed relationships;
filters;
versioning;
scoring;
APIs;
MCP integration;
programmatic retrieval.

In that architecture, Obsidian does not compete with Neo4j, PostgreSQL or a vector database. It plays another role: a human-editable view of the system’s structured memory.

What about vector search?

A Context Graph and a vector database solve different problems.

Vector search is good at questions such as:

which documents discuss publishing failures?

A graph is better at questions such as:

which component publishes, where does it run, which PR changed it and which incidents affected that path?

In practice, both can coexist:

agent question
      │
      ├── semantic search -> relevant documents
      │
      └── graph traversal -> entities and relationships
                         │
                         ▼
                    final context
                         │
                         ▼
                       LLM

The goal is not to replace RAG.

It is to avoid making everything depend on semantic similarity.

Example: investigating a failure

Suppose an agent receives:

“Why didn’t the automatic publisher publish the episode?”

Without structured context it might search for “publish,” then scheduler, then CI, then Telegram, then YouTube.

With a small graph it could immediately retrieve:

Auto Publisher
  ├── scheduled_by -> Systemd Timer
  ├── runs_on -> Oracle Runner
  ├── invokes -> YouTube Publisher
  ├── notifies -> Telegram Bot
  ├── configured_by -> Environment
  ├── modified_by -> PR 293
  └── related_incidents -> Incident 2026-09-24

The model still has to reason.

But it no longer has to rediscover the basic topology of the system from scratch.

That is exactly the kind of advantage illustrated by Uber’s published experiment.

Where Obsidian falls short

The prototype has clear limits.

Obsidian does not provide by itself:

strong object-type schemas;
relationship constraints;
transactional control;
granular authorization per object;
typed operational actions;
enterprise real-time synchronization;
graph traversals optimized for massive scale;
governance equivalent to a platform such as Palantir.

Even Graph View primarily represents links between notes; it does not automatically turn every relationship into a formally typed semantic edge.

A reasonable path therefore looks like this:

phase 1
Markdown + links + properties

phase 2
explicit schema

phase 3
automatic extractor

phase 4
structured index

phase 5
API / MCP for agents

phase 6
actions + permissions + feedback

Obsidian can be the laboratory.

It does not need to be the final destination.

Then another Uber idea appears: skills that evolve

Uber also describes a particularly interesting direction: recording problems encountered during skill executions and using those traces to generate improvements.

Combine both ideas and a powerful loop appears:

agent execution
      │
      ▼
trace / failure / success
      │
      ▼
Context Graph
      │
      ├── which context was useful
      ├── which relationship was missing
      ├── which tool failed
      └── which skill solved the problem
      │
      ▼
improvement proposal
      │
      ▼
updated skill

Now the system’s memory does more than help the agent solve tasks.

It can help improve how the agent works.

The experiment worth running

For a small team, I would not start by installing a complex platform.

I would start much more simply:

take the documentation that already exists;
convert it into structured Markdown;
define 10 or 15 important entity types;
define a small vocabulary of relationships;
generate the vault automatically;
connect an agent to that knowledge;
measure whether searches, token use, latency and errors decrease.

If the result works, then replace pieces as needed.

Obsidian
   ↓
prototype
   ↓
structured store
   ↓
production Context Graph

The specific technology can change.

The principle remains.

An agent with more tokens does not necessarily have better context.

As agents execute longer and more autonomous tasks, the ability to explicitly represent what exists, how it is related and where to find it may become just as important as the model reasoning over that information.