Graph Engineering explained in 8min..

When we ask cloud code to do a deep research about a specific topic behind the scenes, it's not just one agent that handles the entire research, but many agents are spawned to handle our research needs. Cloud code actually generates a dynamic workflow that looks something like this, where you have over 100 agents broken into various phases. And this entire workflow is generated on the fly by cloud code in JavaScript code. Like you can see here, that's 427 lines of code. And this very code acts as a runtime environment that will spawn over a 100 agents. And every new request that I send, cloud code will generate a fresh new workflow. And each workflow will spawn different numbers of agents. So given our example here of JavaScript file where cloud code essentially converted my research plan into a workflow as a runtime, cloud code will then start launching many agents in five different phases and each phase of the workflow will more or less work in parallel. And each agent has its own context window and its own system prompt. Pretty neat, right? Now, building on this workflow that you can see here, the concept for graphs has been resurfacing lately as if it's the next natural progression in our agentic engineering. So, we ask the natural question, what exactly is graph engineering? The idea of graphs dates all the way back to 1736 when a Swiss polymath, Leonard Luluer, was considering solving this strange question in a city called Consisburg. They have two mainlands and two islands and seven bridges connecting them. And the question was simple. Is there a route through the city that crosses every single bridge, but only exactly once? Now, you might try and hypotheize away by process of elimination. Maybe you can start here and try to cross the bridge this way. Or maybe you just start on the island instead and start out and see if there's another way possible. And you'll soon realize that this is not possible. Uler agreed. But it's not just that this wasn't possible, but how Uler simplified the problem into a simple concept shown in this diagram. Circles are nodes which in this case were land and the black lines are edges which are bridges in this case and these two constitute a graph. So this middle island here has five edges or bridges in this case connecting to other areas and so on. And given this representation, Uler concluded with a proof that this kind of route in Konoisburg is impossible. Now, the exact proof that Uler proposed is sort of irrelevant to this video, but Uler's graph theory is now applied to agents and graph engineering today. Here's another way to visualize the workflow that Cloud Code generated for my deep research from earlier. This consists of five phases. One agent for scoping the requirement, five agents to gather credible websites to research for each subtopics, 25 agents to then actually fetch the information and pass it to the next and 75 agents to verify the facts and vote on the credibility. And finally, one agent that generates the full report in the end. And this workflow you're seeing here is a form of a graph. In this case, because execution only flows from left to right with no node going backwards, which would form a loop, this is called DAG or directed asyclic graph. Now, we could technically do this with a single agent instead of hundreds of agents in a graph like we just saw earlier. But this would be a bit silly because using a dynamic workflow for this kind of work is better for many reasons. The most obvious one being time. By parallelizing task into sub aents that have their own small objective. This helps save a large amount of time by the simple fact that multiple agents are working at the same time. Another benefit is separation of concerns. The fact that each agent has its own context window helps focus its own context window towards its goal. Whereas a single agent might need to keep reusing its own context to store some of it for the goal, some of it for the current task, and keep summarizing back and forth. But graphs aren't without its drawbacks either. Enthropic made a post that talked about their multi-agent research system that said a single agent tends to use four times more tokens than a regular chat. And a multi- aent system tends to use 15 times more tokens in comparison. So going back to our example, each agent ran on Opus 5 with their own system prompt. And each agent used about 20,000 tokens by default to start. So, by the time you extrapolate this to 108 agents that it eventually used, the input cost alone would be closer to $10 given Opus 5's pricing. But since we have prompt caching, realistically, this number will look closer to a dollar, which helps scale our agent from a single agent to a parallel agent like you can see here. So, given the benefits and the drawbacks when it comes to graphs, why are everyone talking about graph and graph engineering as if it's the next evolution when it comes to agentic engineering? But first, a quick word from Zo sponsoring this video. It's pretty obvious that more and more parts of our lives are being integrated with AI and often our interactions are scattered across claude, chat, CEX, and Menace. So, how can we have more ownership while having a 24/7 agent? Zo gives you a dedicated computer on the cloud that's yours, meaning your agent is on standby for anything that you give. And part of being 247 is the ability to message your agent through text. You can directly message Zo to have normal conversations through iMessage or ask about files that you have stored on your computer in the cloud. And better yet, build an e-commerce website for vintage watches and host directly on Zo using their AI agent natively through text. What's cool about Zo is that you can viode and launch sites that are actually useful because you can integrate all your contacts into Zo and run automations. Custom domains are also included at pay plan and all your sites are hosted on your Zo's cloud computer. Plus, they got some neat tricks like the selector tool to edit exact areas to improve things or even add automations that plug into your website like a text anytime someone fills out a form. Try out today. I'll have the link in the description below. The concept behind agent communicating with another agent is not anything new. We can look back to open-source ideas like Autogen in 2023 from Microsoft talking about agents communicating with another agent. Companies like Langchain also started messing with cyclic graph in 2023 which led to langraph which became a framework for orchestrating agents. Enthropic also released various ways that agents can work together around the same time like prom chaining where LLMs are chained sequentially one after another. Routing which is similar to sub agents but from the perspective of the main agent. Parallelization which is similar to our deep research workflow. Orchestrator also similar to what we saw earlier. an evaluator optimizer where two LLMs adversarily go at each other until a condition is met. But none of these were materially useful back then because the problem wasn't so much in the graph itself, but what the node inside of the graph can actually do. In Langchain's blog post talking about graph engineering, they said that what changed wasn't the graph, but more in what the node can do. Back then it was just an LLM call. Nothing close to a full agent that we interact with every day like clot code or codec cli. These agents are immensely better given their myriads of tools and harness environment. So with the emergence of coding agents like cursor, Klein, Rue and Windserf, which were one of the few early players back then when it comes to agents, they focus more on single agents and improving that very agent instead of extending them to various edges that form a graph of agents actually working together. And over time, these agents individually started to incorporate better methodologies going from prompt engineering to context engineering, better harnessing, and now the bottlenecks started to shift away from what the node can do, but into a graph and the edges that connect the nodes together. And now, no pun intended, we're coming full circle back to graphs. Because the nodes are reliable and more capable, we can now scale our agent from a single agent to a workflow or a graph to target a much wider set of problems like we saw in deep research, which would have been really difficult for a single agent to solve. So going back to Uler's case, his challenge was to determine the physibility of crossing all seven bridges exactly once, which led to the birth of graph theory. In our case, our adaptation of graph theory into agents is determining how a task can be divided in a way that a highly capable node now should structurally be configured to solve a much more complicated task that we give our agents to solve.