 Hello, everybody. Good morning, good evening, good afternoon, and thank you for joining this Neo4j live. Two weeks after Nodes, so I hope you all recovered from 24 hours of Neo4j presentation on the beginning of November. But now we're back with our sort of regular schedule with live streams on the channel. So happy to have you all back here today we had a funny conversation already in chat earlier while the video was running about graph aid which i need to check out somebody miko posted that in chat so i need to check that out so people having a good time here saying hello from from pune from paris from new york from Manchester, from Lima, from India, on LinkedIn. So great to see you all join today. And yeah, welcome, everybody. I'm happy to have Johan Salami join me today on hybrid AGI, graph-powered self-programmable AI. So that's going to be our topic for the session today. Hi, Johan. How is it going? How are you doing today? Hello. So hello, everybody. I'm doing great. So to present myself, I'm a PhD in AI and robotics. I've been working before in humanoid robotics and social robotics, the LLM crazy started, I started to implement a system based on my knowledge on making a robotic system. So I will share my screen just a bit. Cool. OK. Let me see, when I get your screen, then I can switch over here. Here it comes. Right. That works. That works? Yep. OK. right that works that works yep okay so um the company that we started is called uh synalinks and maybe you maybe you i'm sorry for interrupting maybe you wanna get rid of this little box that says you're sharing your screen maybe uh yeah or you can click on a little uh that yes exactly okay and then it goes away thank you cool so uh when uh all the lm crazy craziness started um we we started a company that is called synonyx and the main idea behind it was uh to um to promote a neural symbolic system. So here is our team. And when we started the company, our idea was really to push neural symbolic systems, to push neural symbolic systems, because in robotics, we use these kinds of systems a lot. So here is some of my previous work that I've done with human robots as i said previously and it was about creating a graph structure for explaining the scene so you have a different kind of objects you have maybe people in the scene and he wants to describe the scene as a graph and that graph goes into an ontology system. And based on that, the robot is able to interact with the people and ground information and entity in the real world. So actually, my work was about many different things, but mostly about combining the robot perceptions and simulation engine to make the robot perceptions and simulation engine to make the robot able to infer the position of the objects, even when they are occluded by the camera. And also about theory of mind. So theory of mind in robotics, we use a lot the graphs but we don't only infer a graph for the robot but we also infer a graph for the humans and the way we construct it is that we take we have the graph from the robot and we filter some part of the graph and how we do that we do that using what we call visual perspective taking so we take a picture from the point of view of the the user and from that we are able to compute the visibility of the objects and based on that we can filter the main knowledge graph and create other knowledge graph for the the people that the robot is interacting with um so when we started uh hybrid agi the the goal was really to um so to give you a bit of history the system is now one year one year old and we started at the very beginning of the agents, the LLM-based agents, and we had kind of a frustration about agents. They were going through infinite loops. Sometimes the, well, the TLDR is that they were not reliable. And so the idea behind Hybrid HGA is to use concepts from computer science but also from a cognitive science to create a system that is able to work reliably and so we do that by controlling the the agent system from end to end using a graph so there is no react agents in our system I mean you can implement a react algorithms I would say but that's not the point of the system the system is really made to be able to program more complex agents than the React one, that didn't give us really reliable results. So we do that by managing the knowledge using graph databases, and we picked the Cypher language. We picked the Cypher language because it's really easy to learn and easy to read for humans so our hypothesis was that if we have a language that is easy to to learn for for humans it could be easier to to learn for LLMs because as LLMs are really a proxy of our of natural language. And if we have a language that incorporates a lot of natural language, we could create an intermediate language between the goal of the user and the execution of the system. So basically, it's really a memory-centric system. We have different kinds of memory, and we can use them all at once, if we want in the same agent. We are not limited by the number of tools that the agents can use, simply because the system doesn't really choose the tool that it have to apply because they are specified in the program. So the way that it works is that each time it needs a program, the prompt is constructed in a way that it gives only the information that it needs for this particular tool. And so we are able to accommodate an infinite number of tools as long as you describe the whole logic into a graph. So there is different memory that we implemented. So the program memory is actually its dependency graph. We see this memory here. And it's a dependency graph why a dependency graph because in our system we decided to really create a kind of a software written in cipher that was the the innovation behind our system so you can describe the whole software and as a software you start with a main program you start with the main program. So you have the main program, which is the entry point of the agent, and it will interpret the program. So the interpreter is very like a Python interpreter. So in Python, for example, an interpreter is going to interpret line by line and going to execute the the given execution in our system the interpreter will navigate inside the the graph and will execute node by node the graph programs and that's really key to to understand i would say like it's really if you come from computer science, you already know what is an interpreter. You already know the differences between a compiled language and an interpreter. For example, our system is very different from Langraph, for example, because Langraph uses finite state machines. The thing with finite state machines is that you define you define them and then they are fixed they are static okay and there is no really a way to modify this uh this uh this state machine on the fly the only way to do that is to create an intermediate language that the the llm can uh read and modify so here it's what we've done with the Cypher language. We have also the memory, the document memory, which is now a classic in React system. I won't talk too much about that. It's really a classic now. The fact memory, so if you're here in this Neo4j stream, I think you already know what is a GraphRag. And the fact memory is the system that store the triplet. So the triplet is the subject, verb, object. And it's basically your determinist fact that you work with. And we have, finally, the trace memory. So the trace memory is a bit special. It's kind of the episodic memory of the system. But we didn't want to bring too much concepts from cognitive science. So the idea was to really use the concept from cognitive science, but ground every concept into computer science because it's easier for people with programming knowledge to understand it and it also it's avoid many pitfalls that people have when they try to mimic too much the human cognitive processes. So, the trace memory, what it does is, we basically record each action that the program was performing. So, actually, what you have is that in this memory, you have the trace of the program that's already executed. As I said, each memory can be used multiple times and all are at once in the same agents because they have special tools that we can use within the agents to access them to read-write. So the agents have read-write access to most of the memory system. About the repository, so we currently have started to get quite famous, and we are really happy about that. So... Well, it's good. Great. Yeah, today we had a really... I would say, like some stars are shining more than others. And today we had one star from François Cholet, which is the creator of Keras and the RKGI benchmark. And actually, we used some of his work with Keras to come up with an abstraction that was easy for people to understand and to leverage. So actually that was really quite something for us. And so yeah, so here is the link, see if you want to go and check and have a start to the repository uh next i put the link to uh to the github reports and chat okay thank you thanks uh so uh now uh we are going to drive into um into some notebooks so i will show you uh really uh i would say basic notebooks so it will be a graph rag, so you can get a sense of how to use the library. And then we are going to switch to a more experimental, I would say, feature, which is a copilot for our system. Cool. Okay. our system. Cool. OK. Oh, and if anybody's watching and have any questions, any comments, then please feel free to use chat and let us know. There was already a question on your slides, if they would be available afterwards. So maybe we can share them with the audience later. But the recording, definitely, this will all be recorded. And you can watch it afterwards, anytime, in our YouTube channel. Yeah. So Knowledge Graph Rags are nowadays, I would say, common. But when we started IBuild AGI for, I don't know the reason, last year, nobody was giving attention to graphs because everybody was focused on vector-only rags and react agents. And coming from robotics, that was really something weird for us because graphs are really powerful and they can model almost anything so actually they are really useful in many cases and many applications so here in this notebook we are going to build a graph that is about so a movie basically a movie accommodation system it's kind of a toy example but it's show well the how the system works so we have here our input data and we are going to build the facts that we are going to need in our system. So here it is. We have the facts that we are going to use. So basically, it's just the fact is a triplet that we have. So here we are. So here we just like create the facts for the fact memory. So the fact, as I said, are actually triplets. And then create a graph from them. As you can see, the nodes are not connected with each other, which is a classic problem in a graph database. It means that there is duplicate nodes. And actually, we can create a pipeline. So in iBuild AGI, there is a really handy way to create a pipeline for data processing. And it really looks like Keras or Hugging Face library. In fact, we took inspiration from them. So it's actually quite normal that the system looks like Keras or Aguinface. So we can stack modules with each other, and we can create a data processing pipeline. So here in this pipeline, we did duplicate the entities, and we embed the entities and the facts. And by doing that, we can create a knowledge graph. And based on this knowledge graph, we can infer some things. And in this case, we can recommend movies for the users. So here is the part that in iBrill AGI, so the thing is we create a graph program. And this graph program is actually done in Cypher, but we created a way to create them using Pythons because when we started our system one year ago, the only thing that we did is that we had the software written in Cypher. And this many people complained about because they didn't know Cypher or it was too complicated for them. So we took inspiration from Keras, and we created an intermediary language on top of the DSL to be able to create the programs in Python. So the program can have four different nodes. It can have control nodes, which are used for the start and the end of the program. It can have action nodes, which describe the use of the tool for the agents. We can have decision nodes. So the decision nodes are used for the system to branch over the graph based on a question that the developer asks for the system. And actually, the question, the good way to see that is not about really asking questions to an LLM, because the LLMs are quite limited and they really cannot say that they understand the prompt or whatever. But actually, they are quite good to do some one-shot classification in a one-shot setting. So you have to see the decision of the system as a classification task. So the goal of the decision is to classify the context and based on that classification, the system will branch over the graph to execute the action of the branch. So, and also the last node that is possible to have in our program are the program nodes. So the program nodes are actually like a sub-program in a programming language. So the interpreter have a stack, like in any, I would say, proper interpreter, and you can call other subprograms. And by doing so, you can call a subprogram, a subroutine, and you can go back to when the routine ends, you can go back to the program that called that routine. So it really looks like a programming language, in fact, for LLMs. you can go back to the program that's called the truth scene. So it really looks like a programming language, in fact, for LLMs. And so you create your program. And at the end, what you got is a program that is expressed in Cypher. And this program, due to the fact that this program is really, use a lot of natural language, the LLM is able to understand it quite easily. And it says here tool FactSearch, because Paul also has the question in chat, is that a tool you built yourself, or is that some, what is fact search? So the fact search is when you search for facts in the fact memory. Ah, I see, okay, the one you showed earlier in the slides. Yeah. Yeah, exactly, here. So actually it's going to look for triplets inside the knowledge graph. Okay, I see. We have a way to... What is really different from our system from a land graph is that because we have... I can also show you this notebook. Because the... I'm sorry, here... Okay. So this is another notebook, and it shows... Because actually the programs are embeddable. And what it means is, it means that you can have many subroutines. Like imagine you have millions of graphs and each graph is actually a skill for the agents. And so it's impossible to have in the main program, to create a program to have the good condition to call the right program, etc. Because at some point, if you have a growing library of programs or you have an agent that is really general and that have a lot of different skills, you need a way to search for the right skill to apply. And this can be done because we use the description. So here is the description of the program. We use the description of all the sub-routines to create an embedding for the program. And by doing so, the system is able to search inside its own program library and is able to search inside its own program library and is able to dynamically call a program when needed. So here we create a different program. So for example, this is the one that looks like a rag, basically, and we have another one that is about telling a joke, for example. So we create a pipeline to embed each programs. So we embed the graph programs that we created earlier. And based on that, we create a dependency graph. OK? So here we have the dependency graph. In this example, it's quite simple, but there is no limit on the complexity of the dependency graph, obviously. And what we noticed when we were experimenting with self-programming agents, because remember, the goal of IBDGI is to have a system that is able to program itself and to evolve. And I would say, like, learn new skills on the go. That's really the main goal of the system. And this, when we started to experiment with that, we noticed that sometimes the LLM wanted to modify its own main program, which is, if you think about it, it's quite not good. And we came up with a system to be able to protect some program. So in programming language, we have some scope. For example, in Golang, for example, you have... Oh, no, no, no, no, no. In C++, you have the scope of the... Some program have a scope, so you can be protected, etc. And here we have made a kind of scope for the graph programs by only allowing the system to call programs that were disjoint from the main program. Because when you create, for example, when you create, I would say, a learning program, so you will create a main program that says, okay, look for a skill to perform the user query. If that skill is not present in the database, so we are going to learn a new skill. So we are going to plan, create a plan, convert this plan into a graph program, okay? And we are going to save this into memory. And this is basically a learning algorithm that you can add. And your learning algorithm is in your main program. But you don't want the system, the AI system, to be able to modify this learning algorithm because it will mess up with all your architecture. So we have to come up with a way to protect some of these programs. And also, it's really interesting in the sense that we can implement some guardAR writes in the system by, for example, if you usually, if you want to, I don't advise to have only this GUAR write for a system based on LLM, because there is a lot of problems that can arise, like prompt injection, etc. But it's useful to have, like, I would say, a first decision when you receive a query from the user that will be like checking that the user query is about this topic, the topic of the system, OK? Or check that what the user asks is not against some ethical rules or some safety guards. And what you do is instead of calling the subroutine that's going to execute the user query, you shunt your system. So this is really useful to have in a system, and that's why we implemented this safety mechanism to the program. So for example, here... We have the input query of the user. It's called the Fulfill Objective subroutines. And this subroutine is going to find into the memory system, the program memory, other programs to call. Okay. It's going to search them. And then we are going to ask, are they relevant or not, etc. And if they are relevant, we are going to use a tool that is called CallGraphProgram that, based on the name of the program, will actually call dynamically a program. So basically here it's what happens. So the system is calling the detailjoke program that was searched previously here, and it's going to execute it. So it's able to execute the program. So here is the execution of the program. And then it ends the execution of the program and ends the main program. Are you guiding this a little bit by this question from Don in chat? Are you using weighted path concepts to help the system make decisions? Or how is your, are you helping the LLM a little bit or giving a little bit of a structure for it to come up? Yeah. To help the LLM to make the right decision, we actually use a chain of thought concept. So if we look at... prompting... here. I have a notebook that explains the underlying prompt that we use exactly. So when we are making a decision, decision-making steps. So here we have a program that has a decision-making steps. And we create the program as usual. And when the system is actually performing the query, we have this reasoning. And this reasoning actually comes from the SPI, because our system is built on top of the SPI. And the SPI have a way to easily create some chain of thought resonance. And so the goal is to, for example, in this case, it's going to create reasoning steps, I would say. Reasoning, it's not real reasoning, but you know what I mean. And it's going to help the system to perform better pattern matching by letting it think before answering. And by doing that, the system is able to have a pretty good decision-making system. About the decisions, there are a few ways to enhance them. One way is to actually ask something that is really grounded in the information that the system has in the prompt. Because when you ask LLM about a question ask something that is really grounded in the information that the system has in the prompt. Because when you ask the LLM about a question that requires its internal knowledge, there is a higher chance that it's going to miss the point. When you ask the system a question about something it has in its context, you can see it as like a regex, for example. Let's say you have a question that is going to be... So I retrieve some documents based on the similarity metric, so like a reg, and you're going to ask, is that relevant? Is your context relevant? Is the list that you fetched empty? If it's empty, you will output just the empty word. If it's relevant, you output relevant. And if it's not relevant, you output, let's say, irrelevant or iranus or something like that. I noticed that when prompting LLMs to actually make decisions, the more distance the classification word that you use in your decision, the more distance they are from each other in the embedding space, the better. There is less ambiguity for the LLM to answer. And if, for example, you have relevant and irrelevant, because the tokens are made of the same, the words are made of most of the same tokens, there could be an ambiguity in the decision, in the decision, and it can make the system choose the wrong path. So actually, the wording of your decision is really important. And I think it's the same problem in many, many system. The more distance the words for your decision, the more distance they have with each other in the embedding space, the less tokens they have in common, the better will be the output. Yep. So here about the decision system. Shit, my computer is completely dead. I wanted to show you also the copilot, but unfortunately, I don't have it here. So I can, if you have other, if there is other questions, I can ask and I will, anyway, I will push the notebooks about the Copilot tonight so people will be able to check it and to run it. JOHN MUELLER- OK. Is there any question about, for example, here is a notebook about creating custom tools. So basically what we do is we take the description of the function to create a tool. So it's really kind of basic, but it allows people to add new tools to the system to satisfy their use case. So here is the graph that we use. And the system is able to, for example, to fetch the price of a cryptocurrency and using the tool that we created, so the custom tool. I see. So I don't see any other questions, but maybe we give it a few moments. But what I wanted to know is maybe we can explain or you can explain what you wanted to know is maybe we can explain, or you can explain, what you wanted to show. I mean, unfortunately, we cannot show it now on screen, but we can at least maybe talk a little bit about it, and you can say what the general concept or the idea is and what it brings to the table that helps people work with Neo4j and hybrid AGI. Yeah, yeah, sure. So the Copilot, for example, the Copilot is really about creating. So as you see, like when we create a graph program in Python, okay, but at the end what you got is a programming cipher, okay. So the copilot is actually a simple program that is used to ask the LLM to create this program, okay. And that's where the usefulness of having to choose a cipher for the system helps. Because the system is quite like a large language model I've been trained on many programming language and many languages. And they are able to put a cipher program. And basically what for the system, we ask the system, for example, let's say you start with write a poem, okay? So the first step will be to convert this instruction, write a poem, into a plan. So this plan could be like a first step. I fetch some documents in memory to see if there is a poem about the given topic in memory. And then I write a draft. And after writing this draft, I ask the user if they're happy about the draft. And then I finish the, I give the last, the last, I give the, write the last version of the poem, and then I finish the program, okay? So the first step will be to like take this query from the user, convert it into a kind of natural language plan, which is going to be like a bullet list. And from this list, then you have a prompt that asks the LLM to format this plan into a program. So you give the LLM some examples on how it has to format the plan. And because each step is actually involving a lot of natural language and is just like changing the format. It doesn't have, the system doesn't have to learn or to, because actually LLM have not been trained on our DSL. Okay. So they don't know the exact DSL. But if we give them the instruction to create it, like for example, we say, okay, for each action, you have to create a node that looks like this, that have this IDE, that have a purpose field, a tool field, a prompt field, what you have to do, put in the prompt, etc. Given that in the previous step, you have given already all information, or you have created an intermediary step that allows the system to populate these steps, the system is able to actually create this program, this cipher program. And so the whole idea, and that's why we created an interpreter and not a static language. Because the goal at the end is to have... Let's say you have an agent, but you cannot program it for all the tasks that it's going to perform, okay? And if we want to have a system that is general enough, we have to come up with a way to create new skills and new tasks on the go. And the way to do that is to actually use this Cipher intermediate language. And so the system is actually able to create on the go this representation, this Cypher program, for example, is able to create something similar and to save it into memory. So then if you ask again the system about the same task, it will be able to dynamically call the program that it just created. That's why I League AI has these features. So actually the dynamic call is needed if you want to have a program that is able to learn new tasks on the go. Okay? And so we have to... It's a way because when you start your main program, let's say you start your main program, you just have your learning algorithms that say, okay, look for the programs in memory. If there is no program for the specific task, call create program, the subroutine create program, and then this subroutine create program is going to have some programs to actually come up with the actual cipher program and save it into memory. The library, when we look for known programs to solve particular problems, okay, at the beginning, the program memory will be almost empty. The only program that will be inside the memory will be your main program, and the program that your main program is called, using the program nodes. But as you use it, the library of tasks that the system will have will grow. It will grow over time. So actually, it was really important for us to have a way to embed the tasks, the programs, and to search for them in a dynamic way in order to be able to, when the library of program is growing in real time, on the go, to have a way to fetch the correct one and execute it. So that's why we have these tools like to search for known programs inside memory and to call them dynamically. And of course, to add it into memory to save it. OK, cool. Yeah, that's really cool. It's a shame we cannot see it now in action, but maybe, I don't know, if you can record a video at some point and maybe add it to your to your github page or something where then people can can follow up and and see how it how it looks like on the other side um the only other question i see here is from andrea that would bring us to the end anyway from andrea and they ask have you evaluated the models used in your repo and not used with text to Cypher? What are your results? I don't know if you played with that. So text to Cypher is actually very different from what we do. Text to Cypher is used, like traditionally, Cypher is used to carry a knowledge graph. So if you look at text to Cypher, for example, I don't know if you already looked at this data set, but it's about carrying the knowledge graph. Here, we use what the goal of the system is to create a DSL based on Cypher, but it's not the graph program is not a traditional query, I would say, that you use in Cypher. And it's really different. So here in this system, the Cypher language is used as a proxy, is used as a way to describe a graph in natural language, but it's not only about retrieving facts in a knowledge graph, which is two different things. So actually, it's very different from text to cipher. JOHN MUELLER OK, good. And maybe just to close it down, because you talked a little bit about this earlier, from large language models to local small language models to to local small uh language models is is what what are your experiences here and uh what uh why have you chosen you know the the tools you are working with now so first uh there is a different um i would say justification for for choice and design First, I've been working on AI for, I would say, a very long time. And the trend that we see on AI system is that when they always get better and smaller, okay? It's something that we... I've been working with computer visions. And when we started computer using deep learning for computer visions, the system was quite big and very quickly they reduced in size and they they got almost real time frame rates and they get better and better and more importantly smaller so that's that's actually a global trend in ml uh that's as soon as uh there is a lot of money invested in uh in machine learning the the size of the the models is reducing reducing and the capability is augmenting so that that's the first justification. That's why from the start we thought about if you have a system that requires multiple steps, the only way to reduce the cost of running the system is to actually perform computation on the client side. So actually on the computer users. And this can only be done with local LLMs. For example, let's say you have a system for predictions. Having the LLMs on the client is not really problematic. What is important is to have the graph database on the client is not really problematic. What is important is to have the graph database on the cloud, okay? So all your systems are going to be connected to Neo4j, to whatever the graph database you are using, okay? And so actually, when you are using a neural symbolic system, the importance of the system shifts from the normal network to the data to the structured data so the the the graph database is really more important than the large language model the large language model is used just as a execution engine but the the the whole value is in the graph database that's where you store your programs your programs or plans that's where you store your data your business data etc so actually you when you're creating a a program that is for for example for you have a team of workers and they want to have a graph right the thing that is going to be important to have on the cloud is the graph, not actually the LLM that you can run locally. And that way, you can actually reduce a lot the cost of running your systems. JOHN MUELLER- Yeah, that's great. That's a good point, a very insightful view on this. And yeah, it's really really good good that you that you you made that um connection here between using using your own data is is is what what makes the difference really and your data is can be should be in your in your graph database and then from there you can you can use any uh any other i i think uh you mentioned it when when all this uh craziness about llm started not everybody was uh looking into graph database but i think that a lot of professionals were actually looking into that because that's that was the way that they make the data-intensive systems are all based on the graph database. And graph database are really key for that. For example, I have some story when we started, for example, I believe HGI, we started with this graph. And they dropped the support for their graph database. And for me, I was really surprised as someone from robotics. And I think many professionals were really also very surprised by that decision. And so they wanted to stick on a vector-only database. And for us, it was really something weird because graph database are really like the missing points, the missing link, I would say, in the architecture. They give the possibility to have insightful analysis, but also you can use them in many ways. Like for instance, in Ibuild AGI, we use a graph database in many ways that are not traditional. But it's because the graphs can describe almost everything, they can model almost everything. So you can actually use that to model many kind of algorithms, many kind of models, and not necessarily knowledge graphs, traditional knowledge graphs. Yeah. Cool. Yeah, thank you very much. That's right. I think that was a good end point to our session. Yeah, like I said, links to the repository are in the video description on YouTube. Yes, I will check my computer. I hope it's doing fine. It's definitely out of our control this time. Yeah, no worries. The more fact, We talked about that. It's so... It happens. Don't worry about it. We can pick it up again at some point. So like I said earlier, next stream is tomorrow. We're going meta. But don't forget about the Neo4j Developer Survey, so that's currently running. So, And I will publish the notebook about the copilot on my LinkedIn, so. Okay, cool. And you can share that with me maybe, then I can add it also to the video description. Obviously, I will share it with you, and if people want to follow us on LinkedIn, I will be happy to connect with them. Cool. Yeah. And I think with that, we're at the end of today's episode. Thank you very much, Johan. Thank you everybody for watching. Like Johan said, reach out to him and the team if you want to know more about Hybrid AGI. Check out the GitHub repo, give it a star, and play around with it some more. And let us know what you thought of this episode by giving it a thumbs and and you know play around with it some more and yeah if let us know what you what you thought of this episode by giving it a thumbs up that would be obviously great and yeah with that have a good rest of the day and yeah thank you thanks for new 4g for having invited me and thank you everybody for uh for participating for participating in the in the chat so you
Neo4j Live: HybridAGI – Graph-Powered, Self-Programmable AI
Discover HybridAGI, a groundbreaking Cypher-based neuro-symbolic AGI designed to make AI adaptable, reliable, and knowledge-driven. With the power of graph technology, HybridAGI goes beyond traditional Agent systems by using a graph interpreter that dynamically reads, writes, and executes graph-based data, enabling self-programming and on-the-fly adaptation. 
Tune in to explore how HybridAGI combines graph and LLM capabilities, allowing users to create secure, memory-centric AI applications with deterministic behavior and extensive customization through Cypher. 

HybridAGI: https://github.com/SynaLinks/HybridAGI
Notebook:  https://github.com/SynaLinks/HybridAGI/blob/main/notebooks/graph_programs_copilot.ipynb
Guest: Yoan Sallami

Knowledge Graph Builder https://dev.neo4j.com/KGBuilder

0:01 - Welcome & Guest Introduction
5:06 - The inception of HybridAGI: Addressing limitations of early LLM-based agents.
6:37 - Why Cypher was chosen for HybridAGI and its benefits for AI programming.
10:12 - Explanation of the four memory types in HybridAGI and their roles.
17:06 - Demonstrating a toy example: Building a Knowledge Graph for a movie recommendation system.
22:46 - Discussing dynamic program calls and embedding program descriptions for enhanced agent capabilities.
26:01 - Importance of protected programs for safety and maintaining architecture integrity.
32:55 - Insights into effective decision-making with LLMs and optimizing prompts for clarity.
37:22 - Exploring the concept of self-programming agents and dynamic task creation in HybridAGI.
41:00 - Why graph databases are crucial in neuro-symbolic systems and their role in reducing LLM dependency.
49:16 -  WrapUp

#neo4j #graphdatabase #llm #genai #aiagent