Agent branches need deployment and permission checks
Omnigraph documents a branch per agent or task, followed by a three-way merge into the shared graph. That gives platform teams a concrete workflow to evaluate when agents propose changes to durable application state. The adoption question is whether that workflow fits the deployment and access rules the application needs.
The README describes typed node and edge schemas, vector retrieval, full-text search and graph traversal in one engine. Data lives in Lance on local disk or object storage. These are documented capabilities; the supplied sandbox did not measure retrieval quality, transaction behavior or recovery.
A review workflow also needs permission design. The authorization guide explains that writing an unpublished commit is voluntary for an actor with ordinary write rights. Do not assume that choosing a proposed-change workflow prevents that actor from writing directly. Check the installed policy against the actual write and merge actions your agents require.
What happened when we ran it
The sandbox installed Omnigraph commit 9f2523c in 44 seconds and recorded 847 dependencies. Build and test steps each timed out after 900 seconds. The run took place on 2026-10-20 with 3 CPUs, 12 GB RAM and image lab-rust:1. Actual compiler and operating-system versions are not established by the supplied summary.
The test-log tail shows crates still compiling, including matrixmultiply, term, ref-cast, keccak and xxhash-rust, ending at string_cache. It contains no completed test count, failed assertion or compiler diagnostic. The result is an unfinished test step within the sandbox limit, rather than evidence of failing assertions.
The build timeout likewise leaves source compilation unverified in this run. It does not establish that a published binary cannot run, or that another source build would time out. Contributors should retain the exact command, toolchain details and full logs in a separate attempt before drawing conclusions about compilation requirements.
The checkout contained 1,661 files, about 596,575 source lines and 35.5 MB. The scan recorded 19 CI workflow files and a Dockerfile, but no tests directory. That directory observation does not establish that the project lacks tests. No vulnerability audit result was supplied.
Choose an artifact before following setup instructions
The README offers published CLI and server binaries through an installer or Homebrew. A pinned released binary is a reasonable next evaluation step because this source build did not finish. That is a recommendation, not a deployment path validated by the sandbox. Omnigraph Cloud is described as a private preview.
The README specifies Rust stable, edition 2024, for source work. It documents a workspace test command that excludes the GQT and DST suites, which run separately, and says some test flows need additional dependencies or environment configuration. The supplied harness summary does not identify its exact commands, so it cannot establish whether those requirements explain either timeout.
A deployment needs a cluster definition declaring graphs, schemas, stored queries and policies. The deployment guide covers local and object storage, bearer-token configuration and TLS termination at a trusted proxy. The README also documents an MCP bridge and an exportable agent skill. Those integrations do not establish that a deployment meets your access or recovery requirements.
Keep the version boundary explicit. The supplied latest-release record identifies v0.13.0, released on 2026-10-07. Current main-branch deployment documentation describes a v0.14 HTTP contract. This review does not establish that current-main instructions apply unchanged to v0.13.0 or to the measured commit.
Branches share one writer process
The deployment guide specifies one mutation-capable writer process per cluster. That restriction includes servers, direct CLI writes, deployments, branch controls and maintenance. Read replicas and zero-downtime overlapping writer replicas are not currently supported.
Multiple agents submitting work to one server do not require multiple server writers. If your platform requires overlapping writers during replacement, however, the documented topology does not meet that requirement. The guide prefers stop-then-start replacement and requires operators to establish that prior graph work and control-store I/O are terminal before transferring ownership. Object storage alone does not remove that restriction.
Authorization is graph/branch scoped. The policy guide explicitly excludes per-entity and per-property authorization. Before importing documents for different audiences, map the required access rules to graphs and branches. Check direct writes as well as proposed changes and merges; branch creation alone does not prove that review is mandatory.
Check which migration preserves history
The v0.13.0 release says older cluster-managed graphs require export and rebuild when upgrading from v0.11 or earlier. Previous commit IDs, snapshots and branch history are not carried over. This matters if retained history is a reason for choosing the database.
That limitation is specific to the stated migration route. The same release says supported standalone graphs can be upgraded offline while preserving data, branches and retained commit history. Existing v0.12 graphs need no additional storage-format migration, although cluster-ledger conversion may still be necessary. Follow the route for your source version and graph type rather than treating every upgrade as equivalent.
Compare the requirement you need most
TerminusDB is a knowledge graph database with git-like version control. Its README also describes linking JSON and JSON-LD documents. Include it in an evaluation when versioned document relationships are central to the application.
TypeDB uses TypeQL, a declarative, functional and strongly typed query language. Its README describes schemas built around entities, relations and attributes. Include it when typed domain modeling is the main requirement. Neither alternative was measured in this run, so these are evaluation directions rather than comparative performance or reliability findings.
For Omnigraph, the next useful evaluation is a representative branch workflow, permission check and recovery exercise on a pinned artifact with matching documentation. The supplied run establishes installation and two compilation-stage timeouts; it leaves a running deployment, completed tests and workload behavior unverified.