What Is Omnigraph? A Versioned Graph Engine for Agent Context and Memory

Updated

Omnigraph is a versioned graph database built on object storage, designed for context assembly and agent memory. Its distinguishing idea is that graph data is treated like code: schema, queries, policies, and infrastructure are declarative files that are branched, reviewed, merged, and audited. It fits teams running multiple agents against shared graph data who need isolation, typed writes, and a reviewable history — and it is less suited to simple single-writer graph lookups where a conventional graph database is enough.

The core model: graph as code

In Omnigraph, the pieces that define how a graph behaves are files rather than dashboard settings:

  • Schema — node and edge types, enforced by the engine.
  • Context and queries — each "lens" on the graph is a typed, linted query file.
  • Policies — rules governing who can write and who can merge.
  • UI and infrastructure — also declarative.

Because these are versioned like code, a change to how the graph is queried or written goes through the same review path as a code change. The engine enforces the schema, so malformed writes are rejected at the branch before they reach main.

Git-style workflows for concurrent agents

The central workflow is branch-per-agent. The documented example shows two agents, Claude Code and Hermes, each forking main:

  1. Branch — each agent creates its own cheap fork (omnigraph branch create).
  2. Write — Hermes adds nodes and edges while Claude Code dedupes existing records; isolated branches never collide, and schema and policy are enforced on each.
  3. Review — each branch's diff is approved by a human or another agent (omnigraph diff).
  4. Merge — branches land on main in review order via three-way merge, attributed to their agent (omnigraph branch merge).

No agent writes to main directly. The commit graph records every change and its author, which is what makes the history auditable rather than just logged.

Key capabilities and what they mean in practice

Capability What it does Why it matters
Hybrid retrieval Vector similarity, full-text, and graph traversal fused in one query with rrf() One ranked result instead of stitching three systems together
Typed schema Writes are typed and checked, rejected at the branch Bad data fails before merge, not after
Atomic whole-graph commits Readers see a consistent snapshot, never a partial write Queries during batch ingestion stay correct
Three-way merge Row-level merges with typed conflicts Concurrent agent work doesn't degrade to last-write-wins
Time travel Every version stays queryable; pin a query to any snapshot Reproduce or audit what an agent saw at a given point
Approval-gated operations Destructive changes need explicit approval before apply Guards against an agent deleting or rewriting data unattended

A concrete example of the retrieval model: a find_experts query takes a topic string, matches Person nodes, and orders results by rrf(nearest($p.embedding, $topic), bm25($p.bio, $topic)) — combining embedding similarity and keyword relevance in a single ranked list. The whole lens is one file that can be linted, versioned, and reviewed like any other code.

Deployment and availability

Omnigraph is object-storage native — the page describes it as a "Lance S3 graph" — and is positioned to deploy on infrastructure you own. A hosted option, Omnigraph Cloud, is listed as a private preview starting in early October, with a waitlist signup. The source material does not state pricing, so cost and access terms for either deployment path should be confirmed directly rather than assumed.

When Omnigraph fits — and when it doesn't

It fits if:

  • Multiple agents or batch jobs write to the same graph concurrently and you need branch isolation and review before merge.
  • You want schema enforcement and an auditable, attributable history of every change.
  • Your retrieval needs mix vector, keyword, and graph-structure signals in one query.
  • You need to pin queries to past snapshots for debugging or compliance-style review.
  • You want to run on your own object storage rather than a managed graph service.

A conventional graph database may be the better choice if:

  • You have a single writer or low-concurrency workload where branching adds process without benefit.
  • Your team doesn't want a code-review workflow around data changes.
  • You need a mature managed service with published pricing today — Omnigraph Cloud is still in private preview per the source.

The practical test is whether your pain is coordination — agents colliding, untraceable changes, inconsistent reads during ingestion. If so, Omnigraph's branch-diff-merge model addresses exactly that. If your pain is simply query performance on a stable graph, the versioning machinery is overhead you may not need.