Context Engineering: Connecting the Dots with Graphs — Stephen Chin, Neo4j

How do you get an AI application to use the right information when a larger context window can hold so much irrelevant material? Stephen Chin, introducing himself as Neo4j’s VP of Developer Relations, opens with a Matrix metaphor: developers have become workers serving the machines, spending their time adjusting prompts. The escape is to move beyond clever one-shot phrasing and design the information the application receives.

Context engineering is information architecture for the model. It means dynamically selecting information for an application’s goal, curating it for the relevant domain, and structuring it so useful signals stand out. Enterprise applications particularly need this business context. A large context window does not ensure that the model attends to the facts that matter; retrieval and agent memory must help put those facts where they can influence the answer. In Chin’s metaphor, that is the move from trapped worker to superhero: gaining control over what the agent has available to accomplish its task.

Prompt engineering remains one component of this larger system. The surrounding components supply evidence, continuity, and a usable output contract.

Together, these determine both what the model knows during a request and how its response can participate in a larger workflow.

Short-term memory holds what the agent needs for the current task. Compress that information, prioritize relevant results high in the context window, and integrate tool results selectively. A tool may have dumped useful output several exchanges ago, but retaining all of it can crowd out the information needed now.

Long-term memory requires more than saving a conversation transcript. Past episodes need semantic and structural interpretation: what was learned, how facts relate, and which lessons should become instructions, procedures, or planning guidance. Bringing those lessons into the current context fills gaps without replaying every previous exchange. The objective is to reduce noise and the missing information that can contribute to hallucinations.

Memory quality still obeys garbage in, garbage out. Chin points to DSPy and BAML as ways to make prompting more dynamic, then extends the idea to reasoning that organizes context internally. The emphasis shifts toward what an agent can assemble and reason through at test time, alongside what a model learned during training. More context helps only when its inputs remain relevant and structured.

A knowledge graph supplies structured information alongside the LLM’s language and generative capabilities. Nodes represent people, places, events, or things; relationships record how those entities connect. This gives humans and models a structure they can inspect, and it can represent a digital twin of an organization, supply chain, or business process.

The graph-components example uses Anne, Dan, and a car. The people know one another and have a living-with relationship; driving and ownership connect people to the vehicle. Properties add detail: the car is a Volvo V70, while relationship attributes can record how long someone has lived with another person or driven the car. The distinction matters because knowing an entity exists is different from knowing how someone relates to it.

Embeddings can also live on the graph, enabling vector lookups without discarding explicit relationships. A graph therefore need not replace semantic search: it can provide the structure around its results. The combination joins the graph’s stored knowledge and context with the LLM’s language, reasoning, and creativity.

Chin uses GraphRAG broadly: any retrieval pipeline that uses graphs during retrieval. Its basic flow is straightforward:

1. A user asks a question.
2. The application searches for relevant information by querying a knowledge graph.
3. Retrieved graph information becomes additional context for the LLM.
4. The LLM answers using that context.

The additional retrieval signals include relationships, nodes, and community groupings. These can supply domain facts that a similarity search alone does not bring together.

The retrieved subgraph also gives you something concrete to inspect: which facts and connections were passed into the model? As knowledge changes, the graph can evolve. Chin proposes adding role-based access overlays, using a patient system as an example: a doctor receives diagnosis information, while administrative staff receive contact information such as phone numbers and addresses. The proposed design combines graph access rules with instructions about what the model may disclose; the talk does not demonstrate permission enforcement.

The same inspectable structure can support improvement over time. Store learning from user and agent interactions, visualize conversation flows and associated reasoning, then examine where context quality or agent performance breaks down. Relationships can be improved and duplicate nodes removed. Chin returns to the Matrix’s virtual dojo: repeated inspection and adjustment provide a way to improve the system’s behavior by changing the information it works with.

The first demonstration starts with a running Neo4j Aura instance on the free tier and the open-source LLM Knowledge Graph Builder. Its web interface accepts drag-and-drop files. Chin has already uploaded two representative documents: a supply-chain document describing artifacts, digital signatures, and relationships, and a VEX security document describing Jackson library vulnerabilities, affected versions, remediation, and fixing commits.

Ingestion has also happened before the demonstration. The LLM extracts a graph from the documents, and Chin inspects the resulting nodes and relationships. The extracted information includes who discovered a vulnerability and a vulnerability-database URL. Connecting these facts makes them available for queries and traversals, rather than leaving them only as passages inside the source documents.

Retrieval then runs in two passes:

1. Find entry nodes: use vector similarity to identify relevant nodes in the graph.
2. Expand the context: retrieve related nodes and pass the connected information to the LLM.

The desired boundary is that the application answers from this knowledge pool and declines questions outside it. That boundary is an intended behavior, separate from the mechanism that retrieves context.

Chin first asks about Jasper, another Java library that is absent from the VEX document, intending to test that boundary. He then corrects the query toward Jackson and comments on the model’s tolerance for typos. In the Jackson response, he reports information about Jackson Databind, an attack characterized as XML injection, the affected version, whether it has been fixed, and the fixed version. Those are the response details described in the demonstration, rather than a remediation recommendation for a particular installation.

The useful property is that the answer draws on a finite, editable body of information. The graph aggregates connected facts for the response, and its contents can be corrected or expanded to change what subsequent retrieval provides. That gives the application a concrete place to improve its evidence.

The Matrix analogy changes when Chin turns to agents: the film’s antagonists cooperate and have distinct personalities, much like collaborating LLM agents. Those agents need memory retrieval as well as document retrieval. An open-source Neo4j MCP server can expose graph retrieval tools, allowing an agent to search knowledge, vectors, and structural signals such as communities or nearest neighbors. Retrieved information then feeds the agent loop as contextual memory.

For short-term use, that context can describe the current conversation. For long-term use, previous conversations can be stored with temporal information and retrieved later. Memory becomes entities and relationships with properties such as text details, headings, time, and location. Embedding selected properties supports semantic search; graph algorithms add other signals, including approximate nearest neighbors, community grouping, and PageRank. The system can therefore use both semantic resemblance and graph structure to select relevant context. Chin’s bullet-time metaphor introduces the practical payoff: recovering connections that a similarity lookup may miss.

Consider the request: “Let's update this presentation from the last time I presented with Sid.” Resolving it requires more than finding a document that mentions presentations. The graph connects Chin, the VP of DevRel, with Sid, a community manager in India, and with GIDS, the developer conference in Bangalore where they last presented together. A presentation memory record adds the relevant point in time. The retrieved context can now tell the model who presented, where, and when before it attempts an update.

One way to express that lookup in Cypher is to model each presentation as a memory record linked to its presenters and event. Using illustrative labels PresentationMemory, PRESENTED, and AT_EVENT, the query finds shared presentations and selects the latest:

MATCH (stephen:Person {name: 'Stephen Chin'})-[:PRESENTED]->
      (memory:PresentationMemory)<-[:PRESENTED]-(sid:Person {name: 'Sid'})
MATCH (memory)-[:AT_EVENT]->(event:Event)
RETURN stephen.name AS presenter,
       sid.name AS copresenter,
       event.name AS event,
       event.location AS location,
       memory.presentedAt AS presentedAt,
       memory.text AS presentationContext
ORDER BY memory.presentedAt DESC
LIMIT 1;

The timestamp determines which shared presentation is last; the event connection supplies the location and event name. The returned record supplies context for a proposed update—it does not itself modify the presentation. This illustrates Chin’s multistage retrieval example rather than reproducing a query shown in the recording.

Use graph retrieval when the answer depends on connected facts. Chin explicitly leaves room for standard vector RAG: if a one-shot lookup or single similarity search answers the question, it is sufficient. He locates the additional value of GraphRAG and graph memory in traversals involving two or more relationships, where the needed facts are related but do not arrive together in a single similarity result.

Graph retrieval can give the application different degrees of control over the query:

Chin describes text-to-Cypher in terms of fine-tuning an LLM with the schema, but the following demonstration shows schema inspection and query generation, not a model-training step. Agentic traversal extends query generation into a loop: inspect what came back, decide what is missing, and query again.

The second demonstration reuses the same vulnerability graph through Claude Code. Chin has preconfigured the Neo4j Labs Cypher MCP server with database settings and supplied keywords such as graph and database to encourage tool use. He asks Claude what it knows about the Jackson vulnerability based on the graph database. This is the Labs tooling used in the recording; the current repository distinguishes it from a separate official product server.

The agent first retrieves the graph schema to learn the available structure and relationships. It then generates multiple Cypher queries for the vulnerability. Cypher is Neo4j’s graph query language. Its relationship to ISO GQL is more nuanced than the talk’s subset description: the current conformance documentation lists both GQL features missing from Cypher and Cypher features outside GQL.

After finding vulnerability information, the agent retrieves text chunks attached to those nodes. This is a useful division of labor: the graph helps locate and connect the relevant entities, while the attached text supplies further source detail. Each result can reveal what the next query should retrieve, allowing the agent to assemble a fuller answer than the initial lookup alone supplies.

Chin describes the first retrieval approach as relatively fast but limited in CVE detail, while the agentic approach produces a more detailed answer through repeated graph traversals. This is an observation from the demonstrations; no timing measurements or comparative accuracy benchmark accompany it.

The second response includes the CVE number, the affected vulnerability, attack type, severity, and a technical description. It also gives upgrade versions and advisory information. Those details matter when the task is an organizational vulnerability report: the reader needs to understand the issue and how to address it, not simply identify a matching vulnerability. The agent can return to the graph for additional evidence as it develops that report. Chin calls this the best possible response; the demonstrated mechanism is the ability to keep gathering relevant information before composing the answer.

Chin closes with paths from these demonstrations to implementation. GraphAcademy offers free, hands-on learning in Cypher and GraphRAG, including Python and TypeScript examples. At recording time, he also describes more advanced GraphRAG courses as forthcoming. The displayed learning pathway progresses from knowledge graph fundamentals and graph construction to applied projects and evaluation.

Chin reports over 13,000 registrants for the preceding NODES conference, which he describes as having taken place the prior week. His invitation to NODES AI 2026 is for a free, day-long online event devoted to AI, with a call for proposals open at recording time. The event has since concluded, and its page now points to recordings.

For deeper work, GraphRAG.com brings together research, conceptual explanations, and implementation guides. Chin presents this Neo4j-supported community resource as a way to explore different retrieval approaches and apply graphs to new problem domains—the next step after understanding how connected evidence improves an application’s context.