What Is a Branchable Graph? Git-Style Branching for Multi-Agent Graph Data

Updated

A branchable graph is a versioned graph database in which each writer—an agent, a pipeline, or a person—forks its own branch from a shared main graph, makes changes in isolation, and merges back only after review. It applies when multiple agents write to the same graph concurrently and you need to prevent collisions, reject malformed writes before they land, and keep an auditable record of who changed what. Omnigraph describes this model as "graph as code," with Git-style branch, version, and merge for data.

The core problem it solves

When several agents work on one graph at once, uncoordinated writes collide: two agents may edit the same node, one may add a duplicate that another is already deduplicating, or a malformed write may corrupt shared state before anyone notices. A branchable graph isolates each writer's work until it is reviewed, so concurrent batch writes stay safe and no agent touches main directly.

The fork–write–review–merge cycle

Omnigraph's documented workflow uses two agents, Claude Code and Hermes, working on the same graph:

  1. Branch. Each agent forks main into its own branch (for example, claude/dedupe and hermes/ingest). Forking is cheap: omnigraph branch create.
  2. Write. Hermes adds new nodes and edges while Claude Code dedupes existing records. Because branches are isolated, the two never collide, and the schema plus policy are enforced on every write (omnigraph mutate).
  3. Review. Each branch's diff is approved by a human or another agent before it lands (omnigraph diff).
  4. Merge. Both branches land on main in review order, via a three-way merge attributed to the agent that made the change (omnigraph branch merge).

The result is two agents, one graph, no collisions.

What the engine enforces

Branching alone is not enough; the guarantees come from what the engine checks at each stage:

  • Typed schema. Writes are typed and checked, and malformed writes are rejected at the branch before they land.
  • Policy-gated merges. The policy decides who can merge, so approval is a rule rather than a convention. Destructive changes require explicit approval before they apply.
  • Three-way, row-level merge. Conflicts are typed and resolved at row level rather than by last-write-wins.
  • Attribution and audit. The commit graph records every change and its author, so history shows which agent produced which edit.

Consistency and history

Two related capabilities make branched work practical:

  • Atomic whole-graph commits. Readers see a consistent snapshot and never a partial write, so a query never observes a half-merged branch.
  • Time travel. Every version stays queryable, and a query can be pinned to any snapshot—useful for reproducing what an agent saw when it made a decision.

When branching is the right fit

Branching pays off when writes are concurrent, changes need review before they affect shared data, or you need to trace each change to its author. For a single writer making small, trusted updates, the branch-review-merge cycle adds steps without adding safety. The model assumes writers can be identified and that someone—human or agent—can approve merges; if neither holds, policy-gated merging has nothing to enforce.