Omnigraph is engineered for the new workload introduced by long-horizon agents: multiple agents sharing a typed world model to continuously retrieve and update context and coordinate work. Agents and UIs can become thin stateless consumers of durable state.
Omnigraph Cloud is in private preview: join the waitlist.
Join the Omnigraph Slack community to ask questions, share feedback, and follow development.
Capabilities
| Capability | What it gives you |
|---|
| Typed ontology | Agents share one enforceable model of the domain. .pg schemas declare node and edge types, keys and constraints, and the engine enforces them on every write. |
| Multimodal retrieval | Agents assemble high-precision & recall context in one query: graph traversal + vector ANN + full-text + Reciprocal Rank Fusion in one runtime, with filtering. |
| Branching | Agents propose reviewable changes instead of writing to main: a branch per agent or task, three-way merge, time travel across the whole graph. |
| Declared as code | A cluster.yaml declares graphs, schemas, stored queries, embedding providers and policies. cluster plan previews, cluster apply converges, Terraform-style. |
| Security as code | Cedar policy enforced server-side on every mutation, per graph or server-wide; bearer auth, server-resolved actors, audit tracking. |
| Object-storage native, open format | Decoupled storage and compute. Store graphs on local disk or S3-compatible storage: RustFS / MinIO, AWS S3 / R2, or Azure preview. Graph data uses open, versioned Lance, including Blob values. |
What you can build
| Use case | What it's for |
|---|
| Company brain | Org knowledge unified into one graph every agent can query |
| Agentic memory | Durable, versioned memory: a branch per agent or per task, merged on review |
| Context graph | Decision traces and codified tribal knowledge for retrieval |
| Dev graph | Issues & dependency model that coding agents read and write |
| R&D / ML data layer | Experiments and trials written into branches, versioned for training & eval |
Install
curl -fsSL https://raw.githubusercontent.com/ModernRelay/omnigraph/main/scripts/install.sh | bash
This installs omnigraph (CLI) and omnigraph-server into ~/.local/bin from
published release binaries. Or with Homebrew:
brew tap ModernRelay/tap
brew install ModernRelay/tap/omnigraph
Studio
Omnigraph Studio is the desktop app for your graphs. Browse each type as
a table, follow relationships on a canvas, write queries with the compiler's
errors as you type, and review what a branch changes before you merge it. It is
a native Rust app on GPUI, the framework behind Zed, for macOS, Windows and Linux.
Open a graph on one of your server targets in Studio:
omnigraph studio --target <server> --graph <graph>
Download Studio or read its source.
Set it up with an AI agent
Omnigraph is built to be run by coding agents. Two ways in:
Teach your agent the playbook. The omnigraph binary carries the
omnigraph agent skill written for it: the operational
playbook covering cluster mode, the two config surfaces, schema evolution, query
linting, data writes, branches, Cedar policy, and the common gotchas. Export it
where your agent loads skills, so the skill always matches the installed CLI:
omnigraph skill export ~/.claude/skills/omnigraph --force
With an older CLI that has no skill command, or none installed,
npx skills add ModernRelay/omnigraph@omnigraph installs the copy on the
default branch instead.
Or have an agent set it up from scratch. Paste this into Claude Code,
Codex, or any agent that can read a URL and run a shell command:
Read https://github.com/ModernRelay/omnigraph/blob/main/skills/omnigraph/references/onboarding.md and follow it to set up Omnigraph for me.
The agent installs the CLI, asks what the graph is for, builds and queries a
small local graph, and then points to the cookbooks, a cluster or Omnigraph
Cloud.
For ready-to-run graphs with real seed data (company brain, VC operating system,
pharma & industry intel),
ModernRelay/omnigraph-cookbooks
is the fastest way to see Omnigraph shaped to a real domain.
Deploy
A cluster declares graphs, schemas, stored queries, and policies in a
configuration bundle. cluster plan previews changes and cluster apply
submits them to the selected destination. The cluster-only HTTP server exposes
graphs at /graphs/{id}/… and activates applied changes without a restart.
Keep desired configuration separate from its destination:
company-brain/
├── cluster.yaml
├── people.pg # schema for the "knowledge" graph
├── queries/ # stored queries: the .gq files ARE the declaration
│ └── people.gq
├── cluster.policy.yaml # deployment permissions
└── graph.policy.yaml # graph permissions
# cluster.yaml
version: 1
metadata:
name: company-brain
graphs:
knowledge:
schema: people.pg
queries: queries/ # every `query <name>` in queries/*.gq registers
policies:
cluster-access:
file: cluster.policy.yaml
applies_to: [cluster]
graph-access:
file: graph.policy.yaml
applies_to: [knowledge]
This is the beginning of the README. Read the rest at the original. Read the full README ↗
