The Contextual Agentic Graph: Context Is Not Authority

For: enterprise architects, AI platform engineers, data and knowledge stewards, and process-intelligence leads. The decision: what an enterprise graph should hold for agents, what an agent may retrieve from it, who may change it, and what it must never authorise.

A plausible path can still lead to the wrong action

Illustrative scenario: MAAH is a fictional composite used throughout the book. It does not describe a real organisation, and nothing in it is a reported outcome.

A MAAH customer asks, through a support case, for a suspended account to be restored. An account-service agent looks for context. It finds the customer, the account, the support case, an exception granted last quarter and a hardship letter that supported it. Every link is relevant. The agent proposes restoring the account and cites the exception.

The proposal cites a relevant graph path and is still wrong. The exception expired on 30 September. Since 1 October a new policy version governs restoration. A name match also links the customer to an account in another tenant, and that path should never have been visible to this task at all.

None of these problems is a retrieval failure in the usual sense. The agent found the right things. What it lacked was the condition attached to each thing:

• who said it;
• when it was true;
• which purpose permits it to be read;
• whether it is a verified fact, an extracted guess or a decision someone once proposed.

And even with perfect context, the graph could not have approved the change. That decision belongs to a different component, checked at a different time.

This article introduces a design pattern for that gap: the Contextual Agentic Graph (CAG). It is a CAE proposal built on established graph and agent-memory work. Its main contribution is a set of boundaries rather than a new store.

What already exists, and what CAG adds

Context graphs for agents are established practice. Neo4j describes context graphs that combine three kinds of agent memory:

• long-term enterprise knowledge;
• short-term conversation history and task state;
• reasoning memory in the form of decision traces.

Neo4j also publishes an open-source Agent Memory library that maps these tiers onto a graph. Its explainer defines a context graph as a connected representation of the knowledge, state, history and decision records an agent needs for a task. Zep’s Graphiti describes itself as a framework for temporal context graphs with explicit bi-temporal tracking. Every derived entity and relationship traces back to the source episodes that produced it, and superseded facts are invalidated rather than deleted. These are the foundations CAG builds on. They are not things CAE invented.

The acronym needs a warning. CAG already means cache-augmented generation in the research literature: Chan and colleagues’ paper preloads knowledge into a model’s context and cache instead of retrieving it at query time. In CAE writing, CAG means Contextual Agentic Graph and is local to this architecture. First use should always spell it out.

What CAG adds is a governance contract around a context graph. It answers four questions that product features alone do not settle:

1. What is a dependable claim, as opposed to a plausible connection?
2. Which paths may this principal, tenant and purpose see?
3. Who may change shared knowledge, and on what evidence?
4. Where does the graph’s influence end and authority begin?

Definition: a governed, time-aware map that supplies context, not permission

Contextual Agentic Graph (CAG): a proposed CAE design pattern. It is a governed, time-aware map of enterprise meaning and agent activity, linking entities and relationships to:

• source evidence;
• ownership;
• permitted scope;
• validity;
• decisions and outcomes.

The aim is that an agent can assemble context with provenance and scope rather than merely find similar text.

Three properties follow from that definition.

It is a logical contract, not a database. CAG does not require all enterprise information to move into one graph. Documents stay in their repositories, transactions stay in their systems of record, and controlled policy stays in its policy store. The graph holds typed references, relationship claims, digests and the conditions attached to them. A federated graph, a relational model with graph queries or a dedicated graph platform can all realise the same contract.

It holds claims, not truths. A relationship is a claim with a source, a state and a lifetime. “Exception E-77 applies to account A-204” is true only between two dates, only on the authority of a named source, and only until someone with the right to do so corrects it.

It supplies context, never permission. A graph path explains why a proposal is supported. It does not authorise the account change. In the CAE architecture, the capability gateway checks current identity, delegated authority, policy, approval and transaction preconditions against authoritative services at the moment of action. The Commit Boundary article develops that check.

The claim model: ten object types and six claim states

The second edition proposes a conceptual model of ten object types:

Each relationship carries a visible claim state:

• observed: recorded from an authoritative event;
• declared: asserted by an accountable owner;
• extracted: produced by a model from unstructured content;
• inferred: derived from other claims;
• disputed: contradicted by another source;
• validated: reviewed and accepted.

In the MAAH example, “customer holds account” is observed from the core banking record. “Same person as account B-31” is extracted from a name match and must never be presented as equivalent. An agent’s own conclusion is at most a candidate for one of these states. It does not become knowledge because the agent wrote it down.

Two kinds of time

Every claim needs two timelines:

• Valid time: when the claim was true in the business world.
• Recorded time: when the enterprise learned it, changed it or corrected it.

The distinction answers questions that a single timestamp cannot. A policy loaded today may have governed a decision made last month. An exception discovered today may have expired yesterday. A correction made this morning must not silently rewrite what a decision-maker could have known last week.

With both timelines, three questions become answerable:

• Which policy applied at decision time?
• What did the agent see when it proposed this?
• What has changed since the previous decision?

Those questions underpin replay, audit and fair review of past decisions.

Reading: scope first, then search, then disclose with care

For each task, the Context Contract supplies five things:

• the principal;
• the tenant;
• the purpose;
• the decision horizon;
• the evidence obligations.

A policy-aware query then runs in four steps:

1. Bind the caller’s tenant, purpose and entitlements to the query.
2. Resolve canonical entities within that scope.
3. Combine exact and semantic search with permission-aware, bounded relationship traversal where it helps.
4. Return only permitted evidence paths in an evidence package.

The package contains each item’s source, claim state and validity, any contradictions, and the material required by the contract but not found.

Three rules matter more than the choice of query language.

Filter before retrieval, not after ranking. Scope must be bound to the caller, tenant, purpose and current entitlements before candidate material is gathered. Removing forbidden nodes after ranking, or after content has reached the model, is too late.

Paths can disclose. Hiding a restricted node is not enough. A path that routes through it can reveal that it exists, as can a count of hidden neighbours or a summary built from it. In the MAAH example, the existence of a same-name account in tenant B is itself sensitive. Testing must cover path and inference leakage as well as direct reads.

Missing evidence is an answer. “The policy current at 1 October was not found” is more useful than a confident proposal built on the last policy the graph happened to hold. The evidence package should state the gap, and the agent should carry it into the proposal.

The retrieval-routing article covers when relationship traversal earns its place alongside keyword and vector search.

Writing: the hard half of the design

Shared memory fails more often on writes than on reads. CAG therefore needs an explicit write contract.

• Authoritative adapters may publish records within their defined scope, such as customer-holds-account from the core system.
• Extraction models and agents may submit only candidates: an entity, an edge or a correction, each with evidence, confidence, purpose and provenance.
• Domain stewards, or an explicitly delegated validation workflow, accept, reject or qualify candidates. A model’s self-critique is not independent verification.
• Releases are versioned. A change carries a schema and content version and a record of who approved it, and it is tested against the queries and agent decisions it affects before publication.
• History is preserved. The history needed to explain earlier decisions is kept: a superseded edge is marked superseded, not erased.
• Revocation propagates. A correction, revocation or access restriction must reach indexes, embeddings, summaries and caches within a defined service level. If it does not, an old graph-derived answer can outlive the fact it was built on and remain available to a task that should no longer see it.

A rejected candidate should usually stay visible as a rejected claim, where retention and access rules allow. That prevents the same error being rediscovered and resubmitted every week.

Where CAG stops, and what AFM does instead

Agentic Flow Mining (AFM) is CAE’s proposed extension of process mining to agent, tool, human and policy events. It analyses what agents and people actually did:

• which context they read;
• which tools and handoffs occurred;
• what approval was obtained;
• which effect was committed.

CAG answers a different question: what connected claims and evidence this task could use, under its scope, at that time.

The second edition draws the boundary precisely. CAG links governed knowledge to references to agent tasks, decisions and outcomes. AFM retains and analyses the execution trace itself, in the event and evidence plane. Stable identifiers join the two: request, graph revision, retrieved claim identifiers, policy decision and committed effect.

That separation is what lets each component stay honest:

In the MAAH example, AFM sees the agent read an expired exception and the gateway escalate. If the pattern recurs across runs, AFM can identify the affected runs and the source relationship. It then submits a candidate correction with that trace evidence. A steward checks the source and any conflicts, accepts the correction, tests the queries and decisions it touches, and publishes graph version 4 with the exception marked superseded. The next evaluation checks whether decisions improved without introducing disclosure or retrieval regressions.

Incomplete traces deserve the same care. If an event or a graph revision identifier is missing, AFM should report an unresolved case rather than a clean pass. An absent edge does not prove the agent never saw the information. A present edge does not prove the source was accurate.

Implementation: database-independent by design

CAG is a contract, so it should not depend on any one database. The guarantees that matter must be enforced and tested in the application architecture, around whichever store holds the graph:

• purpose restrictions;
• provenance and claim state;
• valid and recorded time;
• reviewed writes;
• revocation;
• authority at the time of action.

A graph database supplies traversal, indexing and storage. It does not by itself supply those guarantees.

Three open or open-core options cover most starting points:

The sensible sequence is to build a small CAG reference model on Neo4j, then run the same competency questions and permission tests against PostgreSQL with AGE. Keep the CAG contract identical across both: the claim schema, time model, scoped retrieval interface, write path and adversarial tests. The comparison then measures the stores, not two different designs. Consider JanusGraph only if measured graph size or throughput requires a distributed graph.

Graphiti is a relevant component where temporal agent memory is the main need. Like the databases, it supplies mechanisms rather than the enterprise rules on scope, ownership and authority.

Whatever the store, a database role does not by itself prove five properties:

• per-request purpose control;
• tenant isolation across every path;
• path-safe disclosure;
• timely revocation through derived indexes and caches;
• authority checked at the time of action.

Each needs explicit design and adversarial tests. Choose the platform by measured evidence:

• answer quality;
• freshness;
• permission correctness;
• update and revocation latency;
• operating cost;
• maintainability.

Neither the brand of graph nor the query language is a selection criterion.

A reference implementation for one bounded process, such as account-restoration requests, would include:

• A small schema for customers, accounts, policies with effective intervals, evidence, owners and run references.
• Fixed, parameterised queries for the common intents, with the agent given a read-only retrieval interface.
• Scope enforced per request in the retrieval service, not by the model or by database roles alone.
• A separate, reviewed write path for candidates.
• A comparison baseline: the same competency questions answered by an authorised API lookup and by hybrid document search.

Implementation challenge: convention-enforced versus database-enforced isolation

Tenant isolation in a graph can rest on convention or on the database. With convention, every query the retrieval service writes carries a tenant filter, and isolation holds only while every query path remembers it. With database enforcement, the store applies a rule whatever the query says. Neo4j Community Edition does not include role-based access control, which Neo4j lists among its Enterprise features, so a Community prototype relies on convention in the application layer. PostgreSQL with Apache AGE offers a second option. AGE keeps vertices and edges in ordinary tables, so PostgreSQL row-level security (RLS) can apply to them. Apache AGE’s documentation does not describe that pattern, so it had to be tried rather than assumed.

Lab test, 17 October 2026: one machine, one session, not a production result or a benchmark. PostgreSQL 16.15 and Apache AGE 1.6.0 were built from source. An ordinary application role, with no superuser or bypass rights, queried one graph holding two tenants. Newer AGE releases and PostgreSQL versions were not tested.

What held in that test:

• A labelled MATCH with no tenant filter in the query returned only the session tenant’s rows, and returned nothing when no tenant was set.
• Creating a claim tagged for another tenant, creating one with no tenant tag, and re-tagging an existing claim were all rejected.
• Updating or deleting another tenant’s claim affected nothing, and a variable-length path from a tenant A claim reached only tenant A nodes.

Three results differed from the obvious design:

1. Policies on the label tables were not enough. An unlabelled MATCH (n), and a direct query on the parent table that AGE’s label tables inherit from, returned both tenants. The leak closed only when the parent tables carried a policy too.
2. A BEFORE INSERT trigger did not fire for a Cypher CREATE. The same trigger fired for a plain SQL INSERT. In the test, the WITH CHECK clause of the policy is what blocked the cross-tenant writes.
3. The tenant was an ordinary session setting. The application role changed it with a plain SET and immediately read the other tenant’s rows. The retrieval service has to set the tenant for each transaction, and the application role must not be able to run arbitrary SQL.

The policy that held, in outline:

-- set by the retrieval service for each transaction
CREATE FUNCTION cag.current_tenant() RETURNS agtype LANGUAGE sql STABLE AS
$$ SELECT to_jsonb(current_setting('app.tenant_id', true))::text::agtype $$;

ALTER TABLE cag."Claim" ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_iso ON cag."Claim" FOR ALL
  USING      (ag_catalog.agtype_access_operator(VARIADIC ARRAY[properties, '"tenant_id"'::agtype]) = cag.current_tenant())
  WITH CHECK (ag_catalog.agtype_access_operator(VARIADIC ARRAY[properties, '"tenant_id"'::agtype]) = cag.current_tenant());

-- the parent table that an unlabelled MATCH scans
ALTER TABLE cag._ag_label_vertex ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_iso ON cag._ag_label_vertex FOR SELECT
  USING (ag_catalog.agtype_access_operator(VARIADIC ARRAY[properties, '"tenant_id"'::agtype]) = cag.current_tenant());

The same pair of policies is needed for every vertex label and for edges, and edge labels have to be created in advance by a deployment role. Not tested: shared nodes tagged with more than one tenant, untagged edges, query plans and performance under RLS, connection pooling, SECURITY DEFINER functions, and backups. The result is a plausible pattern with known gaps, not a verified one. It still has to pass the adversarial tests described above on the store, version and deployment actually chosen.

Application requires organisation-specific architecture, security, privacy, legal, regulatory, operational, safety, accessibility, commercial and governance review, together with appropriate approvals.

Start with one decision class and its competency questions

Do not start with “put the enterprise in a graph”. Start with one decision class and write the questions the decision depends on:

• Which policy applied at the decision time?
• Which evidence supports each relationship the proposal relies on?
• What changed since the previous decision on this account?
• Which paths are hidden from this principal and purpose, and does anything leak their existence?
• What remains unknown?

Then test the failure cases before the happy path:

• wrong entity merges;
• stale or superseded policy;
• disputed links;
• cross-tenant paths;
• revoked access;
• missing evidence;
• replayed agent observations;
• a proposal replayed after the policy has changed.

Measure task quality and false denials as well as query speed. Keep the graph where its explicit relationships and temporal provenance measurably improve decisions, after stewardship and operating costs are counted. For a simple workflow with a few stable entities, a relational model and controlled search may be enough. CAG earns its cost where relationships, time and multi-hop evidence are central to the decision.

Ownership should be explicit:

• Executives decide which relationships matter enough to govern and who owns corrections.
• Architects define the claim, time, identity and authority contracts.
• Stewards own the review path.
• Engineers own the tests listed above.

A simple first implementation

Keep the first version small enough to finish, and prove the pattern before generalising it.

1. Pick one bounded process, not the whole enterprise. Service-account access review is a reasonable start: a handful of entity types, a manageable number of relationships, and an existing human review step to attach the graph to.
2. Write the claim schema down before opening a database. At minimum, five fields per relationship (source, recorded time, valid-time interval, status and owner), and nothing is written to the graph without all five. This is the rule most worth enforcing early, because it is the one most tempting to skip under deadline pressure.
3. Give the agent a read-only, parameterised retrieval interface, scoped to the caller’s identity, tenant and purpose at the query layer, not a broad traversal filtered after the fact.
4. Route every proposed new claim or correction through the process’s existing review step. The graph does not acquire write authority of its own. A proposal is a proposal, reviewed the way any other change to shared memory would be.
5. Leave the capability gateway, the Commit Boundary, exactly where it already is. The graph answers what context was available. It does not move closer to deciding what happens next.
6. Run the same questions against today’s baseline, whether a relational query or a search index, before committing to the graph’s ingestion, entity-resolution and operating cost. If the baseline already answers the bounded process’s real questions, the graph has not yet earned its place. If multi-hop, temporal questions are central to the task, it usually will.

None of this requires Neo4j, Graphiti or any specific product. It requires deciding the claim model and the review path before picking a database, in that order.

Where this fits the governed delivery lifecycle

The claim model above is not independent of how the system that uses it gets built. Across a delivery lifecycle of intent and acceptance criteria, architecture and contracts, implementation, verification and evaluation, release and recovery, and operation and outcome learning, a Contextual Agentic Graph is decided in two of those stages, not built once and left alone.

Architecture and contracts is where the claim schema and the agent’s Context Contract are designed together, because they are one decision wearing two names. The Context Contract states what an agent may read. The graph’s claim model states what it is reading and under what conditions. An architect who defines one without the other has only half designed the system: an agent could hold a valid contract and still retrieve a claim whose evidence has expired, or sit behind a graph of sound provenance that a misconfigured contract exposes outside its intended scope.

Operation and outcome learning is where the graph closes its own loop. An AFM finding that routes a correction for review, and an outcome-learning cycle that revises a hypothesis after an observation window, both need something stable to point at, such as a claim identifier, a graph revision or an evidence digest. Without one, the next cycle is reasoning about an outcome nobody can trace back to what the agent actually saw. The graph does not grant deployment or financial authority at this stage, any more than a favourable outcome score does. It supplies the trace that lets the accountable owner decide what the observation means.

Every other stage touches the graph only as a consumer of what those two stages already fixed. Implementation reads through the scoped retrieval interface built in architecture. Verification checks evaluator findings against the evidence a run actually used. Release and recovery check current authority at the capability gateway exactly as they would without a graph in the picture.

Five ways a context graph fails, and the boundary that prevents each

1. A model-extracted relationship becomes fact. Prevented by visible claim states and a candidate-only write path for models and agents.
2. Yesterday’s valid path is used for today’s decision. Prevented by valid time on every claim and policy version, and by a freshness check at the gateway.
3. Restricted context reaches the model before the filter. Prevented by scoping to principal, tenant and purpose before retrieval, and by path-leakage tests.
4. One incomplete trace becomes institutional memory. Prevented by routing AFM findings to steward review, never to automatic graph updates.
5. A graph answer is treated as approval. Prevented by the capability gateway, which checks current authority against authoritative services at the moment of action.

Key takeaways

• Context graphs and temporal agent memory are established prior art. The Contextual Agentic Graph is a CAE governance pattern built on them, not a new database or an established standard.
• In CAE, CAG means Contextual Agentic Graph. Spell it out on first use, because the acronym also means cache-augmented generation.
• A relationship is a claim. It needs a source, claim state, valid and recorded time, an owner and a scope before an agent can depend on it.
• Scope before retrieval, and test paths as well as nodes.
• Writes are where shared memory goes wrong: models and agents propose candidates, while stewards release versioned, tested changes.
• AFM observes what happened and may propose a correction. It does not change the graph.
• Keep CAG independent of the database. Prototype on Neo4j, then compare PostgreSQL with Apache AGE on the same queries and permission tests. The guarantees live in the application architecture, not in the store.
• Context informs the proposal. Current authority, checked at the capability gateway, decides the effect.

Where the book takes this further

The second edition of The Contextual Agentic Enterprise, now in preparation, introduces the Contextual Agentic Graph in Chapter 7 with Figure 7.4. It connects CAG to Agentic Flow Mining in Chapter 12 and to the governance of organisational memory and learning in Chapter 21. More about the book.

This article is part of CAE Field Notes, a series accompanying the book, The Contextual Agentic Enterprise.

References

1. Neo4j (2026), Context graphs: Why AI agents need three types of memory. https://neo4j.com/blog/agentic-ai/context-graph-ai-agent-memory/
2. Neo4j (2026), What is a context graph? https://neo4j.com/blog/agentic-ai/what-is-context-graph/
3. Zep, Graphiti: temporal context graphs for AI agents, project repository. https://github.com/getzep/graphiti
4. Chan, Chen, Cheng and Huang (2024, revised 2025), Don't Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks, arXiv 2412.15605. https://arxiv.org/abs/2412.15605
5. Neo4j, Cypher Manual: Search-performance and semantic indexes. https://neo4j.com/docs/cypher-manual/current/indexes/search-indexes/
6. Neo4j, Cypher Manual: Temporal values. https://neo4j.com/docs/cypher-manual/current/values-and-types/temporal/
7. Neo4j, Operations Manual: Managing privileges. https://neo4j.com/docs/operations-manual/current/authentication-authorization/manage-privileges/
8. Neo4j, Licensing; Operations Manual: Introduction (editions). https://neo4j.com/docs/operations-manual/current/introduction/
9. Apache AGE, Introduction. https://age.apache.org/overview/
10. Apache AGE, project repository (source of the PostgreSQL 16 release branch used in the lab test). https://github.com/apache/age
11. PostgreSQL 16 Documentation, Row Security Policies. https://www.postgresql.org/docs/16/ddl-rowsecurity.html
12. JanusGraph, project site. https://janusgraph.org/
13. The Contextual Agentic Enterprise, second edition (in preparation), Chapters 7, 12 and 21.