NODES AI 2026 - Neurosymbolic Architecture in Production with Neo4j, GDS, Node2Vec & LLM Grounding

In this talk, João Cunha, founder and AI lead at Kipo, discusses the innovative approach of utilizing knowledge graphs to enhance collaboration between human and non-human agents in the modern workplace. He introduces the concept of a workforce graph, which redefines how work is organized by focusing on skills as the fundamental units of execution rather than individual roles. The speaker elaborates on how Kipo leverages Neo4j's graph data science algorithms to model and analyze work dynamics, enabling organizations to visualize and optimize team compositions through a system called Assembly. This system recommends team structures based on real execution data, taking into account various capabilities of human and AI agents. João also briefly touches on the significance of connectors and ontology in structuring work signals effectively.

[music] >> Okay, thanks Ryan. Hi everyone, it's great to be here. Thanks a lot for joining this session. I'm João Cunha, founder and AI lead at Kipo. And I want to start navigating in this graph that I built to help us in the presentation today start to talk about what is Kipo and what we do in Kipo. Uh cuz I think it helps frame everything we will

be discussing today. Well, in Kipo we are building AI systems powered by knowledge graphs that help organizations understand how work really happens nowadays, especially as work becomes distributed between humans and agents. And my work here focus on modeling these systems and exploring how graphs can capture this new kind of execution and how they enable more integrated collaboration between human and non-human. And this is exactly where Neo4j

comes in. We are part of the Neo4j startup partner program and as we will see today, Neo4j is an essential part of our architecture, our product architecture. well, before we dive in, I also want to share that we will soon release together with Neo4j a case study covering many of the ideas I will present today based on a real implementation at Creditas. Creditas is a leading Brazilian

fintech. So, if you are interested in what we are discussing today, you can follow me on LinkedIn because we will be sharing more about case study very soon. So, if you want to connect with me, uh I put a QR code here. You can scan is this um connect with me in the LinkedIn. So, let's navigate in our graph to map a overview of our talk today.

First, I will briefly share our view about the shift that emerges and work starts to be distributed between humans and non-humans. Then, I will show how we addressing this problem using knowledge graphs, more specifically our concept of workforce graph. I will present this concept. It's a concept by Keepon. And after that, I will go deeper into the pipeline itself. Uh will be the more technical part of

presentation. And I will explore how we use Neo4j graph data science algorithms to do that. Finally, if you we have time, I will close with a short demo of one of our features that brings many of these ideas together. Uh we call this feature assembly. And assembly is a system that recommends team is teams compositions, bring together the graph, the pipeline, and the orchestration of humans and

agents, okay? So, as we only have about 30 minutes, let's go to the good parts. So, let's back to navigate in your graph again. Whoops. To understand what is the kind of question that we are trying to answer here in Keepon. It's a simple but at the same time very complex question. it's about how do human and non-human agents can collaborate. Because up to now, work has

been organized around the person, the person as the basic unit. As you can see, roles, org charts, performance management, hiring, everything assumes that work is is executed primarily by individuals. But, AI agents break this assumption. We are no longer performed only by people. Work in general are no longer performed by only by people. And once this happens, we need to change how we organize the work because

simple simple roles, job titles, org charts, this kind of stuff aren't enough anymore. And we need a new unit to understand work. One that can connect people and agents through a common language that allows them to interact. But, we have a problem. Uh, let's let's look for our problem here. Um, because the workforce solutions were never designed to deal with this new reality. They don't really understand

how non-human agents integrate into work or how to model collaboration between humans and AI. The non-human agent performs real work. It contributes to outcomes, collaborates with people, but that work is invisible to the systems. So, we have a thesis for approach this question. Uh, we are develop developing this thesis for the last 2 years. And in our thesis, skills are a strong answer to this problem. We've

been thinking about skills as the minimal units of execution regardless of who or what performs it. This gives us a common language to redesign work around execution itself rather than around who performs the task. Because roles change, people move, agents evolve, but the capability to perform a task remains stable as a concept. uh, skills is also observable. It can be inferred from work signals, outcomes, contexts. Um,

another important characteristic of skills at is that they are composable. Work is not done by a single skill, but by a combination of skills interacting. So, if you want to understand work in this new structure, you need to this kind of unit that is stable, observable, and composable. And for us, this unit is a skill. And we manage this uh, kind of approach I'm looking this at

the the graph. This concept, uh, proprietary concept for Keap on. The workforce graph that is the foundation of our system. Because once you try to represent a skill in context, connect to work outcomes, agents, you are no longer dealing with isolated attributes. We are dealing with relationships. And this type of structure doesn't fit well in tables. Anyone who has worked with relational database here knows what I'm

talking about. Graphs are the natural fit for resolve this kind of Queries that are extremely hard in relational models become very simple with a graph. For example, if you want to identify single points of failure, if you want to find breeds between skills clusters, if you want to project project skills gaps for future other projects, for example. this kind of stuff is very hard with the relational

models, but it's very simple using graphs. diving in the context context of your workforce graph now. Oops. Yeah, let's look how it's work. At a high level, the workforce graph connects any important data to understand and orchestrate the work. So, instead of saying, for example, this person has this skill, we model things like this person applied a given skill in a specific project in collaboration with other

agents producing a certain outcome at a specific point of time. It's a very different approach, yeah. >> [snorts] >> So, you start to see patterns like how capabilities develop across different contexts, which agents improve or replace in certain human capabilities. And because everything evolves over time, the graph isn't static. It's updates in real time as new work happens. And I want to uh I I think that

I would don't have time to answer the questions, but uh uh I don't know. Someone ask about uh how we present these concepts. And I want to talk about do two important concepts for us. Connectors and ontology. So, let's look for connectors in our Ontology. Yeah. Connect Connectors is a very important concept cuz uh it's where what is what allows uh to reflect It's what allows the

graph to reflect the real work in in real time time where the work real happens. Uh with connectors, we can connect the graph to the sources where work actually happens like project management tools, GitHub, Slack, shared drives, traditional HR systems, and any other tool where execution signals are generated. Instead of asking people to manually declare skills, the graph observes signals from real execution. For example, commits, tickets,

reviews, feedbacks, deliveries, all of these uh and all of these stuffs become evidence. ingesting data is not enough. And this is where ontology becomes critical. We don't have time to dive in in this topic, but it's a very interesting topic. Uh cuz we need to structure those signals into a consistent model that allows to connect them in a coherent way. When we query the graph, the way

information is connected connected, and this is the the the ontology, this is what will impact the performance of the inference that we can extract from the graph. And at Keap, we use a proprietary ontology ontology inspired by RDF principles. We follow uh subject predicate and object structure, which is a classic structure for ontologies. And in practice, these simple models works really very well for us. Another important

design choice we made was to minimize the numbers of relations types that we use in the graph. These allows to keep the model flexible, extensible, and easier to reason about. So now I will show [snorts] uh the real use case of as assembly. So let's look for assembly now. To exemplifies everything we've described so far. Assembly is the flow used to recommend custom team compositions based on

a high-level description of a problem. So the goal is to take an input that the user brings, something like a business need and business need, uh project idea, or an initiative, or whatever, and translate that into a structure understand of work that needs to be done. The final output in this feature is a recommendation of a hybrid team combining human and agents along with the rationality behind

it. It's clear which skills are needed, where they come from, and how they connect to the work. At the most most basic level, this means answering questions like who has the required skills for this job for this team, where those skills were actually demonstrated, and which parts of the work could benefit benefit from hybrid execution with agents. But if we go further, the questions become more complex.

We need to try to understand who works well with home, which parts of the process can be fully automated, if are there hidden gems in the graph, yeah, and who could replace home if someone is not available. More complex questions that we can find some answer if we use this pipeline that I will show now. This will be the most technical part of the presentation, so I

will describe the pipeline that we use in assembly to find this this answers, okay? Let's go to pipeline, and then if you have time, we'll try to do a demo of this feature. What we are doing here is transforming an unstructured input in a ground into a grounded subgraph, and then running graph data science algorithms on top of it to produce a ranked and explainable recommendation. First,

what we do is everything is start with the interaction of the user. So, the user talks with a voice agents. This process use a voice agents. So, it's very natural. The user talks with these agents about his projects, his or initiatives or we are trying what the user are trying to to build. And we use LLM to generate a first hypothesis about the best conditions to do

this work and compose compose this team. At this stage, we have what we have until now is a semantic representation of the inputs. We are trying to understand what are the jobs to be done, which skills are likely required, and what kind of context we are dealing with. But this is too ungrounded in the real world. This is just a good hypothesis made from LLMs, okay? the

second step is to try to connect this this hypothesis with the real work, with the data that we have in the graph and that represent the real work. And we do this through a combinations of strategies. First, we use lexical matching. Direct matches and full text research to find exact exactly or close reference between, for example, skills. Then use vector similarities to capture semantic matches when the

wording is different but the meaning is the same. And finally, we validate this magic structurally checking how well they connect to the rest of the graph. So, at the end of this step, we don't create new entities in the graph. We resolve everything against the existing graph. Yeah? Skills are matched to existing skills nodes. Contexts are grounded through the connections to projects, domains, and teams. And signals

are linked to actual execution and already present in the graph. So, what we're trying to do here is ground the first hypothesis into the real work that are represented in the graph. This step is critical because it ensures that everything we use from this point forward is anchored uh in the real organization data. So, the next step is create a subgraph uh projection. Cuz we are if

we are if we we are trying to work with the entire graph, we you have so much data that we can find the right connections and this could be very expensive. So, we built a subgraph that includes candidate skills, related projects, and contexts, connect profiles and agents, and relevant execution signals. So, this subgraph becomes the computation computation computation computational space where all downstream analysis happens. And this

is an important idea. We are not running algorithms on the whole graph. We are computing on a context-specific projection of it to be more precisely. So, we go to the next step where we in fact try to find the candidates for this uh this team this ideal team. And to do that, we combine three different approach. We use the vector similarity to capture semantic proximity, matching skills

in profiles that are conceptual similar. We expand the graphic using key hope K uh to capture structural proximity with who can be close uh of other person not in a semantic way but in a structural way. And we use node similarity to identify profiles that share similar neighborhoods, people who have work worked on similar uh projects or have similar skills, for example. In some cases, we can

also use embedding techniques like fast RP to combine these both approach, but we are now testing this kind of process. The results of this step is a candidate set that is semantically relevant, structurally grounded, and context aware. Once we have this candidate set, the problem shift. Now, it's about ranking this uh this group. And this is where GDS become more central for us. We compute multiple signals

over the sub graph. We can use page rank to measure influence. We can use uh similarity uh similarity metrics like Jaccard to measure overlap between required skills and observed capabilities. We can use Louvain to understand how Louvain to understand how skills and collaborators clusters together in this context Each of these algorithms captures a different dimension of relevance. Can be similarity, importance, connectivity. we are trying out to

explain the steps that we are uh passed through to get these conclusions. So this is a uh a benefit of the graph cuz we can explain exactly what what what was the uh the steps that we need to go through to um get our informations or get the uh perfect match to the composition of this So finally we uh work with uh pipeline to scoring uh the

suggestions and finally compo- We combine all the signness that we compute until now and use some kind of algorithms to optimize uh this process like complementary skill convergence, structural diversity, and collaboration compa- compatibility. Finally, we add one more layer to try to understand how agents can compose this team together. Yeah? So, until now we had just persons in this team and now we can we we we

will understand how we find agents that can augmented some capabilities of some person or or or in other scenarios can automate a process whole process. Okay? So, we already have 5 minutes and I will try to do a demo of this uh Uh the demo that I will show is a demo production. So, we use all these spaces, these algorithms and this uh process that I show

you to to get the the final match of the teams, okay? So, let's try. I think you are already seeing this is screen. Everybody uh seeing the the the the the screen of the feature? Okay. No. So, I will start to conversate with this agent and it will try to help me uh organize my ideas to understand what I want to do. So, let's start. It only

It only take about 2 minutes to get started. Just tell me in your own words what you're trying to build. Now, we are trying to build here in Keepon knowledge graph that can represent the real data of the work. That sounds like a very interesting and valuable initiative. To help me understand it better, could you tell me what problem or opportunity this knowledge graph aims to address

for Keepon? We are trying here to build a system that suggests skills in a more effective effective way. and we understand that graphs can help us to connect this data to find the right skill for the right person. That's a clear objective. So, the core idea is to use a knowledge graph to improve skill suggestions by connecting data more effectively. To achieve this, what are the main

work streams or phases you envision for building this knowledge graph and integrating it into a skill suggestion system? I think that you got it, the idea. So, I will pass through the next step cuz we don't have time. But now, we process all the conversation and find the main data that will help us to build this team. So, for example, we describe here the initiative, the objective

the the the objectives, the jobs to be done, we list the jobs to be done. What is the kind of skills that we need to to address these jobs to be done. If you are have relevant projects or relevant teams, people that are part of relevant projects and teams to help our intelligence to build this team. So, we are processing the data now through this pipeline that

I showed. And the result is that suggestions for the composition of this team. For instance, for example, Hiko. Hiko is the co-founder of Keepon that lead with a more technical things and specialist in ontology, too. as you see, we understand why what Hiko was suggested because Hiko uh are participated in a relevant projects. Hiko have some important we suggest yet agents and skills that can combine with

human knowledge to compose this team. Okay? So, I don't know >> That's a very comprehensive overview of So, we have more 1 minute and I don't know if someone have some Let me see in the queue. >> I understand you're explaining your internal Could you share a bit more about how you create the ontology? We base our the process to create the ontology in RDF. But we

are trying a lot of systems and process that already exist to create ontology, but at least an ontology need to work for we are trying to resolve, yeah? The context that we are trying to to lead with. So, we create our own ontology cuz we understand that neither ontology of already existed represent the it's specifically for represent the work the the workforce. So, if you are leading

with a very specific context, I suggest that you create your So, I think that we don't have more I can you can connect with me in the LinkedIn, so we can um extend this conversation in in other uh place. You can we can do calls or or ever you want, okay? >> [music]