What is a context graph?

Take everything an agent or AI application currently knows — the user it's helping, the systems it touched, the decisions made so far, the documents it consulted — and store each of those as a node, with typed relationships between them: (:Fact)-[:ABOUT]->(:Entity), (:Fact)-[:SOURCED_FROM]->(:Document), (:Decision)-[:SUPERSEDES]->(:Decision).

That structure is the context graph. It's not the model's training data and it's not a prompt template; it's a live database of the situation, small enough to traverse in milliseconds and precise enough to cite.

The two are often conflated because both store entities and relationships. The difference is posture. A knowledge graph is an organisational asset: curated, reviewed, slowly changing, meant to be true for everyone. A context graph is an operational record: written continuously by agents mid-task, scoped to a user, session or fleet, stamped with sources and timestamps, and allowed to contain observations that are later superseded.

You can build one from the other — promote hardened facts from context graphs into the knowledge graph, or seed a context graph with a slice of org knowledge — but they answer different questions: "what does the organisation know?" versus "what does this agent know right now, and how does it know it?"

The schema that keeps working across teams is small: Entity nodes for the things that matter (people, services, accounts, tickets), Fact nodes carrying a statement with an observed_at timestamp, ABOUT edges from facts to entities, and SOURCED_FROM edges from facts to where they were learned — a document, a conversation, an API response.

You don't design the full ontology up front. Relationship types accrete as the agent's questions demand them, which is exactly the property-graph model's strength: adding DEPENDS_ON next month doesn't invalidate what's already stored.

Writes happen as the agent observes: extract entities and facts from what just occurred and MERGE them, so re-observing the same fact is idempotent rather than duplicating. Reads are traversals: start from the entities in the current query and walk their neighbourhood — facts, sources, related entities — rather than replaying history.

That's what keeps the token budget flat. Dumping a 2,000-entity knowledge base into an LLM's context costs about 202,285 tokens per query; traversing to the relevant subgraph costs about 2,668. The retrieved neighbourhood stays roughly constant as the graph grows, because the query bounds the walk, not the corpus.

Every fact in a context graph arrives with its lineage: which source produced it, when it was observed, what superseded it. When an agent answers, the traversal it ran is the citation trail — you can inspect exactly which nodes produced the answer. For anything customer-facing, regulated, or simply debuggable, that auditability is the difference between "the model said so" and "here's why."

CognoDB is built to be this layer. Instances provision in seconds and bill for what you use, so a graph per agent, per session or per tenant is an architectural choice rather than a cost decision — isolation by database, not by WHERE clause. Agents connect two ways: any Bolt driver with Cypher, or the built-in MCP server, which lets Claude, Cursor and other MCP clients read the schema and traverse directly. Full-text BM25 search inside the database covers the "find the entry point by keyword" step without a separate service.