# Context Engineering: Connecting the Dots with Graphs

Stephen Chin, Neo4j | AI Engineer CODE 2025 | 26:50

Source: https://www.youtube.com/watch?v=LLuKshphGOE
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/context-engineering-connecting-the-dots-with-graphs
Published: 2025-11-24
Tags: context-engineering, embeddings, memory, rag

## TL;DR
- Context engineering expands prompt design into the deliberate selection, structuring, and management of information given to AI systems.
- Knowledge graphs connect facts, relationships, properties, and embeddings so models can retrieve related information and provide more explainable answers.
- Graph-based retrieval is most useful when answering a question requires multiple related facts, while simple vector retrieval is enough for single-step lookups.

## Summary
Stephen Chin presents context engineering as the work of shaping everything an AI system receives, including prompts, retrieved data, tool results, conversation history, memory, and structured outputs. He argues that large context windows do not guarantee good answers because models may pay attention to the wrong information. Knowledge graphs address this by representing facts as nodes connected by relationships, with properties, text, embeddings, and time attached to them. Chin demonstrates GraphRAG with a Neo4j knowledge graph built from supply-chain and vulnerability documents. A two-pass retriever first finds similar nodes, then expands through related nodes before sending the result to the model. He also shows an agent using Claude Code and the Neo4j MCP server to traverse the graph through multiple queries. The talk's practical boundary is clear: vector RAG works for one-step similarity searches, while graphs help when several connected facts must be combined, inspected, or controlled with access rules.

## Key ideas
### Context engineering controls the information around the prompt
[00:58](https://www.youtube.com/watch?v=LLuKshphGOE&t=58s)
Chin describes context engineering as an expansion of one-shot prompt engineering. The system can feed an agent more dynamic information, select material for a particular domain, and structure the input so useful signals are not buried in noise. This matters because models can have huge context windows while still paying little attention to the right parts. The engineer's job becomes closer to information architecture: decide what the model should receive and how that information should be arranged. In enterprise settings, this includes business data, domain-specific grounding, task goals, and the information an agent needs to work with other agents or tools.

### A context pipeline includes retrieval, memory, and structured output
[02:53](https://www.youtube.com/watch?v=LLuKshphGOE&t=173s)
Chin places prompt engineering inside a wider context-engineering pipeline. Retrieval-augmented generation brings in enterprise and business data. Short-term memory helps models collaborate during the current task, while long-term memory preserves conversation state and history for later operations. The output also needs structure so other applications and tools can consume it. He says memory should compress relevant information into the current context, integrate useful tool results, and avoid dumping excessive output from earlier exchanges into the context window. Past conversations can be analyzed for episodic, semantic, and structural meaning, then turned into instructions, procedures, or plans.

### Memory quality affects the quality of model responses
[05:30](https://www.youtube.com/watch?v=LLuKshphGOE&t=330s)
Chin treats memory as the center of context engineering because language models depend on the data they receive. Poor or irrelevant data leads to poor responses, so the system should select the right information and place it high in the context window. He mentions dynamic prompting with DSPy and BAML, along with internal reasoning over retrieved data. Better context lets teams spend more effort on running tasks rather than only training models. He also connects structured, relevant inputs with more reliable and explainable model behavior. The practical concern is controlling what enters the model and how that material is organized before the model reasons over it.

### Knowledge graphs add relationships that language models do not store explicitly
[06:54](https://www.youtube.com/watch?v=LLuKshphGOE&t=414s)
Chin explains a knowledge graph as facts represented by nodes, such as people, places, events, or things, linked by relationships. Nodes can also have properties such as dates, types, ownership, or embeddings. His example connects Ann, Dan, a house, and a Volvo V70, with properties describing ownership, driving, and duration. Embeddings can live on the graph, which allows vector lookups alongside graph queries. Chin says graphs give AI applications structured domain information and a visible representation that humans and language models can inspect. He also describes them as possible digital twins for organizations, supply chains, and business processes.

### GraphRAG retrieves connected context and makes answers easier to inspect
[09:19](https://www.youtube.com/watch?v=LLuKshphGOE&t=559s)
Chin defines GraphRAG as any retrieval pipeline that uses graphs during retrieval. A question goes to a language model, which queries a knowledge graph for relevant information, then receives graph-derived context before producing an answer. This can add relationships, node information, and community groupings beyond vector similarity. The retrieved graph section lets developers see what evidence was passed to the model. Graphs can also support access rules. In a patient-information example, a doctor could access diagnosis data while an administrator could access contact details. The graph can instruct the model which information it is allowed to return.

### A two-pass graph retriever combines similarity with neighborhood expansion
[14:04](https://www.youtube.com/watch?v=LLuKshphGOE&t=844s)
In the first demonstration, Chin uses Neo4j Aura and the open-source Knowledge Graph Builder to ingest supply-chain and VEX security documents. The system creates graph nodes and relationships from the documents. Its retrieval process has two passes. First, a vector lookup finds similar nodes. Second, the system finds nodes related to those results and passes the expanded context to the language model. A question about the Jackson library produces details about an XML injection vulnerability, affected versions, and the version that fixes it. A question about Jasper, which was absent from the source document, should produce no answer. Chin uses this to show how a finite, editable graph can constrain responses.

### Agentic graph traversal gives more detail when the question needs it
[21:42](https://www.youtube.com/watch?v=LLuKshphGOE&t=1302s)
Chin's second demonstration connects Claude Code to a Neo4j MCP server. Claude first retrieves the graph schema, then issues several Cypher queries and pulls text chunks attached to relevant nodes. This multi-step process returns a fuller vulnerability report, including the CV number, attack type, severity, technical description, affected versions, remediation versions, and advisory information. The approach takes longer than the earlier two-pass method, but the agent can continue traversing the graph when it needs more facts. Chin presents this as a useful pattern for questions where the answer is spread across several connected parts of the graph.

### Graphs matter most when an answer requires multiple related facts
[20:30](https://www.youtube.com/watch?v=LLuKshphGOE&t=1230s)
Chin draws a boundary around when GraphRAG is useful. If a question can be answered with one similarity search or a single retrieval step, standard vector RAG may be sufficient. Graph retrieval becomes more valuable when the system must combine two or more related facts, such as people, an event, and the time of a previous presentation. He describes several retrieval approaches, including explicit queries, text-to-query generation based on a schema, and agentic traversal that iteratively gathers information. Graph algorithms such as approximate nearest neighbors, community grouping, and PageRank can also help surface relevant material.

## Notable quotes
- "We needed to give them the right information in the context window and kind of limit and give it, move it up as high as possible." (05:51)
- "GraphRAG is any retrieval pipeline which also uses graphs as part of the retrieval process." (09:45)
- "Graphs excel in use cases where you are able to pull in multiple facts which are related but don't get pulled back in a single query." (20:46)
- "The first pass it's going to do a vector lookup and find a similarity search to find related nodes in the knowledge graph." (14:04)

## Tools & references mentioned
- Neo4j
- Neo4j Aura
- Knowledge Graph Builder
- GraphRAG
- DSPy
- BAML
- Claude Code
- Neo4j MCP Server
- Neo4j Cypher
- Cypher
- GQL
- Graph Academy
- Nodes AI 2026
- graphrag.com
- Jackson library
- VEX
- Volvo V70

## Who should watch
- You are building a RAG system and need to decide whether vector search is enough or whether your questions require connected facts.
- Your model has a large context window but still misses relevant information, mixes in noise, or gives answers that are hard to explain.
- You want to add persistent agent memory, access rules, or inspectable retrieval evidence to an AI application.

## Related talks

- [Connecting the Dots with Context Graphs](https://aietalks.com/talks/connecting-the-dots-with-context-graphs) (Stephen Chin, Neo4j, 17:39)
- [Context Graphs for Explainable, Decision-Aware AI Agents](https://aietalks.com/talks/context-graphs-for-explainable-decision-aware-ai-agents) (Andreas Kollegger & Zaid Zaim, Neo4j, 16:39)
- [Mergeable by default: Building the context engine to save time and tokens](https://aietalks.com/talks/mergeable-by-default-building-the-context-engine-to-save-time-and-tokens) (Peter Werry & Brandon, Unblocked, 1:41:25)
- [GraphRAG](https://aietalks.com/talks/graphrag) (Mitesh, NVIDIA & Ching Kyong Lamb, PO.AI & Daniel Chalev, Zep & Mark Bane & Vasilia Marovitz, Cognify & Alex Gilmore, Neo4j & Ola Mabad, Cisco & Michael Hunger & Steven Shen, Neo4j & Tom Smoker, YAL.ai, 4:08:05)
- [Context Engineering in 2026](https://aietalks.com/talks/context-engineering-in-2026) (Louis-François Bouchard, Omar Solano & Samridhi Vaid, Towards AI, 1:03:26)