Late in the afternoon of 13 March 2025, at Neo4j GraphSummit Amsterdam in A’DAM Tower, I recorded a short interview for my show with Stephen Chin, VP of Developer Relations at Neo4j. I’d already seen him twice that day: moderating the Q&A panel after the product keynote, and as one of the presenters of the hands-on workshop. So I asked him to pull the day together: what GraphRAG fixes, what comes after it, and where a developer should start.
What follows is my summary of his answers. Product claims are Stephen’s, speaking for Neo4j.
Keynotes, releases and customer stories
Stephen summed up the morning as keynotes about new releases and new capabilities of the graph database, with a focus on GenAI use cases, plus customer stories.
He also moderated the Q&A panel that followed the product keynote. According to the slide, it brought together Sudhir Hasbe (Chief Product Officer, Neo4j), Neha Bajwa (VP of Product Marketing, Neo4j), Edward Brinkmann (CTO and co-founder, Datenna), Peter Gorgels (Manager Digital Products, Rijksmuseum) and Erwin Verbruggen (Technical Project Lead, Q42). Questions came in through Slido.
The panel slide, and the panel itself, with audience questions arriving on the Slido screens.
Why ground an LLM with a knowledge graph
For Stephen, pairing a knowledge graph with an LLM is one of the most useful things you can do with a graph database. It deals with hallucinations and with answers that are inaccurate or can’t be explained.
He described a demo from his morning keynote. He gave the room a reasoning problem. The GraphSummit attendees got it right. OpenAI’s o3 reasoning model, according to Stephen, struggled with it, even with around 40 seconds of processing. He put that down to the model’s biases and to how hard it is for it to think a problem through the way a person does.
His point was what comes next. A puzzle like that is something we can check ourselves. An enterprise question that depends on domain knowledge is much harder to check. In his words: “We need to ground the LLMs with knowledge, with information where it can answer accurately.”
He pointed to a GraphRAG application that Sudhir Hasbe had shown earlier, loaded with data about Amsterdam, as an example of an LLM giving good, factual answers because the knowledge graph gave it that grounding.
Structured and unstructured data in one model
I asked what a good use case for 2025 would be, given that most companies have both structured and unstructured data. Stephen’s answer was that combining the two is one of the best uses for a graph database. You get a schema, and you can also hang properties, documents and other information off the nodes in that schema.
Graphs as memory for agents
Looking forward, Stephen expects AI applications to become agentic: agents talking to agents, and reasoning agents that collect and combine information from many places. He sees two roles for a graph database there.
- The retriever. This is GraphRAG: the graph supplies the knowledge the model answers from.
- The memory. Agentic systems need to keep track of conversations, responses and information coming from different systems. “And that’s like our human brains, memory is best explained as a graph.”
He added that a number of startups are already building agent memory on graph databases such as Neo4j. He didn’t name any.
My take: of everything Stephen said, this is the part I’d watch most closely. Retrieval is now well understood. Agent memory isn’t yet. Once memory lives in a database, it has the usual operational questions: who can read which agent’s memory, how long it is kept, how it’s backed up, and how you keep it consistent when several agents write to it at once. I explored one approach to this in my GBrain tutorial on self-wiring memory for AI agents.
Vector search plus graph algorithms
When I brought up Neo4j’s vector search, Stephen pointed to the workshop that was running while we talked. Attendees loaded a graph, loaded vector embeddings into the same database, and used them to retrieve results.
The part he stressed was that you don’t stop at the vector match. You can combine it with graph algorithms, such as community grouping, and with cosine similarity, to pick the most relevant results and pass them to the LLM as context.
The workshop I joined earlier that afternoon: Stephen was one of the three presenters on its “Who are we?” slide, and the agenda ran from loading data and vectors to GraphRAG and agents.
From the workshop: why cosine similarity is the usual choice for OpenAI embedding models, which produce normalised vectors.
My take: this is the design I’d recommend. A vector index on its own returns passages that look similar. The graph is what lets you expand from those passages to the entities and relationships around them, and that’s usually where the useful context is.
Keeping up: graphrag.com
When I asked where things are heading, Stephen came back to agents and systems talking to each other, with graph technology underneath. To keep up with the research, he pointed to graphrag.com, a Neo4j site that summarises recent papers from universities and companies. The aim, he said, is to bring those algorithms down to a level where developers building systems can understand them and apply the newest patterns.
Where to start: GraphAcademy
For someone new to all this, Stephen’s advice was to start with GraphAcademy on Neo4j’s website. It’s free training, and it includes a GraphRAG course in which you build a chatbot in Python or JavaScript. For questions, he pointed to the Neo4j community forums and the community Discord server.
Late afternoon from A’DAM Tower: the IJ ferries and Amsterdam Centraal, shortly after the interview.
Thank you, Stephen, for taking the time at the end of a long day on stage.
