NODES AI 2026 - From AI Workflows to Graph-Native Reasoning: A Dify Plugin for Querying Neo4j

This talk introduces the Dify plugin, developed by Nikola Milojevic and Michal Hunger in collaboration with Neo4j, designed for building AI workflows. Dify is an open-source product that allows users to create workflows using various nodes, which can include large language models and integrations with tools like Elastic Search and various databases. The speaker explains how Dify stands out with its agent-first architecture, enabling users to prototype AI workflows quickly and effectively. By integrating Neo4j, the Dify plugin allows for enhanced querying capabilities in knowledge graphs, which are essential for tasks like target identification in biomedicine. The integration includes a user-friendly interface for executing Cypher queries and managing data across different databases. The speaker also discusses challenges related to using large language models with knowledge graphs and emphasizes the importance of ontology and entity linking to improve query accuracy. Overall, Dify is portrayed as an accessible tool for enhancing AI-driven projects with a significant focus on user collaboration and community-driven development.

[music] >> Hello. Uh so, I hope everything that is fine. So, like my name is Nikola Milojevic. I am part of my R&D and department data science and AI. And uh yeah, like I would like to introduce uh today uh the Dify plugin that we have made in with with like collaboration uh with Neo4j. So, like uh with my Michal Hunger. Uh and yeah, like I'll basically

start in case you don't know what is Dify. So, it's an open-source uh product for building um AI workflows. And uh basically on the uh right-hand side, you can uh see like how it looks like. So, like you can have this kind of like nodes and you can connect them and basically build your workflows. And these uh nodes could be anything from LLM to kind of like

full-blown uh agents uh that uh are like working in some kind of like react uh um manner. So, kind of like have this like a reflect and act uh kind of like architecture. those nodes could be as well kind of like integrations with uh bunch of other tools. Uh including like elastic uh search, vector stores, some like number of memory engines, other kind of like search engines,

uh data like like that different kinds of databases and so on. Uh and as well, there could be kind of like branching and so on. So, so so it's pretty powerful tool. It is uh, like there are a number of tools on the market right now uh, that do that could do similar things. Um, such as like N8N or uh, I don't know like pipeline pilot nine

or so that are kind of like more traditional and like not really built uh, as kind of like agent first or AI first engine but like more kind of like for automation where they feel like stands out it is a little bit more on this kind of like LLM first and it builds for you like the whole kind of like chat interfaces. You can share it with

users and so on. Uh, so it can like once you build a pipeline you can expose the workflow as either you way UI. >> [snorts] >> Uh, so it can build either a form or a chat. But you can as well expose it as API or like MCP server. Uh, so it's like pretty powerful tool. Uh, that let you easy easy and quick prototype agents or kind

of like AI workflows that are utilizing large language models or not so large language models. It has integration with all kind of like cloud providers that are hosting the LLMs and as well like you can self-host them and and so on. So, yeah, like all in all tool. However, um, yeah, like they have a marketplace with all sorts of like plugins. Uh, as you can see on

the right side. so so they are like integrations with like a number of models. Uh, tools, uh, agent strategies, extensions, bundles. There are like around like hundreds of plugins or at the time when we as well like started looking into the uh the DPA as a tool basically already had kind of like hundreds of plugins. however, like what was missing was basically a Neo4j. uh uh we

basically had the pipeline in mind that like I will show and explain uh the next slide uh shows basically what was the use case that we were trying to address. Uh and then like we found out that it's pretty easy to uh implement as well like your own plugin. So like it is based on Python, you can code like basically a single uh Python file that uh

does all the kind of like handling with of the data and so on. And there's a YAML file that defines a certain things like parameters and does some kind of like this uh descriptions. Uh and uh these plugins can be easily published to the marketplace via GitHub repo. So basically you can uh we found out that you can basically make a pull request to the official uh

GitHub repo that hosts all the uh plugins uh that are published on marketplace. Once the uh pull request gets approved, it's automatically there on the marketplace. So yeah, like I said, there was missing Neo4j uh plugin and then we decided just kind of like to build it ourselves. Uh and yeah, like the use case that we had uh a bit I don't know, like 2 years almost

ago was that like we started building uh a knowledge graph that integrated the data from a number of different data sources uh such as at that time there was a UK Biobank, like some data we needed to delete delete one from the UK Biobank because of like some regulatory reason, uh but there was kind of like integration with like STRING, with Campbell, with various like public knowledge

graphs like Prime KG and so on. There's like DrugBank, GTEx, uh we had some kind of like internal sources, so like we had internal literature and so on and internal like single-cell studies, UniProt, and so on. So So like based on this knowledge graph that we had, we wanted to create a pipeline for the target identification. so like basically to find a gene that we can target

in order to treat a certain disease. Because you're not from the life sciences, and the pipeline that we tried to do is basically that we look at the cell types, then like we queried the >> [sighs and gasps] >> uh language model saying asking it to filter to the cell types that are relevant for the given disease, and then we would query again like a knowledge graph

to get the genes in those like cell types that are either market gene and then that are either under or overexpressed. And then there was kind of like initial round of like LLM classifying these genes whether they should be included in further analysis or they're kind of like irrelevant or the LM can be as well like I'm sure and then we would more data from the knowledge

graph. So, this could be things like whether there is a direct gene disease link, whether there is indirect link. So, like of uh I I believe like we looked at up to like three hops. Are there like uh MRNA that regulates this gene positively or negatively? What pathways this gene is part of? What are kind of like the functions of this uh gene? Are there like any

protein-protein interactions? Uh and we looked as well like on a running clinical trials. And this is well kind of like mapped into the scores that we wanted to give to this like that. So, so so basically then all this data were like passed to LLM which was supposed there was like some kind of like chain of thought prompt asking to rank or the score of like one

to 10 uh like how strong this is link is, how uh good this like safety of the this like gene, uh is it drugable or like how how good is drugability? Uh based on kind of like clinical trials, you can as well kind of like explore how fierce the competition is. Uh so, like who is running uh clinical trials in the similar gene and then there was

some sort of like average. and uh then kind of like the next step was kind of like to try to establish a link with patient population. Uh so, there was basically a lot of kind of like querying and then going back to the knowledge graph and to the LLM. and and then like kind of like if you extrapolate it, what what would be the further needs of

yeah, like having Neo4j plugin. So, like basically there's a lot of need of kind of like grounding information. So, you want LLM to not hallucinate, to base the responses on something. So, like whether it's literature or something like structured. So, in a structured sense for us the integration was done on Neo4j. Uh and as well kind of like for that you do kind of like graph rack.

you can verify the answer whether it is really kind of like based on something. So, we had as well like uh a project with Fraunhofer Institute where we looked at kind of like verifying the responses from LLMs with kind of like knowledge graphs that were kind of like underlying and that were queried. Uh and then as well kind of like data source expansions and it could be

used as kind of like a genetic tool. so, yeah, like basically we built this Neo4j query tool you like and as well like open sourced it. So, like you can find it in the free marketplace and just use it. and there is as well kind of like a GitHub and so so on associated with it. Like there will be the links later. Uh so, basically it allows

authentication to your Neo4j database whether it's local, remote deployment, Aura Cloud, anything kind of like uh would work. So, you can just kind of like connect and then uh basically you can add queries and, uh, those can be parameterized. You can kind of like query across different databases. Uh, and as well, these kind of like parameters could come as, uh, output from some other, uh, node in

the pipeline, whether it is LLM or it is some kind of like code node. So, like, Dify allows as well a code node, or it could be, uh, like, coming from some other, uh, systems. And, like, what we thought is as well kind of like important is to have, uh, the switch for allowing uh, write queries. So, it is by default on false. So, like, uh, if

ever, there is a query that comes from the previous nodes that wants to write into your knowledge graph, it would not allow it unless you consciously, uh, allow it, uh, in the, uh, configuration of this like Dify tool. Uh, so, this would kind of like prevent that, yeah, like, basically, LLM does wild things to, uh, your knowledge graph, and, uh, make changes to the integrity of your

data, Yeah, so, so, so, yeah, like, the basic, and it's as well kind of like, this is done in a way that, the query has this kind of like pre-flight mode, and then, like, based on that, it kind of like flags whether it is writing query or not. So, like, before execution, we know, that we won't accept the query to execute. Uh, and, uh, yeah, like, basically,

here simple workflow, or like, sample of like, what you can do. uh, here what what we did is basically we have a starting node that yeah, like user inputs uh uh, whatever question. Uh, and then uh basically we connect it to Neo4j database where we uh, called this like DB schema visualization which would give us the uh, schema of uh the of our Neo4j database. >> [gasps]

>> Uh, and then there will be a LLM that uh we would pass the result of this query. So like to which we would pass the uh, schema. And with the schema we would as well like prompt uh this LLM which is in this case like Gemini. Uh, and Gemini was uh here used uh because of the uh quite long uh context size. So it it even

if we had like quite large graph, it would still kind of like fit our large schema of the graph. Uh, it would still kind of like fit into the uh, the model context. And then it was prompted basically to generate the Cypher query uh would try to answer the user's question using the schema. uh in in the next one next node we would kind of like call

Neo4j with this query. Uh, and in the last one we would just kind of like try to verbalize uh what came out of the uh Uh, and there is like some use case that we as well like try to do with this like clinical knowledge graph that is like open source and we try to describe it. Uh so here you have like a number of like relationships

uh centering around uh yeah like clinical findings around like some patients and their kind of uh tissues, proteins, interactions, and >> [clears throat] Yeah like like there uh as well like some challenges that we figured out that yeah like it's worth mentioning uh especially if you're working with like large language models and uh knowledge graphs uh uh that LLMs could struggle to yeah like query your uh

database in the right way but then kind of like you can do some things to uh make it better. Uh so yeah like basically uh prompts can be filled with parameters from all other nodes. So the user questions, graph schema, and so on. So uh this is basically how our prompt for this like clinical knowledge graph uh look like. So we said that based on the user

question and the Neo4j knowledge graph schema and then like you pass the schema uh write the Cypher query that would fetch the data from knowledge graph helping answer question. Make sure to capitalize the first letter of each word and blah blah blah. Uh so uh this as well kind of like requires you to know uh basically how the data is or how the nodes or the relationships

are represented in your knowledge graphs. So so uh you need some kind of like description that like, well, is it starting with a capital letter or or so? And then somehow to know how the things are phrased there. And so, basically this kind of like naming convention that you are using are important and it can be a little bit of challenge uh to describe and I see

that somebody is writing in a chat like, "Don't you use a ontology to unify the terms?" So, yeah, like one way to do that is to normalize to some sort of like IDs or some ontology either like UMLS, Mondo, or something like that. And then basically use either ID or preferred term to kind of like do that. But But it is what kind of like require you

to add additional step. So, uh here I can kind here I'm showing like the squaring ontologies with So, so we have built internally this like Linnaeus tool or I mean we didn't really build it from scratch, but there is already open source tool Linnaeus. We modified it a bit and then kind of like included our dictionaries of synonyms and then kind of like normalize it to our

internal ontologies or ontologies that we are using. And and that node is basically doing for us this kind of like entity linking to the particular IDs or to the given ontologies. And then you can kind of like pass the schema, pass these kind of like IDs, and then like based on these IDs uh generate the Cypher query that will be kind of like more reliable and kind

of like better to use or easier to use. and yeah, like basically the end result is like you can ask the questions what proteins are part of meat topic prop base pathway and it would answer like based on provided data the following uh part of this pathway and then we can Uh and and this is as well like how the interface like child interface within Difi looks

like. So, it will generate this UI for you. so, yeah, like basically for conclusion, so like we are introducing here the this like Difi plugin that's uh for basically easy building and grounding either agentic or LLM workflows. So, like you can use it as well as a tool within uh yeah, like uh Difi agent node and as well it like you can use it as kind of

like a separate and it could be uh yeah, like basically as I said like use as a part of the pipeline or as a tool in the agent and with this like retrieval and reasoning over the schema you can generate the Cypher for querying uh Neo4j database. but then like yeah, like I would recommend using some kind of like ontology and entity linking and normalizing your terms,

otherwise you may have uh quite a bit of the troubles. and it can kind of like execute both retrieval and write queries. Uh and it is open source and available for Difi, so it already has over 2,000 uh downloads and uh yeah, like people are it seems using it uh quite um happily and successfully. so basically once you have like deployed V fee, it is basically one

click to install it in your environment and uh provide it to your users. so it's very easy to install and set it up. There is this kind of like link to marketplace and then GitHub and yeah, basically it was mostly written by myself and then like there was a bunch of ideas coming from Michal Hunger about like what we should include and do which yeah, like was

at some point implemented for the most part. Uh but yeah, like we are still kind of like looking for ideas and stuff to improve. So like in case you have idea, feel free to raise an issue in GitHub uh repository. It's more than welcome and we will try to find the time to implement those and yeah, like basically that's it from uh my presentation and yeah, like

we can go for some questions if there are any like I saw in chat quite a few but uh should somebody go through it or like Branly so how do we prioritize or so? >> Yeah, we can um it looks like most of them Nikola ended up in the chat not in the Q&A. So if you want, you could um you could either stop sharing and then

it might make it easier to see those chat messages. Um and if you like yeah, most of the most of the questions are towards the end. So you might be able to Um there were some early ones just wondering, you know, how Diffy was different from another system like Flow wise and then people wondering about how to integrate with uh your enterprise system and then, you know,

some some more So basically, if you scroll back to about 1:30 uh or 30 after the hour, then you'll see a lot of the questions starting. >> Yeah. Okay, so like I can read to them and then I'll like to try to respond. So [snorts] is Diffy integrated with your enterprise system? So yeah, like we have a deployment in like one of our systems and we have

I don't know, like 100-ish Uh and we have connection to like Neo4j database that I presented as kind of like integration of like many of things. Uh also that is now a little bit changing the structure. So yeah, like there are like some things that need to be redone. Uh but yeah, like it is connected to a enterprise systems within Bayer. Uh how does it differ from

Flow wise? I don't know exactly Flow wise. Uh but yeah, like there as I said, like there are a number of these tools. Like when I was looking at them, I needed something that's kind of like easy to deploy, easy to play with, that doesn't need too much overhead with like licensing and so on. >> Uh [snorts] and that I can kind of like roll out and

collaborate with people. Uh So kind of like Deep Phe had most of those characteristics at the that time, provide a little bit at least like for my use case functionality than Any and >> eight like that I looked as kind of like a comparison. yeah, like as I said on the market there are a number of those tools. So like there's Any and there's probably this Flow

wise, there's nine knowledge supporting elements and agents. And so on and so forth. So Yeah, like this is one of the systems that you can do such things. Like there there is quite a bit of competitions. So is AlphaFold integrated with your So not with this one that I described, but we are building some sort of like co-scientist kind of like multi-agent platform that has already multi

like AlphaFold well like some of the kind of like multi-omics pipelines. This basically like when it comes to multi-omics, it basically pulls the data from this like database and some literature. Some of this data are like genomics, some are proteomics, some are so there is a bit of like more than one omics data, but like mostly it is about like relationships and so on. There is no

really raw data >> So, yeah, like, basically, the >> the way at the moment is that it just kind of like pulls the data and passes it to LLM to analyze. Uh and there is not much of kind of like uh yeah, like, calculating anything from raw omics screens or data. Uh but the data is well kind of like would be part of this like Coscientist uh

platform. Uh does save everything about text-to-cypher tool executions? I'm not completely [clears throat] understanding these questions, but yeah, like, what I described is a bit of a text-to-cypher. >> Uh or like how they built this and there is this question about ontology to unify terms. do you have a dedicated entity linking node before the step to map user terms to Mondo ID, >> [sighs] >> or do

you rely on LLMs to perform the trans- la- uh translation on the fly within the prompt? So, so, like, we do have entity linking, as I said, there is this kind of like uh Line ALS uh tool, uh which is as well kind of like a little bit modified and integrated with our dictionaries open source tool, uh but that we didn't open source because of yeah, like,

>> some reasons. In a large-scale uh data bases, uh the schema is often uh too big for a prompt. Do you see a subgraph schema extraction technique to only show the AI relevant node for a specific question? So, yes, this is a good point. uh we did that quite a bit. So, like um even if you pass LLM the full schema and he like the models such

as the Gemini 3 or Gemini 3.1 like they have like 1 million token they can swallow the schema. However, they quite often would make mistakes at least in kind of like directionality of the notes uh in the Cypher query. Uh so, therefore, yeah, like like they are as well like much more comfortable uh using like smaller kind of like subgraph uh nodes. do you find that you

showed the example uh were necessary to maintain the script normalization rules uh you mentioned? I mean, it helped, but I think like mostly it was like about uh yeah, like passing the schema and trying to kind of like um isolate subgraph that is relevant for the Uh but and for that then kind of like you can't really know which part of the graph you would use and

therefore kind of like providing the Cypher for that part of the graph would not be uh possible. And that's I believe it, and we are at time, right? >> Yeah, thank you so much. That was great. And thanks for all the participation from everybody um and the questions that you're able to answer. Incredible. Thank >> Thank you. >> [music]