AI Engineer Code 2025
Context Engineering: Connecting the Dots with Graphs — Stephen Chin, Neo4j
Read the talk
Context Engineering: Connecting the Dots with Graphs
Knowledge graphs connect retrieval, memory, and agent tools so an LLM can work with related facts, temporal context, and inspectable evidence.
From a talk by Stephen Chin
Before you start: Familiarity with LLM context windows and retrieval-augmented generation is helpful; graph concepts are introduced as needed.
From clever prompts to useful context
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 and SteveOnJava, 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build context, then curate memory
Prompt engineering remains one component of this larger system. The surrounding components supply evidence, continuity, and a usable output contract.
| Component | Contribution |
|---|---|
| Prompt instructions | Task, grounding, and guidance |
| Retrieval-augmented generation | Relevant enterprise and business data |
| State and history | Short-term collaboration and long-term continuity |
| Structured output | Results usable by applications and tools |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Represent facts and their relationships
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Retrieve a connected context
Chin uses GraphRAG broadly: any retrieval pipeline that uses graphs during retrieval. Its basic flow is straightforward:
- A user asks a question.
- The application searches for relevant information by querying a knowledge graph.
- Retrieved graph information becomes additional context for the LLM.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build a graph from supply-chain documents
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:
- Find entry nodes: use vector similarity to identify relevant nodes in the graph.
- 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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Put graph memory into the agent loop
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Find the last presentation with Sid
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:
cypher
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let the agent choose the next traversal
Graph retrieval can give the application different degrees of control over the query:
| Strategy | How it retrieves context |
|---|---|
| Explicit queries | Prewritten queries with selected entry points |
| Text-to-Cypher | Schema-informed generation of a question-specific query |
| Agentic traversal | Repeated tool calls that navigate and gather evidence |
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Trade retrieval work for answer depth
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build the next graph application
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Build Neo4j knowledge graphs from documents, inspect extracted relationships, and query the resulting data.
MCP tools for inspecting graph schemas, executing Cypher queries, and storing graph memory across conversations.
Free hands-on courses covering Cypher, graph modeling, application development, and GraphRAG.
Concepts, implementation guides, retrieval patterns, and research links for graph-assisted retrieval.
Documentation for programming and optimizing language-model workflows with DSPy.
Documentation for developing typed language-model functions with BAML.
Further reading
Guide to document ingestion, extraction schemas, and Knowledge Graph Builder features.
Updates since the talk
- Cypher and GQL conformanceDocumentation
Current documentation of the overlap and differences between Neo4j Cypher and ISO GQL.
Conference page linking recordings about GraphRAG, graph memory, agents, and production applications.
Read the complete timestamped transcript
- 0:01
Hello everybody, and welcome to my session at AI Engineer Code Summit. And I'm gonna talk a bit about how you can connect the dots with graph technology and solve problems like context engineering, um, improving retrieval patterns, and also agentic memory.
- 0:17
So we're gonna have a lot of fun. My name is Stephen Chin. I'm VP of Developer Relations at Neo4j, and you can find me on all the different social media outlets with my handle, [REDACTED:username].
- 0:27
So excited you're all here to join for the session today, and I think this is how a lot of us have felt the past couple years as AI technology has basically taken our jobs away.
- 0:40
We've become slaves to, um, AI programming, to prompt developments, to building things off AI models. Now, it's not all bad. I mean, we, we have a lot more time to, to play games, to hang out in the matrix.
- 0:52
But what we really wanna be doing is we wanna be doing things which are higher value. So this is where context engineering comes in the picture and transforms what we've traditionally been doing with kind of one-shot clever phrasing, prompt engineering to get different results out of the AI, and we're evolving that to have a more dynamic and,
- 1:12
and more wider scope of things which we're feeding the AI as context, which gives us much better results. So, um, this allows us to feed the desire of agents to get even more context and information to do things together, um, to have more dynamic models and applications, to make our applications goal-driven, um, selectively curate the information for
- 1:36
the relevancy of the particular domain which we're working in. So if you're working in a, um, an enterprise domain, if you're working with a lot of business context, this is particularly important.
- 1:45
And then we can structure the input and get a lot more signal over all the noise of what's being entered into the model, which is one of the biggest problems with models today.
- 1:53
Um, huge context windows, but very little attention focus, and simply not looking at the right parts of the context to give us good results. And this allows us to think not like prompt engineers, but like information architects, where we're building the model context, which actually gives us superior results coming out of the AI.
- 2:14
And this evolves us from being, um, you know, your traditional trapped matrix worker to being superheroes. So this is, this is where we wanna be. We wanna be in control of our destiny.
- 2:25
We wanna be able to give the agents all of the information, all the context which they need to perform the task and to do exactly what we wanna get for results out of it.
- 2:34
And there's a lot of tools at our disposal now which allow us to manipulate, control the context, and really, um, feed the AIs all the information which they need to be successful.
- 2:44
So in the kind of the scope of context engineering, there's a whole bunch of things which are clearly, um, part of the domain that this now encompasses. So one is prompt engineering.
- 2:56
Of course, we need to design, engineer good, good prompts, um, make sure that the AI actually has the right instructions, the right information, and the right grounding which it needs to do its job well.
- 3:08
But we also need to pull in from different data sources by using things like Retrieval-augmented generation. So, um, RAG is still very relevant for the ability to pull in data from enterprise context, from different business contexts, and then supply that as additional information to the AI that it can use to make decisions.
- 3:27
Um, pulling in state and history as well. So now we actually want our models want memory, um, both short-term memory, so they can collaborate with each other, and also long-term memory, so they remember the conversation state, the history, and, um, they can do more effective long-term operations.
- 3:45
And we also want to be able to structure the output in a meaningful way, so we can actually feed into not only other applications, but other tools and things which we need to collaborate with and integrate our, um, context with.
- 3:58
And when you put this all together, this is kind of the, the scope and domain of context engineering. Now, one of the big focuses of this is all about memory.
- 4:08
So it's all about how we capture the AI memory and what we're able to do with it. So, um, there's kind of two main categorizations of memory. One is short-term memory, so this is what the AI is currently working with on the current tasks.
- 4:23
Um, we wanna compress as much information as possible into the short-term memory and give it relevant results which are high up in the search window. Um, be able to integrate tool results into this as well, although, you know, not give it too much information from tools, especially from previous exchanges where the tools might have dumped a lot
- 4:40
of output or information which will fill our context window. Um, and in addition to this, we also need to mix in long-term memory. So things which you've learned over a long set of conversations, which might be episodic.
- 4:53
Um, we need to figure out the s- semantic and the structural meaning of past conversations. Um, kinda pull this out into things which can either be used as instructions for the AI and also for procedures and operations which we can use to, to guide and plan the artificial intelligence.
- 5:12
And, um, when we put this together, this helps us pull the more relevant context higher up into the context window, fill in the gaps, and then avoid a lot of the noise which gives us bad results or, um, hallucinations or other problems coming from our AI applications.
- 5:30
And, um, memory is really the core of what we need to accomplish. Um, you know, if you're plugging yourself up to the matrix, this is where you sy- synergize all of your memories, all the things which you wanna get into the AI together with, um, your neur- own mind, your own neural network that you want to, um,
- 5:49
express. And it's extremely important right now because LLMs are only as good as the quality of the response that they're getting from the data. So if you give them bad data, if you give them garbage, then you are gonna get garbage back out again.
- 6:01
So we need to give them the, the right information in the context window and kind of limit and give it, um, move it up as high as possible. Be able to do more dynamic prompting with things like DSPy and BAML.
- 6:14
Um, ability to do more reasoning, um, so we can do internal context engineering on top of our data. This will turn us from human developers into agents, where we're actually using more agent technology to fuel our applications to build things.
- 6:31
Um, and then this allows us to focus more on the time which we're doing our tests rather than just focusing on the time which we're training our models. Um, so together when we have more context now, it allows us to do better things, but then it's still important that we really have structured inform-information, relevant inputs, and this
- 6:53
improves the reliability and explainability of our models that come out of it. Um, so one of the ways which we can do this is by leveraging knowledge graphs. Knowledge graphs are a technology which has been around for a while, but they're very applicable for AI because they fill in that gap between the AI, which is very good
- 7:12
at, um, creating things, building things, kind of pulling from different sources it has, but, um, structured information. Knowledge graphs are a structured representation to understand a bit about how a knowledge graph is constructed.
- 7:26
It's typically built with facts, which are, are nodes about people, places, events, or things. Those are linked together by relationships or, um, um, lines between them, which reference how those things are related.
- 7:40
It's very easy for both humans and LLMs to read knowledge graphs, so s- both acts as a, um, organizing concept, but also a way which you can understand what your AI is doing and actually look at some of the data behind it.
- 7:53
And, um, it can be of... also very useful as a digital twin of your organization, of your supply chain, of, um, a whole bunch of different processes in your organization.
- 8:04
And the basic construct of a knowledge graph is, um, nodes, which represent different people in the situation, relationships, and then you can attach properties to these nodes. So this is an example of a knowledge graph where you have two people, they know each other, they live with each other.
- 8:20
Well, one person lives with the other, so I guess technically it's Anne's house. And they both drive a car. Now, the car is owned by Dan or, or by Anne, but it's driven by Dan as well.
- 8:33
So they both have a relationship with the car, and they have a relationship with living with each other, and you can see the, there's attributes on this, how long has Dan lived or driven the car, the type of car, so it's a Volvo, um, it's a, um, model V70, some information about it, and also some embeddings.
- 8:52
So we can also encapsulate embeddings on the graph as well, so we can do vector lookups. And this allows us to do fairly complex things as we build larger knowledge graphs to capture all this information.
- 9:06
And what knowledge graphs gives the benefit of is all of that knowledge, context, and enrichment that we can build into a representation of knowledge. In addition to LLMs, which have kind of that language, reasoning, and creativity, and when we put them together, we can do really powerful things.
- 9:23
Um, so we talked a bit about RAG being an essential part of context engineering, and a even better way of doing RAG is GraphRAG. Now, what is GraphRAG? So GraphRAG is any retrieval pipeline which also uses graphs as part of the retrieval process.
- 9:43
And so, um, an example of this is a user asks a question,
- 9:48
um, it goes to the LLM, and it does a search, and it asks for if there's any relevant information, which will go a, as a query out to a knowledge graph.
- 9:56
This then gets passed in as additional context to the LLM when it's answering the question, and then the LLM gives an enriched answer, which is more relevant. So it's, it's a...
- 10:06
will give you more relevant results than just a vector similarity search because you also have information about relationships, about nodes, about community grouping, more context. So you can now get domain information, factual information, structured knowledge on your subject.
- 10:23
You can explain what the LLM is actually doing because you can see the part of the knowledge graph which got passed to the LLM, and you can also evolve the knowledge graph over time, and you can now start to i-implement overlays like role-based access.
- 10:35
So you can say only these people get access, for example, in a, um, patient i-information system. Only the doctor would have access to the diagnosis, but only the person who, um, handles the administrative information would have access to phone numbers or addresses or other personal information about the patient.
- 10:55
So it allows you to kind of overloas- overlay that role-based access directly on the knowledge graph and then instruct the LLM on what information it's allowed to respond with.
- 11:05
And, um, knowledge graphs allow this sort of explainable AI. So in a, in a large graph with a lot of nodes and a lot of information, now you can store the learnings from the user and agents into the interactions of the graph context.
- 11:18
You can start to visualize conversation flows with the addition of reasoning. You can analyze the context data of agent systems about performance, um, identify opportunities for improvement over time of the, um, either the, um, the quality of the results which are passing in, the relationships, um, removing duplicate nodes so that you get better quality results coming out
- 11:41
of it. So it gives you a lot of control over the application and the ability to modify and control what the AI is answering, kind of like you're, you're training in a, in a dojo.
- 11:51
So I think, uh, you know, in the, in the film, Neo spends a lot of time doing virtual training, improving his skills with different programs he's loaded up. And, um, this is how we're able to do a lot of amazing things, like this demo which I'm gonna show you.
- 12:05
So the first demo we're gonna show is a, um, GraphRAG demo using the LLM Knowledge Graph Builder. So I've already set up a Neo4j Or instance, this is the, um, um, online free version of Neo4j.
- 12:19
You can see I have a, a running instance with a bunch of relationships loaded up. And to load up those relationships, I use the Knowledge Graph Builder. The Knowledge Graph Builder is a very simple web application.
- 12:31
It's open source, and it lets you do a couple things. So it lets you upload files, so you can drag and drop different files into the user interface. Before the presentation, I loaded up a couple representative files of a, um, supply chain use case.
- 12:45
One is a supply chain document, and as you can see here, it has a whole bunch of information about different artifacts, um, and the digital signatures of them and the relationship in front of them.
- 12:57
And the second one is the more interesting one. This is a, a VEX document, which is a security standard, and it talks about some vulnerabilities, um, in this case, inside the Jackson library, and talks a bit about, um, how to remediate with it, which versions are affected, um, which commits fix it, and all that good stuff.
- 13:16
So, um, we have quite a bit of information which we loaded up. And then what I've done is I've already dropped those into the knowledge graph, and we can take a look at what got generated by the LLM.
- 13:28
So it takes this through an ingest phase, um, where the LLM actually builds out a knowledge graph, and then we can see that the-- some of these nodes represent different parts of the, um, VEX document.
- 13:41
Um, here we can see some information about, um, um, who found the vulnerability, information about the, um, vulnerability database URL, and, um, all this stuff is connected with different relationships, and this allows us to query, navigate, and traverse this information to build better responses for the LLM.
- 14:01
So what we're gonna do in this demo is we're gonna take this knowledge graph, which we built, and then we're going to run an LLM which does a two-pass process.
- 14:12
The first pass, it's going to do a vector lookup and find a similarity search to find related nodes in the knowledge graph. And the second pass, it's going to take those nodes which are related to the result, find related nodes, and then pass those in as context to the LLM.
- 14:30
And ideally, what we'd, what we'd like to get from the LLM is that, um, it will answer questions with information it has from the knowledge graph, and then it won't be able to answer questions or refuse to answer questions with things which are outside of that knowledge, um, pool.
- 14:45
So let's ask it, um, about vulnerabilities in the, in the Jasper library. So Jasper is another, um, Java library that's very commonly used. It wasn't actually referenced in the VEX document.
- 15:01
So we're-- in this case, we're hoping to get a no response. Okay. So that's amazing. I, I made a typo. I should have said Jackson.
- 15:12
Let's see what we get when we, um, ask about the Jackson library, even with the typo, because LLMs know that humans aren't perfect, and they're very good at fixing our mistakes.
- 15:21
And, um, here we can see that it actually pulled that information about the Jackson data bind library with an XML injection attack. It knows a bit about the vulnerability, what version it's in, um, whether it's fixed and at which version it's fixed.
- 15:37
And, um, all this information is, is pulled from and aggregated off the knowledge graph. So, um, it gives us quite a lot of information, um, very detailed and, and very focused because it's grounded in a, um, data which is, um, very, um, uh, complete.
- 15:55
Um, it's finite, and it's something we can edit, modify, and change the response over time. So knowledge graphs are a very powerful tool. It allows us to do things like this where we can, um, get better responses and better answers.
- 16:09
And now with knowledge graphs at our disposal, now we can, we can go and we can fight the, um, the evil agents. Actually, it's kind of ironic that the, um, the agents of the Matrix film were, um, the bad guys, but actually they operated and acted a lot like modern agents, where we're having LLMs collaborate, pool together,
- 16:31
and, um, cooperate on different algorithms. And even the agents of the film had different personalities and, um, different types, um, kinda like individual agents. So, um, we need to power up and, and get our, um, Matrix and graph skills up to a level where we can go tackle the agents with new tools like memory retrieval.
- 16:51
So we, we talked a bit about graph retrieval and, um, graphs are also a great tool and mechanism which you can use to do, um, memory retrieval as well.
- 17:01
So we can do search, um, in, in memory, use graph memory retrieval tools. We have an open source MCP server which does a lot of this for graph retrievals.
- 17:11
And now you can q-query the graph not only for knowledge graphs, but also vectors as we did in the last, um, example. And we can also use graph data science algorithms like, um, community groupings or k-nearest neighbors or different graph algorithms which allow us to get, um, pull some insights out of the relationship and the structure of
- 17:31
the graph, pull back relevant information, and then pass this as additional context, um, either for short-term or long-term memory into the agent loop, um, where now we're feeding the agent with additional information and context from either, um, a short-term memory source about the current conversation or knowledge pulled in, like kind of what we showed in the previous
- 17:53
example from a graph or from a long-term structure of memory where we memorize, um, previous conversations, give them temporal information, and then structure those into a memory that can be retrieved from the graph.
- 18:07
And, um, now we're able to use graph memory to capture knowledge in the form of entities and relationships between them, where some nodes have the relevant properties such as text details and headings, time, and location on top of them.
- 18:18
So this is kind of a, a visual representation of our, of our graph, our memory graph. Some of these properties get vector embedded, and this enables us to do vector-based semantic search.
- 18:28
So now we can do semantic search on the graphs via projections into vector space. But then we can also use algorithms like k-approximate nearest neighbors, community groupings, um, PageRank algorithms on top of the graph to answer different types of questions and to kind of bubble up the most relevant results into the context.
- 18:51
This gives us quite a lot of power 'cause we can do both the vector embeddings, but we can also
- 18:57
do additional graph algorithms on top of it.
- 19:02
Okay, so now we have our, our superpower with our, our graph. We're, we're able to do amazing things which aren't possible just with, um, vector embeddings and similarity searches, kind of like, like the bullet time in the Matrix films.
- 19:15
Um, this will allow us to do amazing stunts and to evade the, um, um, the agents. But let's give a quick example of how this would actually work in practice.
- 19:24
So let's say, uh, my question to the LLM was, "Let's update this presentation from the last time I presented with Sid," who's my colleague in India. Um, so we can now search this information in the graph, and there's two relevant people for this, right?
- 19:39
So it's, it's me, um, VP of DevRel, it's Sid, who's a community manager, and the event, and the last time we presented it was at an event called GIDS, um, which is, uh, an event in Bangalore, awesome developer conference.
- 19:54
So, um, now we have kind of that temporal relationship with the two people and then an event. And we can add to this the, the memory record at a particular time of the presentation.
- 20:08
So now we're pulling back information about this presentation at a specific point in time, and we can pass this in as context to the LLM. So when we ask it to update the presentation, we both have the context of who presented, where they presented, and the time period in which they presented for the LLM to build additional
- 20:27
information on top of it. This is only possible because we can do this, um, multi-stage query with graphs. Graphs excel in use cases where you're able to pull in multiple facts which are related, um, but don't get pulled back in a single query.
- 20:43
If you can do it in a, in a one-shot or you can get a, a single similarity search, um, standard vector RAG is, is fine for those sorts of use cases.
- 20:52
It's where the relationships are two or more where you get the real value from doing, um, graph RAG and graph memory.
- 21:01
And, uh, this allows us to do a whole bunch of different types of graph retrievers. So, um, we could do explicit retrieval queries where we have pre-canned retrieval queries with different entry points and retrieving some context.
- 21:11
So this gives us some great information from the graph, but we can do better by doing text to Cypher, so fine-tuning the LLM with the schema, generating a query for the question.
- 21:21
And then we can kind of take this to the next level with agentic traversal, where we iteratively navigating over the graph, collecting information until we answer it, and using an appropriate set of tools.
- 21:30
And to show an example of this, um, we're gonna use the same knowledge graph which I loaded up again in our demo number two. But this time, we're gonna query that knowledge graph using Claude Code.
- 21:44
So what I've done is I've hooked up Claude Code using the, um, Neo4j MCP Cypher, um, MCP server, which is an open source extension 'cause they Neo4j Cypher MCP server, which I've already configured with the database settings.
- 22:00
And now when we talk to Claude and we ask it a question, it can answer with that additional graph context that it can tell us things. So I put a few keywords into the MCP server like, um, graph and database, and we can ask it, um, "What do you know about the Jackson vulnerability,
- 22:18
uh, based on your graph database?" And so now in addition to, you know, pulling in information from its standard knowledge sources, it's gonna use the Neo4j MCP server and then query it to get additional information.
- 22:32
And you can see that it's doing this multiple step plans, um, search of the graph. So first it gets back the scheme of the graph so it can understand the relationships and how the graph is structured.
- 22:44
Now that it understands the scheme of the graph, it can go back and it can make a bunch of queries to get information about the particular vulnerability. So it's firing off a bunch of different Cypher queries.
- 22:54
Cypher is the, um, graph query language for Neo4j, and most graph databases support it. It's also now a standard. The GQL standard that's ratified by ISO is, um, basically is a subset of Cypher.
- 23:09
And now that it got back information about the vulnerabilities, it's pulling back some of the text chunks to get additional context which are hanging off of those nodes. And this way it can give us a, a very complete answer with as much information and context as possible from the graph.
- 23:25
And the, the main difference between this approach w- compared to the previous one is the previous approach was relatively fast, but you-- the level of detail it gave us on the CVE was limited.
- 23:40
When we give a, an, an agent, in this case we're giving the Claude agent the ability to kind of have at it for the graph, do traversals, get information, do more traversals, you can see that it gives us back very detailed information about the vulnerability.
- 23:53
So it figured out the CVE number, the affected vulnerability, the type of attack, the severity, and a technical description of the attack, so it's a lot more detailed than what we got before.
- 24:04
And it tells us specifically what versions we need to upgrade to remediate the attack, um, and gives us some advisory information as well about this. So, um, if we were trying to develop a, um, vulnerability report or something to kind of explain w- how we should as an organization, um, address this vulnerability, um, using this sort of
- 24:23
agentic multi-step, um, MCP retrieval approach is quite powerful because you can see that it gives us, um, the best possible response since it's able to go back and keep pulling additional information from the knowledge graph that it needs.
- 24:38
Okay, so we've seen a few different ways which we can apply knowledge graphs to solve and improve the context of our AI applications. So now that we know that we need graphs, we need, we need a lot of graphs, and the best place to find information about graph technology and getting a lot of different use cases for
- 24:56
graphs is Graph Academy. It's a entirely free resource to learn about, um, both Cypher queries. It has courses on Cypher queries, has courses on GraphRAG with examples in both Python and TypeScript.
- 25:09
Um, we have some more advanced, um, GraphRAG courses coming up as well. So, um, a lot of information which is all free and very hands-on for you to get started and actually build your first application, kind of like the ones which I showed here in the presentation.
- 25:21
Um, now, if we want even more knowledge, kind of a wider span, we can then go to Nodes AI 2026, which is our free online virtual conference. Um, this is following up the amazing Nodes conference we had last week with, um, over 13,000 registrants, so it was a huge event.
- 25:41
And Nodes AI is all about AI for, um, an entire day with AI-focused sessions. The CFP is open right now if you'd like to submit, and it's free to attend and watch all the sessions.
- 25:53
And if we wanna really get down and, you know, beat the architect at his own game, then we need a lot of deep research and information, and the best place for that is Graphrag.com, which is a community site which we support, um, where it has all the latest research on different GraphRAG approaches, um, how-to guides and conceptual
- 26:17
information about how to implement GraphRAG, and just a general resource which will help you to up-level your ability to apply graphs to different problem domains, um, with a whole bunch of, of the cutting-edge latest research which is coming out.
- 26:33
So, um, exciting stuff. Thank you very much for joining me for the session today, and I hope you learned a little bit more about how you can use graphs to connect the dots and improve your context engineering for your AI applications.