Omnigraph: graph db designed for agents

Graph as code paradigm: full breakdown

Hey 👋 Andrew here

This V-E issue is about Omnigraph: a new database paradigm built for agents.

We’ll go through the whole story: the premise that we reason from, the design decisions and reasoning behind them, and the impact of this new concept.

Let’s look into legacy databases first.
Most of them built around the trinity:
USER | WORKFLOW | OPERATOR

USER → human who consumes & inputs data
WORKFLOW → software that talks to the database: app, service, ETL pipeline
OPERATOR → human database manager: schema, policies, backups

In the old model, those roles were mostly separated.

Users worked through a fixed UI.
Workflows executed deterministic logic.
Operators made changes in database carefully and slowly.

Agents collapse the trinity

They are database users together with humans
They have the throughput of data pipeline
They can do complex schema migration & deployments

The loops get faster:
Agent can run continuously, touch thousands of records.
It discovers the missing type and proposes schema change.
It gets a context path and saves it as a query.
If an agent is blocked by policy, it can identify the missing permission and ask for it.

So the big question is:
what does a database look like when the same agent is simultaneously user, workflow, and operator?

I think we solve it with Omnigraph - agent-first graph database.

Omnigraph

Omnigraph implements new paradigm: GRAPH-AS-CODE

We took the idea from Terraform:
graph is treated as a deployment with a declarative definition:

• Schemas

• Named queries

• Policies

• Pipelines

• Dashboards

• Embeddings

• Deployment configs

Together they define the whole system. One definition, all code/config that is native to LLMs

The whole database definition fits in context - so the agent sees the entire system at once.
It can reason about the setup before it acts.
And it can change it the way it writes any other code: as a diff you review and apply.

That is unusual for a database.

Most databases cut that into pieces:
migrations through CLI, policies in control panel, queries as strings in application code.

Omnigraph makes the definition itself a primary operating surface.

This surface consists of components:
schema as code
context as code
policy as code
dashboards (UI) as code.

Schema as code

To operate data efficiently agents need a map of the domain.

In Omnigraph, that map is declarative. A .pg schema declares the model:

• Node & edge types

• Properties & constraints

• Cardinality

• Interfaces & annotations

• Embeddings

node Person {
    name: String @key
    role: String @index
    bio: String?
    embedding: Vector(3072) @embed("bio")
}

node Document {
    title: String @key
}

edge Wrote: Person -> Document @card(0..)

Because the schema is declarative, the agent can inspect it before it acts.
It is type safe and enforced - otherwise agent might get too creative and start inventing things on the go.

The schema tells agents what kinds of things exist, how they relate, which values are constrained, and which paths through the graph mean something.

Agents do not only retrieve facts → They reason over a model of the domain.
The better the ontology, the better the agent can retrieve, traverse, validate a write, or notice missing things.

Schema is operating context, the ontology that reasoning runs on.

And because the schema is just code, evolving it is a diff.

An agent running across the data notices a gap the model doesn’t capture yet — every Document is clearly about something, but there’s no type for it. It doesn’t hack around the gap. It proposes a change to the schema itself:

You read the diff and hit apply. The migration runs, the new type goes live, and every write after it is checked against the new shape.

This is the operator from the opening — the role that used to move carefully and slowly. Now it’s a pull request.

Context as code

Agents need stable context tools to assemble the context.

Agent walks the graph: it reasons through traversals.
Traversals create reasoning pathways that make the agent smarter.

If an agent repeatedly needs a specific context - it can define the query and save it.
All queries type-checked against the schema, versioned, exposed as stable tools.

query find_experts($topic: String) {
    match { $p: Person }
    return { $p.name, $p.role }
    order { rrf(nearest($p.embedding, $topic),
                bm25($p.bio, $topic)) }
    limit 5
}

Retrieval is hybrid in one runtime:
Traversals, vector, full-text, hybrid, ranking & filtering

One query fuses vector (nearest) and full-text (bm25), ranked together with rrf.

The agent starts from what it knows and moves through the graph:
follow an edge
search nearby text
rank semantic matches
inspect related nodes
return the result in a shape it can use (and reuse)

Branches

But reading is only half the job. Agents write too - constantly, and in bulk.
Long-running background agents enrich, repair, and reconcile data as they run.

So the writing has to be safe.
In Omnigraph every agent gets its own branch.
It works in isolation. Useful work merges, slop is discarded.
Autonomous writes become proposals you review, not raw changes to live data.

The real unlock: branches let agents make mistakes.

An agent enriching thousands of nodes will get some of them wrong - a bad merge, a mislabeled edge, misplaced enum and so on.
On a branch, that’s fine. The mess stays on the branch; the main graph never sees it.

Every change to the data is a proposal you can inspect and roll back.
And once mistakes are cheap, the calculus flips: you can point agents at real data, at scale, because the downside is a thrown-away branch, not a corrupted graph.

Also old OLTP/OLAP split starts to blur.
Agents do not think in separate transactional and analytical systems.
In one loop they write facts, assemble context, traverse relationships, search & rank matches, inspect history, and write the result back.

Which raises the next question: who is in control of what is allowed?

Policies as code

An agent-first database needs clearly defined boundaries, visible and versioned.

In Omnigraph governance is fully declarative too:

• Who can do what

• On which graph

• On which branch

• Under which identity

• With which audit trail

version: 1
groups:
  agents: ["claude-code", "hermes"]
protected_branches: [main]
rules:
  - id: agent-writes
    allow:
      actors: { group: agents }
      actions: [change]
      branch_scope: unprotected

You clearly define the rules so agents won’t be confused and trying to break through an invisible wall.

If an operation is blocked, the agent can inspect the policy path.
It can see the missing permission, propose a change in config and leave the decision to hit the apply button to you.
Policy changes become a part of the workflow, not a hidden gate.

UI as code

If the shape of the graph changes this frequently - what to do with the UI?
You do not want to rebuild it every time the schema changes or you get a new lens on your data.

Remember what Steve Jobs said about phones - the problem was fixed plastic keys that never change.
The iPhone made the whole surface software, so the UI could become whatever the app needed.

Slide from original iPhone presentation. 2007

Now the problem moves to the next level: fixed software is too rigid too.
A fixed UI can’t keep up with a graph that changes this often.

So in Omnigraph the human UI is fully generative.
If schemas and queries define what can be seen and changed, the UI is derived from them automatically.

Notebook for my personal context graph

Dashboards (as notebooks) are declared in YAML and generated from the graph definition.

version: 1
title: Open decisions
cells:
  - id: decisions
    lens: Table
    query:
      kind: nodes
      where: { type: Decision, status: open }
      project: [id, title, urgency]
      order_by: { field: urgency, direction: asc }
    props:
      columns:
        - { key: title,   label: Decision }
        - { key: urgency, label: Urgency }

You get familiar primitives to view, update, and review data -- without rebuilding the UI every time the graph shape changes.

Deployment

GRAPH-AS-CODE is a deployment paradigm

Flexible and modular.
You can run Omnigraph as a traditional cloud cluster.
Or fully air-gapped on-prem
Or as a hybrid deployment with one integrated control plane.

Object storage scales independently of compute.

The same graph can be served through different surfaces, moved between clusters and recreated from
definition with a single apply command.

version: 1
storage: s3://your-bucket/clusters/knowledge
graphs:
  knowledge:
    schema: schema.pg
    queries: queries/
policies:
  base:
    file: base.policy.yaml
    applies_to: [graph.knowledge]

As open-source models improve - AI sovereignty is becoming an important deployment target.

If the graph is accumulated organizational memory, ownership cannot be conditional.

An export button is not ownership.
Ownership = you fully control all the data and graph config.

Omnigraph is fully aligned with that:

• Based on open Lance format

• Fully open sourced & transparent

• 0 vendor lock-in

This makes Omnigraph the perfect DB for the sovereign AI infra: typed, branchable, reviewable, governed, declarative, owned.

Check out the repo. And here are cookbooks that will help you to setup graph quickly.