Omnigraph

What is Omnigraph?

A typed property graph database with git-style branching, graph queries, and search — built for agent systems that need a shared state core.

Most agent systems spread state across too many places. The workflow engine knows one thing, the vector store another, the database another. That works for a demo. It breaks once multiple agents need to read the same state, write changes back, react to each other, and leave behind something you can inspect later.

Omnigraph gives agent systems a single, structured state core: a typed property graph with branching, queries, and search built in.

How it works

A schema defines the entities and relationships your agents work with:

node Task {
    slug: String @key
    title: String @index
    status: enum(pending, in_progress, completed)
}

edge DependsOn: Task -> Task

A query describes the condition that matters:

query unblocked_tasks() {
    match {
        $t: Task { status: "pending" }
        not {
            $t dependsOn $dep
            $dep.status != "completed"
        }
    }
    return { $t.slug, $t.title }
}

That same query can answer a read request, power a hook that fires when new work appears, and show the effect of a branch before you merge it.

Key capabilities

  • Typed graph queries — Match, traverse, filter, and project over typed graph entities using the .gq query language.
  • Git-style branching — Let agents propose changes on branches, inspect what changed, and merge back when ready.
  • 6 search modes — Full-text, fuzzy, BM25, phrase, vector KNN, hybrid with reciprocal rank fusion.
  • Hooks for coordination — React to graph changes or query-result changes without building a separate event layer.
  • CLI and HTTP API — Operate locally with the CLI or remotely via the HTTP server API.

Under the hood

Omnigraph uses Lance as the storage backbone. The graph runtime is layered on top:

  • _schema.pg stores the schema source
  • _manifest.lance pins a consistent snapshot across the graph
  • nodes/ and edges/ hold per-type Lance datasets opened for that snapshot
  • Traversal, search, branching, diffing, and time-travel all run against the same snapshot model
.pg schema  →  Catalog  →  Per-type Lance datasets
.gq queries →  Typecheck →  IR  →  Executor (scan + index + traversal)

Get started

  1. Quick Start — Create a graph, run a query, branch a change, and merge it back in minutes.
  2. Schema — Define your domain with typed nodes, edges, interfaces, and constraints.
  3. Queries — Write typed graph queries with traversal, filtering, and projections.
  4. Branching — Propose changes on isolated branches, diff them, and merge back when ready.

On this page