Context Graph: Definition, Architecture & Why the Graph Is the Moat, Not the Model
Key Takeaway: A context graph is a graph datastore that unifies an organization's people, policies, data, and decisions as the persistent substrate AI agents read from and write to. It is the institutional memory of a multi-agent system. The model is replaceable; the graph compounds over time.
What is a Context Graph?
A context graph is a graph-structured datastore designed to serve as the shared, persistent context layer for AI agents. It holds the entities that matter to an organization — companies, contacts, projects, decisions, policies, relationships — typed, connected, and annotated with the context in which each was observed or recorded. Agents read from it before acting (to understand what is already known) and write to it after acting (to preserve what was learned).
The defining characteristic is bidirectionality: the graph is not a static knowledge base that humans maintain and AIs consult. It is a living substrate that agents continuously update. Each agent run that writes a new relationship, new observation, or new decision outcome adds to a compounding institutional memory that the next agent can build on without starting from zero.
Modern Relay's Omnigraph is a referenced implementation of this pattern: a graph that stores all organizational context — customer conversations, product decisions, team relationships, operational history — as the unified substrate for AI-assisted work across a company.
Structure and Schema
A context graph's nodes are typed entities: Company, Contact, Project, Decision, Policy, Event, Signal, Outcome. Its edges are named relationships: WORKS_AT, DECIDED_BY, RELATES_TO, LED_TO, CONTRADICTS, DEPENDS_ON. Each node and edge carries properties: source (where the information came from), confidence (how reliable), timestamp (when observed), author (which agent or human recorded it).
This typed structure is what distinguishes a context graph from a generic graph database. The types are chosen for the organization's reasoning needs, not for data normalization. The schema answers the question: "what does an AI agent need to know about this entity to act appropriately?"
For a B2B sales context: a Company node carries industry, revenue band, ICP score, last-outreach date. A Contact node carries role, seniority, LinkedIn URL, engagement history. A Signal node carries type (job change, funding round, product launch), source, date, and edges to the Company and Contact it relates to. An agent reading this subgraph before crafting outreach has full organizational context without a database join chain.
How It Differs from Adjacent Datastores
Versus a vector database. A vector database (Pinecone, Weaviate, Chroma) stores embeddings and retrieves documents by semantic similarity. It answers "what documents are semantically similar to this query?" A context graph stores typed entities and named relationships and retrieves by graph traversal. It answers "who does this person know? what decisions led to this outcome? what signals have occurred around this company in the last 30 days?" Vector search is fast retrieval of similar content; graph traversal is reasoning about relationships and causality. The two are complementary, not substitutes.
Versus a knowledge graph. Knowledge graphs (Wikidata, DBpedia, enterprise KGs built in OWL/RDF) are richly typed, ontology-governed representations of facts about the world. They are excellent for encyclopedic knowledge. A context graph is narrower: it stores the organizational context relevant to the agent's work domain, not general world knowledge. It is optimized for agent reads at query time, not for ontological completeness. The schema evolves with the organization's needs, not with academic ontology standards.
Versus a relational database. A relational database stores normalized records optimized for transactional consistency and aggregate queries. Relationship traversal in a relational model requires multi-table joins, which degrade at scale and require pre-defined query patterns. A graph database traverses relationships natively and efficiently. Context graphs need relationship traversal — "find all contacts connected to companies that had a funding event in Q1 and have not been reached out to in 90 days" — as a first-class operation.
The Moat Argument
The model is replaceable. GPT-4 gets superseded by GPT-5; Claude 3 by Claude 4; any frontier model by the next one. Migrating from one model to another is an API swap — painful to optimize, but structurally straightforward.
The context graph is not replaceable on the same timeline. It accumulates the organization's institutional memory — every decision, every signal, every contact interaction, every outcome — across every agent run. Eighteen months of agent operations writing to a context graph produces a graph that reflects the organization's unique history and relationships. No competitor can replicate that graph by deploying the same model. The graph is the moat; the model is the tool.
This is the Palantir argument applied to agentic AI: what Palantir sells is not analytics software but the graph they've built about a customer's operations over years of deployment. The software is the interface; the graph is the product.
Knowlee's Neo4j Brain
In the Knowlee architecture, the Enterprise Brain is the cross-vertical context graph implemented in Neo4j. Every vertical — 4Sales, d360, 4Talents, Heartshare — reads from and writes to the same graph. Sales contributes companies, contacts, and signals. Client services contributes projects, stakeholders, and deliverables. Recruiting contributes candidates, roles, and evaluations. Cross-cutting: every operator decision, every flashcard outcome, every strategic task — mirrored as graph nodes.
The practical consequence: a sales agent working a new account can traverse the graph to find existing relationships, past interactions, shared investors, or overlapping clients across other verticals — without any human manually assembling that context. The graph makes cross-vertical reasoning a native capability, not a manual research task.
Related Concepts
- Knowledge Graph — the broader category from which context graphs derive; richer ontology, narrower operational focus in the context graph variant.
- Agent Memory — the memory layer that a context graph implements at organizational scale.
- Agentic Mesh — the coordination topology that uses the context graph as its shared substrate.
- Agentic Operating System — the operator surface that governs who reads and writes to the context graph.
- Agentic OS vs Agent Platform — why the graph is the architectural differentiator between an OS and a platform.