Connecting the Dots with Context Graphs

An agent can review an engineer’s pull request while still missing the business context behind the change. That context may live in Slack discussions, customer threads, and separate enterprise systems. Giving an agent responsibility for consequential decisions does not automatically give it access to the information those decisions require. Stephen Chin opens with this mismatch: engineers have increasingly capable tools, but incomplete control over what those tools know.

The Matrix metaphor makes the choice concrete. The blue pill leaves knowledge scattered across disconnected systems. The red pill connects enterprise data, previous decision traces, and tool calls into a system of reasoning. The goal is to make the context available together, so an application can use the relationships between facts when answering a question.

Chin points to Gartner’s recognition of context graphs on its AI hype cycle and Foundation Capital’s AI’s trillion-dollar opportunity: Context graphs as signs of growing interest. The essay’s title says trillion-dollar, rather than the three-trillion-dollar phrasing in the talk; its figure is an investment thesis. The technical question is how to build the connected information layer that such applications need.

A knowledge graph represents people, things, and companies as nodes, attaches properties to them, and connects them through relationships. Chin’s small example has Dan living with Anne and driving her car. Those connections encode different facts: living with someone, driving a vehicle, and owning it are separate relationships. An embedding attached to the car adds another access path, allowing similarity search alongside explicit connections.

Using illustrative labels and relationship names, the Dan–Anne–car example can be represented in Cypher as follows. The car is one shared node, so a query can follow either its driver or its owner to the same object.

CREATE (dan:Person {name: 'Dan'}),
       (anne:Person {name: 'Anne'}),
       (car:Car),
       (dan)-[:LIVES_WITH]->(anne),
       (dan)-[:DRIVES]->(car),
       (anne)-[:OWNS]->(car)
RETURN dan, anne, car;

A vector representation can supplement this structure without replacing the facts encoded by its relationships.

The complementary roles are straightforward: an LLM supplies language capabilities, reasoning, and creativity; the graph supplies organized knowledge, context, and enrichment. Storing relationships together makes them available for retrieval, visualizing them helps people inspect the relevant connections, and analysing them can expose hidden patterns.

The retrieval example asks: What was the care plan associated with Andrea Jenkins’ emphysema? Knowing what emphysema is does not answer a question about one patient’s recorded care. Chin develops the comparison from a baseline LLM through vector retrieval to graph-grounded context.

The difference is the background connected to the patient. Chin identifies a smoking history and a previous operation as information lost in the similarity search but available in the graph-grounded example. This is an illustrative retrieval comparison, not a clinical evaluation.

The Matrix callback is Neo loading the knowledge needed to perform a task. For an agent, the corresponding capability comes from retrieving the relevant connected context before generating its answer.

Retrieval supplies grounding for the current question. The next layer is persistent agent memory, which preserves what has happened so later work can build on it. Chin separates that memory into three forms.

• Short-term memory: The conversation, current agent pipeline, and state of activities underway. Persisting these in the graph preserves information needed during execution.
• Long-term memory: Knowledge accumulated across longer tasks, procedures, and customer interactions. Its usefulness depends on a domain model that organizes business processes, entities, and participants.
• Reasoning memory: Recorded decision provenance that helps explain a recommendation and supplies precedents for later decisions.

The last category needs a precise interpretation: a useful decision trace records the evidence, actions, and rationale available to the application; it does not imply access to a model’s hidden chain-of-thought. Retained provenance can support repeatability, compliance review, and debugging.

Graphs provide a representation that both software and people can work with. An LLM can generate Cypher queries or extract graph structure from unstructured documents. A person can inspect the resulting nodes and relationships much as they would a diagram on a whiteboard. Relationships are first-class objects in this representation, rather than connections reconstructed through a series of table joins.

Chin describes multi-hop traversal as a performance advantage, without presenting a benchmark. He then combines several graph operations: FastRP produces graph embeddings; vector lookup can provide a starting point in the graph; and Louvain community grouping helps organize connected regions. Similarity and traversal serve different purposes: one locates a useful entry point, while the other follows explicit connections from it.

The open-source Neo4j Agent Memory package brings short-term, long-term, and reasoning memory together in a context graph. Chin connects this approach with explainable decisions and ACID-compliant storage, and invites contributions to the repository. The linked repository’s current APIs may differ from those used in the recording.

Podcasts make a useful test case because their information is dense and interconnected. A conversation about AI or product management can mention people, organizations, topics, and locations whose connections matter beyond any one passage. Chin’s Lenny’s Podcast Memory Explorer loads a podcast corpus and uses the three memory layers to support questions about it.

The agent receives tools built on the Neo4j Agent Memory APIs. In the demonstration, it retrieves locations mentioned in an episode, returning location records with coordinates. Chin describes using that information to build a map; the selected screen shows the returned locations and a successful Get Episode Locations tool result.

The purpose of the graph is to make the connected dataset navigable and dynamically queryable. Rather than asking only which location mentions resemble a query, the application can aggregate the locations associated with an episode. Chin describes this as a holistic view of the loaded data, compared with retrieving a partial set of similarity matches.

Cross-domain business questions require more than retrieving facts. They also require understanding why a previous decision was made. Chin distinguishes a context graph from a traditional audit log by the decision context it retains: entities and relationships connect evidence that might otherwise remain buried in Slack, email, or informal conversations. A new recommendation can then become part of the record available to the next interaction.

The architecture forms a feedback loop:

1. Retrieve context. The agent uses context graph tools that combine knowledge graphs, vector search, and data science algorithms.
2. Work through the request. Retrieved domain knowledge and earlier decision traces inform the agent’s recommendation.
3. Record the new context. The agent loop pushes its output and associated trace into context memory, adding them to the graph.
4. Reuse the history. Subsequent queries retrieve the accumulated traces alongside other relevant information.

The output of one interaction becomes evidence available to a later interaction. That is the mechanism that turns retrieval into an accumulating decision history.

The financial services example gives the graph a concrete domain model. People and organizations are entities. Decisions, transactions, and approvals are events. Applied policies, risk factors, and employee reasoning provide the context for why those events occurred. Chin describes an open-source application that can be run locally, as well as a hosted version.

Chin describes a support ticket system, CRM, and internal business data system accessed through 10 MCP tools. Claude agents orchestrate the work, OpenAI embeddings supply vector representations, and Neo4j stores the resulting context. This separates orchestration from embedding generation: Claude does not itself compute OpenAI embeddings. The application maintains both a domain graph and a reasoning graph, then exposes them through a simple Next.js interface for end users.

The demonstration asks whether Jessica Norris should receive approval. The application queries the graph for her history, including her bank account and related margin trades. It exposes model-issued Cypher queries and the graph being traversed and populated, making the retrieved information inspectable. The connected record also reveals a previous rejection—precisely the kind of prior decision that can disappear from view when systems remain separate.

The model recommends against giving Jessica the loan. Its response includes reasons, risk factors, earlier decisions, and fraud-detection patterns that it identifies as relevant to the risk. This is a recommendation presented to a human user, not a demonstrated execution of a loan denial. The person using the system can inspect the supporting context before making and defending a decision.

For developers, the value is a path from an agent’s answer back to the information used to produce it. Connected records and visible queries help users evaluate a recommendation; recorded decision context gives later interactions something more useful than an isolated final answer. Chin frames that grounded information as the practical business value of context graphs.

Chin closes with a practical route to experimentation through Neo4j’s free education program. He introduces the GraphAcademy context graphs course and says the course provisions a free Aura instance in the background. That gives learners a graph database in which to try the techniques before bringing them into their own production or enterprise environment.