The Branchable Context Graph: A New Operational State Layer for Agentic Systems

Abstract

Enterprise AI needs a new kind of system of record: a context graph. The category is emerging quickly, and most takes on it focus on the read side — decision traces, process capture, semantic retrieval. We agree the category is real, but argue the durable shape of the system is set by its write and coordination behavior, not only its reads. We call this shape a branchable operational graph: a context graph designed for agents that read context, propose changes on branches, coordinate through commits and events, and safely merge into accepted state. The pattern is characterized by: (i) a typed graph model for company context, (ii) hybrid retrieval across relationships, text, vectors, events, and files, (iii) branch-local proposed writes with diff and merge, and (iv) governance, provenance, and point-in-time reconstruction as first-class system properties.

The motivation is that agents change the shape of the database workload. Human-facing systems mostly supported search, reporting, and direct application writes. Agentic systems add a new operator profile: software that reads context, reasons over it, waits, resumes, delegates, writes proposed changes, and coordinates with other agents and humans over long-running tasks. Existing architectures separate the relevant functions across search engines, vector databases, document stores, workflow tools, warehouses, CRMs, ticketing systems, and operational databases. This creates staleness, unreliable context assembly, weak provenance, duplicated state, and unsafe mutation paths.

We argue that these problems are not incidental product gaps, but symptoms of an architectural mismatch. Agents need a substrate where context, coordination, and governed change are part of the same system. Omnigraph is our implementation of this design: an open, lakehouse-native, versioned knowledge substrate for enterprise AI.

1. Introduction

This memo argues that the knowledge architecture used by enterprises today will wane for agentic workloads and be replaced by a new architectural pattern, which we refer to as a branchable operational graph. This pattern combines the relational structure of a graph, the retrieval properties of search and vector systems, the durability and openness of the lakehouse, and the coordination primitives of version control.

The history of enterprise software has created a large number of systems of record. CRMs store customers and opportunities. Ticketing systems store support work. Document systems store narrative knowledge. Warehouses store historical facts. Search systems index text. Vector databases retrieve semantically similar passages. Workflow tools coordinate work between humans. These systems were built for useful reasons, and each optimized for a particular operator: an analyst, an application, a support rep, a salesperson, a data scientist, or a human searching for a document.

Agents introduce a different operator.

An agent does not merely query a database or retrieve a document. It assembles context, reasons across sources, acts under uncertainty, writes intermediate state, waits for new information, resumes later, coordinates with other agents, and proposes changes to shared business truth. It may operate over a customer, contract, codebase, incident, account plan, research question, or internal process for minutes, hours, or days. It may work in parallel with other agents and humans on the same underlying entities.

That changes the data management problem.

The read side becomes context assembly. The write side becomes proposed mutation. The shared-state side becomes coordination.

In existing enterprise architectures, these three functions are usually separated. Search and vector tools assemble context but do not own operational truth. Workflow tools coordinate activity but do not usually represent the full underlying state. CRMs and operational databases own accepted state but are not designed for fallible writers that need branches, diffs, and review. Warehouses and lakehouses preserve history but are not the live coordination layer for agent work.

The result is a two-tier, and often multi-tier, agent architecture: agents retrieve from indexes, write to application APIs, store memory in side tables, coordinate through workflow engines, and leave audit trails in logs or transcripts. This works for demonstrations. It is brittle for enterprises.

Specifically, current agentic architectures commonly suffer from five problems.

Context reliability. Agents need high-recall, high-precision, permission-safe context. In practice, context is assembled from disconnected systems with different freshness, schemas, ranking behavior, and permission models. Missing a relevant policy is a recall failure. Including irrelevant or misleading evidence is a precision failure. Returning stale indexed data is a freshness failure. Returning data outside the actor's authority is a governance failure.

State staleness. The state used for retrieval often lags behind the state of record. Documents, tickets, CRM records, product events, meeting notes, and warehouse tables move through separate ingestion and indexing paths. The agent may reason over an older copy of the world than the one it is about to modify.

Unsafe mutation. A traditional application usually knows what it wants to write. An agent often derives a hypothesis and should propose a change before that change becomes accepted state. Treating every agent output as a direct write to production systems is the wrong default for many enterprise workflows.

Poor coordination. Agents need to know what has already been accepted, what is being proposed, who or what is working on which part of the graph, where work conflicts, and which state changed since they last read it. Today this coordination is usually implemented outside the data layer, through queues, workflow engines, comments, logs, or ad hoc memory.

Weak reconstruction. Enterprises need to reconstruct what an agent saw, why it acted, what it proposed, what was reviewed, what was accepted, and which downstream actions followed. A transcript is not enough. The reconstructable unit is the state transition: a snapshot, a diff, an actor, evidence, policy, review, and commit history.

In this memo, we discuss the following technical question: is it possible to build a database substrate for long-running agent systems that provides high-quality context assembly, safe proposed writes, state-layer coordination, and durable reconstruction over enterprise-owned data?

We argue that this design is both feasible and increasingly necessary. The reason is not simply that agents are new. The reason is that agents collapse what used to be separate steps: reading context, deciding what to do, writing state, and coordinating future work. A database for agents must therefore treat reading, writing, and coordination as one loop.

2. Motivation: Why existing architectures are insufficient

The dominant enterprise pattern today is fragmentation followed by indexing. Operational systems produce records. Documents and conversations produce narrative context. Data platforms collect historical state. Search and vector systems build retrieval indexes over subsets of these sources. Agents then sit above this estate and call tools.

This architecture is attractive because it can be adopted incrementally. It is also structurally limited.

First, context assembly is not a simple retrieval problem. A useful agent context read often begins from an entity and then traverses relationships: account → contacts → opportunities → contracts → support tickets → product events → meeting notes → internal decisions → similar historical cases. Some of the relevant evidence is exact and relational. Some is semantic. Some is temporal. Some is embedded in files. Some is permission-sensitive. Some only matters because of its relation to other evidence.

   ┌──────────────┐
   │   contact    │
   │   jdoe       │
   └───────┬──────┘
           │ works_at
           ▼
   ┌──────────────┐           ┌──────────────┐
   │   account    │── owns ──▶│ opportunity  │
   │   acme       │           │ renewal-Q3   │
   └───────┬──────┘           └───────┬──────┘
           │ has                      │ blocked-by
           ▼                          ▼
   ┌──────────────┐           ┌──────────────┐
   │   note/12    │           │  ticket/87   │
   │  "at risk"   │           │  p1 esc.     │
   │  2026-05-02  │           │  2026-05-04  │
   └──────────────┘           └──────────────┘

A pure vector database does not solve this. A pure search engine does not solve this. A graph database alone does not solve this. A warehouse alone does not solve this. The workload requires graph traversal, scalar filters, full-text search, vector retrieval, ranking, permissions, provenance, and version awareness in one runtime.

Second, agent writes are different from application writes. In an ordinary application, a user presses a button and trusted application logic mutates current state. In an agentic workflow, the system may infer that an account is at risk, propose new risk factors, attach evidence, suggest follow-up tasks, update an opportunity narrative, and recommend owner actions. Some of these changes should be accepted. Some should be edited. Some should be rejected. Some may conflict with another agent's work.

This points to branches, diffs, and merges. The correct default for many agent writes is not "mutate main"; it is "create proposed state."

Third, long-running work needs stable worlds. An agent may start from a snapshot, spend time gathering evidence, wait for a meeting transcript or approval, and resume later. During that time, the underlying company state may have changed. The system needs to answer basic database questions: which version of the world did the agent read from? Which changes occurred while it was working? Is the proposed write still valid? What conflicts with it? Can we replay or inspect the reasoning context?

Fourth, coordination belongs partly in the state layer. Workflow engines are useful for control flow: steps, retries, timers, approvals. But multi-agent coordination is not only control flow. It is also shared state. Agents need branch heads, commit history, locks or leases where appropriate, merge status, event feeds, actor identity, and conflict detection over the entities they are modifying.

Finally, governance must be pushed into the substrate. If an agent retrieves unauthorized context and then summarizes it, the policy failure has already happened. Permission checks, provenance, and audit cannot be merely post-hoc logging around model calls. They must be part of planning and execution for context reads and state transitions.

These requirements suggest that the agentic data problem is not solved by adding another memory store beside existing systems. It requires a new design point.

3. The branchable context graph

A context graph stores the relational, evidence-bearing state of an organization for use by agents and humans. We define a branchable operational graph as a context graph designed for the agent operator: it stores typed enterprise context as graph state and provides native support for hybrid retrieval, proposed writes, versioning, diff and merge, events, provenance, and actor-aware governance.

The graph is operational because it is used to coordinate action, not merely to run offline analytics. It contains the entities and relationships that agents and humans work on: customers, people, companies, products, tickets, contracts, meetings, documents, tasks, decisions, systems, policies, evidence, and events.

It is branchable because agent work often begins as a proposed change. A branch represents a hypothesis about the world or a proposed operational update. The branch can be inspected, extended, compared, partially accepted, rejected, or merged.

   main      ●──────●──────●──────────────────────●──────●──▶ events
                                ╲                ╱
   branch                         ●──●──●──●──●─●
                                  ▲        ▲    ▲
                                  │        │    │
                                  │        │    └─ human reviews diff
                                  │        │
                                  │        └─ agent-2 extends evidence
                                  │
                                  └─ agent-1 proposes change

It is lakehouse-native because enterprise AI systems should operate over durable, open, customer-owned data rather than forcing all knowledge into a proprietary application store. Object storage, open table formats, and modern query engines have made it practical to separate durable data ownership from compute and application logic. For Omnigraph, Lance and DataFusion provide useful primitives for this substrate: structured fields, vectors, text, blobs, versioned data, and query execution in a Rust-native system.

A branchable operational graph combines several properties that are usually split across systems:

The architectural claim is that agents need these capabilities together. Context quality affects action quality. Proposed action becomes future context. Review and merge become coordination events. Coordination changes what later agents should read. The loop is continuous.

4. Implementing an Omnigraph system

One possible design for this system has three layers.

                  ┌──────────────────────────────────────┐
  agents  ──────▶ │  retrieval & coordination runtime    │ ──▶ events
  apps    ──────▶ │  graph · text · vector · scalar      │
                  └──────────────────┬───────────────────┘
                                     │  reads · writes
                                     ▼
                  ╔══════════════════════════════════════╗
  branches ────▶  ║  transactional graph + metadata      ║
  diffs    ────▶  ║  schema · commits · provenance       ║
                  ╚══════════════════╤═══════════════════╝
                                     │  versioned
                                     ▼
                  ┌──────────────────────────────────────┐
                  │  durable open storage                │
                  │  records · vectors · files           │
                  └──────────────────────────────────────┘
                  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
                  ░░░░░░ customer-owned object storage ░░░
                  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

The first layer is durable open storage. Enterprise context should live in customer-owned infrastructure where possible, in formats that can be inspected, moved, governed, and queried outside a single application. This is the lesson of the lakehouse applied to agentic systems: the most important enterprise knowledge should not be trapped in a proprietary memory service. The storage substrate must support structured records, semi-structured objects, unstructured files, vectors, and versioned metadata.

The second layer is a transactional graph and metadata layer. This layer defines which objects, entities, relationships, indexes, and blobs are part of a graph version. It is responsible for schema, commits, branches, point-in-time reads, actor identity, provenance, and policy enforcement. In the same way that table metadata layers made object stores behave more like managed analytical systems, a graph metadata layer can make object-store-native enterprise knowledge behave like a coordinated operational system.

The third layer is a retrieval and coordination runtime. This runtime executes hybrid context reads, maintains auxiliary indexes, exposes APIs to agents and applications, and emits state transitions. It should support graph traversal, full-text search, vector search, scalar filtering, ranking, summarization inputs, event feeds, and diff generation. It should also expose enough structure that agents can reason over state without bypassing governance.

Several implementation choices matter.

Versioning and branches. Each accepted graph state should be addressable. Agent work should be able to occur on branches. Branches should carry proposed entity changes, relationship changes, evidence links, generated artifacts, and task state. A branch is not just a scratchpad; it is reviewable state.

Diff and merge. The system should be able to compute changes between branch and main. Some diffs are structural: a relationship was added, a field changed, a task was created. Some are semantic: a risk assessment changed because new evidence appeared. Merge therefore requires both conventional conflict detection and higher-level review UX.

Hybrid indexes. Context reads require auxiliary data structures: vector indexes, text indexes, statistics, graph adjacency, permission indexes, and freshness metadata. These indexes may update asynchronously, but their freshness contracts must be visible to the agent. It should be possible to know whether a context set is fresh enough for the action being taken.

Policy-aware planning. Permissions should be applied before context enters the model. If an actor cannot see a contract, an agent acting for that actor should not retrieve or summarize it. Policy should therefore affect graph traversal, search, ranking, and evidence packaging.

Provenance-bearing context. A context set should not be only a list of chunks. It should preserve the entities, relationships, documents, timestamps, versions, and permissions that produced it. This is necessary for audit, review, and later reconstruction.

Events as coordination. Commits, branch creation, merge requests, conflicts, review decisions, and material state changes should be observable. Other agents can subscribe to these events and continue work from a consistent graph state.

5. Example workflow

Consider an enterprise agent investigating a strategic customer at risk.

The agent starts from the customer node. It traverses the account graph to find contacts, opportunities, contracts, support tickets, open tasks, product usage, meeting notes, and recent executive communications. It retrieves similar historical risk cases, searches for exact mentions of renewal blockers, filters by date and owner, and ranks evidence by relevance and authority. The result is a permission-safe context set tied to a specific graph snapshot.

The agent then creates a branch. On that branch it proposes a new risk assessment, links supporting evidence, identifies likely causes, suggests mitigation actions, and creates draft tasks for the account team. It may also propose updates to the opportunity narrative or customer health fields.

A second agent sees the branch event and adds information from contract terms, usage trends, and recent support escalations. A human reviews the graph diff. Some changes are accepted, some are edited, and some are rejected. The accepted changes merge into main. The merge emits events that downstream agents and workflows can consume.

Later, the organization can reconstruct the exact graph state the first agent saw, the evidence it used, the branch it created, the changes another agent added, the human review decision, and the final accepted state. This is different from having a transcript. It is an operational system of record for agentic work.

6. Why the time is now

This architecture has become practical because several underlying changes have converged.

First, object storage has become the durable shared memory of the enterprise. It is cheap, highly durable, and increasingly the place where organizations expect to keep long-lived data. The economic and governance argument for customer-owned data has become stronger as AI systems touch more sensitive business context.

Second, open table and file formats have normalized the idea that data should be directly accessible by multiple engines. The lakehouse movement showed that organizations want both openness and management features: transactions, versioning, indexing, auditing, and performance over low-cost storage.

Third, modern retrieval workloads are no longer purely relational or purely semantic. Enterprise AI needs structured fields, graph relationships, text, embeddings, files, and event history in the same context path. Systems such as Lance point toward a useful storage model for multimodal, vector-aware, object-store-native data. DataFusion and similar query engines make it more realistic to build serious execution layers without reimplementing all database machinery from first principles.

Fourth, agentic applications are moving from demos to operational workflows. As soon as agents write to shared business state, the old database questions reappear: what commits atomically, what can run concurrently, what isolation level a long-running task reads from, what happens when two agents conflict, what survives a crash, and how to reconstruct the state that led to an action.

The category becomes necessary when these questions stop being edge cases.

7. Research questions and design challenges

The branchable operational graph design raises several open problems.

Semantic merge. Merging graph state is harder than merging rows. Two agents may update different fields but make incompatible claims. They may attach different evidence to the same conclusion. They may create duplicate tasks or conflicting recommendations. The system needs structural conflict detection, but it also needs review interfaces and model-assisted semantic comparison.

Context quality measurement. Retrieval for agents should be measured differently from human search. The system needs metrics for recall, precision, freshness, permission safety, evidence coverage, and provenance completeness. A context read is successful if it supports a safe and correct action, not merely if a user clicks a result.

Index freshness contracts. Some indexes can lag. That is acceptable only if the agent and reviewer understand the freshness boundary. A customer-risk workflow may tolerate a stale semantic index for historical examples but not stale contract terms or open support incidents.

Governance in query planning. Enterprise permissions are often complex, inherited, and source-specific. Pushing policy into graph traversal and hybrid retrieval is technically difficult, but necessary. Unauthorized context cannot be treated as a harmless intermediate result.

Graph-level transactions. Agent actions often span multiple entities: an account, opportunity, tasks, owners, evidence links, and follow-up events. Partial mutation can be worse than failure. The system needs atomicity at the graph-change level, not merely at the row or document level.

Boundary between database and workflow. Not every control-flow concern belongs in the database. Timers, retries, human approvals, and external side effects may live in workflow systems. But branch heads, commits, conflicts, proposed state, accepted state, and graph events belong close to the data. The boundary should be explicit.

Hot entities and concurrent agents. Important customers, incidents, or codebases may attract many agents and humans at once. The system needs concurrency control, leases or optimistic conflict detection, and usable merge flows for high-contention graph regions.

These problems define the category boundary. A system starts to belong in this category when it makes hybrid context retrieval, typed operational graph state, branch-local proposed writes, graph-level commits, state-layer coordination, diff and merge, point-in-time reconstruction, provenance, actor-aware governance, and durable object-store history native rather than bolted on.

8. Relation to existing systems

Several existing system categories solve important parts of this problem.

Vector databases provide semantic nearest-neighbor retrieval, but typically do not provide typed operational state, graph-level transactions, branch-local proposed writes, or merge semantics.

Search engines provide ranked text retrieval, but they generally do not own accepted business state or coordinate long-running mutation.

Graph databases provide relationship-local queries, but they are not usually designed as lakehouse-native, multimodal, branchable coordination layers for agents.

OLTP databases provide reliable application mutation, but they assume trusted application logic writing current state, not fallible agents proposing changes over long-running tasks.

Warehouses and lakehouses provide durable analytical history, open storage, and increasingly rich management features, but they are not usually the live operational coordination substrate for agents.

Workflow engines provide control flow, but not a governed, versioned, queryable model of enterprise context and proposed state.

The branchable operational graph does not replace all of these systems immediately. Instead, it provides the missing substrate that lets agents read, write, and coordinate over enterprise context with database-grade guarantees. In some deployments it will begin as an index and proposal layer over existing systems. Over time, as more work is mediated by agents, it can become the operational knowledge substrate itself.

9. Conclusion

Agents need a database that treats context, coordination, and governed change as one system.

The current enterprise architecture separates these concerns across too many layers. Context is retrieved from indexes. Truth lives in applications. Coordination lives in workflows. History lives in logs and warehouses. Governance is applied inconsistently across the path. This separation creates staleness, unsafe writes, weak reconstruction, and poor multi-agent coordination.

A branchable operational graph is a new design point for this workload. It stores company context as typed graph state, assembles context through hybrid retrieval, lets agents write proposed changes on branches, supports review through diffs and merges, coordinates through commits and events, and preserves the ability to reconstruct what happened from a point-in-time view of the world.

Omnigraph is Modern Relay's implementation of this architecture. Its goal is to provide the context graph for enterprise AI: an open, lakehouse-native substrate where agents and humans can assemble context, coordinate work, and safely merge proposed changes into accepted operational truth.

The core claim is simple. As agents become long-running participants in enterprise work, the database can no longer be only a place where applications store state after decisions have been made. It must become the substrate where context is assembled, proposed action is reviewed, coordination happens, and accepted truth evolves.