Omnigraph: A Lakehouse Graph Engine for AI Agent Memory

AI agents need more than chat history.

They need a shared operational memory: facts, documents, decisions, traces, tasks, branches, reviews, policies, and context that can survive beyond one session. That is the problem ModernRelay/omnigraph is trying to solve.

Omnigraph is an MIT-licensed lakehouse-native graph database for context assembly and multi-agent coordination. It is built around a clear idea: fleets of agents should be able to read, write, enrich, branch, review, and merge graph state without dumping everything into a fragile prompt or a single mutable database table.

The project combines graph traversal, vector search, full-text search, object-storage-native data, Git-style workflows, cluster-as-code deployment, Cedar policy, CLI tooling, an HTTP server, a TypeScript SDK, and an MCP bridge for LLM hosts.

That combination is worth studying because it points at where agent infrastructure is going: not just bigger context windows, but versioned context systems.

What Omnigraph Is

Omnigraph is a lakehouse graph database for agent memory and context assembly. The README describes it as the operational state and coordination layer for fleets of agents.

That phrase is important. This is not just a vector store. It is not just a graph database. It is a graph engine designed for AI systems where many agents need to operate on shared knowledge without trampling each other.

The core design combines:

• graph storage and traversal
• Git-style branching and merging
• vector ANN search
• full-text search and BM25 scoring
• Reciprocal Rank Fusion for hybrid ranking
• object-storage-native deployment through S3-compatible stores
• Lance columnar storage for branchable and time-travelable graph data
• cluster-as-code configuration
• Cedar policy enforcement
• CLI, server, TypeScript SDK, HTTP/OpenAPI, and MCP surfaces

That is a serious infrastructure shape. Omnigraph is trying to be the durable graph memory layer underneath agent fleets.

The Problem: Agent Memory Is Usually Too Flat

Most agent memory systems are simple. They store chunks, embeddings, summaries, or chat logs. That works for small workflows, but it breaks down when the memory needs structure.

Real engineering and business context is relational:

• a person owns a service
• a service depends on a database
• a decision came from a meeting
• a ticket changed an interface
• a document supersedes another document
• an experiment belongs to a model run
• an agent proposed a change that still needs review

A vector store can retrieve semantically similar text, but it does not naturally model ownership, lineage, branches, approvals, and merge history.

Omnigraph’s bet is that long-running agents need a graph of context, not only a pile of searchable chunks.

Git-Style Branches for Agent Work

One of Omnigraph’s strongest ideas is branch isolation.

The project is built for fleets of agents operating on parallel isolated branches. An agent can enrich the graph on its own branch, then changes can be reviewed and merged safely. That maps well to how software teams already think about code review.

For agent memory, this is a big deal.

Without branches, a bad extraction or hallucinated relationship can poison shared memory immediately. With branches, an agent can write proposed facts, edges, summaries, or traces into an isolated workspace. A human, verifier, policy, or downstream process can inspect the change before it becomes canonical.

That is the difference between “agent memory as scratchpad” and “agent memory as reviewed state.”

Cluster-as-Code

Omnigraph deployments are declared as clusters. A cluster directory contains cluster.yaml, schema files, stored query files, and Cedar policy bundles.

The workflow is intentionally infrastructure-like:

1. omnigraph cluster validate parses and typechecks the declaration.
2. omnigraph cluster plan previews what will change.
3. omnigraph cluster apply converges reality to the declaration.
4. omnigraph-server --cluster ... serves the applied graphs.

The control plane records state in a ledger and publishes resources into a content-addressed catalog. Re-running apply is meant to be idempotent. Destructive graph removals require an explicit approval artifact.

That shape will feel familiar to Terraform users, and that is a good thing. Agent memory should not be a mysterious runtime side effect. The schemas, queries, policies, and deployment state should be reviewable.

Retrieval: Graph + Vector + Text

Omnigraph’s retrieval model is more interesting than plain semantic search.

The search docs describe a query runtime where graph traversal, vector nearest-neighbor search, full-text search, fuzzy matching, BM25 scoring, and Reciprocal Rank Fusion can be combined in one query.

That matters because agent context assembly often needs more than one retrieval mode.

For example, an agent might need to:

• find documents semantically close to a question
• rank text matches by keyword relevance
• traverse from a document to its owner, service, project, or decision
• fuse vector and lexical rankings
• return a compact context graph rather than loose chunks

Hybrid retrieval is valuable because vector similarity and text relevance fail in different ways. Graph traversal adds the missing structure.

Security and Governance

Omnigraph integrates AWS Cedar for attribute-based access control. Policy is enforced server-side and at the engine layer for mutating write paths, so the HTTP server, CLI, and embedded SDK paths can share the same authorization logic.

The policy model includes graph actions such as read, export, change, schema apply, branch create, branch delete, branch merge, and stored query invocation. Server-scoped actions cover cluster-level registry access.

The project also pays attention to actor identity. Remote HTTP writes resolve actor identity from bearer tokens at the server boundary; clients cannot simply claim a different actor in a header or request body.

That is the kind of detail that matters if Omnigraph is going to hold enterprise knowledge or agent memory. Once agents can write to shared state, identity, auditability, and permissions become first-order system design concerns.

Object-Storage-Native Lakehouse Design

Omnigraph runs on S3-compatible object stores: AWS S3, Cloudflare R2, Google Cloud Storage through S3-compatible access, MinIO, or RustFS. The storage layer uses Lance, a columnar format that supports versioning and blob-as-data use cases.

This is different from running a graph database as one stateful box with all data trapped inside it.

The lakehouse-native design makes Omnigraph more aligned with how modern data infrastructure is deployed: object storage as the durable substrate, servers as stateless or restartable compute, and deployment state described outside the process.

For teams with private data, this also matters operationally. The project emphasizes running on your own infrastructure so data stays in your store.

What You Can Build

The README points to several use cases that make sense:

• Company brain: a shared graph of people, services, documents, decisions, and organizational knowledge.
• Agentic memory: durable memory where agents write to isolated branches and merge reviewed changes.
• Context graph: decision traces and tribal knowledge that can be retrieved with structure.
• Dev graph: issues, dependencies, services, and code relationships that coding agents can read and update.
• R&D or ML data layer: experiments and trials written into versioned branches for training and evaluation.

The common theme is not “store embeddings.” It is “make context operational.”

Where MCP Fits

Omnigraph provides an MCP server package for bridging the graph to LLM hosts such as Claude and Codex.

That is important because an agent memory system is only useful if agents can actually reach it during work. MCP gives the graph a standard tool surface. Instead of copying context manually, an agent can query structured memory, retrieve hybrid context, or operate against approved graph tools.

The repository also ships an omnigraph agent skill that teaches coding agents the playbook: cluster mode, config surfaces, schema evolution, query linting, branches, data writes, Cedar policy, and common pitfalls.

That makes the project unusually agent-native. It is not only software for agents; it includes instructions for agents to operate it.

My Take

Omnigraph is compelling because it treats agent memory like infrastructure.

The easy path is to bolt a vector database onto an agent and call it memory. The harder, more durable path is to model state as a graph, version it, branch it, review it, govern it, and serve it from infrastructure you control.

That is the path Omnigraph is taking.

It is still a young project, and teams should evaluate maturity carefully before betting production workflows on it. But the architecture is directionally strong: graph-native context, lakehouse storage, Git-style branches, cluster-as-code, policy enforcement, and MCP access.

For builders working on multi-agent systems, internal knowledge graphs, coding-agent memory, or enterprise context assembly, ModernRelay/omnigraph is worth watching closely.