Graph Engineering with ADK transcript

In this video, you will know what Graph Engineering is and how to build one and when you should use it. Hey, I'm Annie. So in the last video we discussed why Loop Engineering failed and why you should consider Graph Engineering. And today let's define Graph Engineering with code that actually runs. So first what is Graph Engineering? You can think of it as you're creating a graph workflow for your system. And inside the graph you can have agents or other deterministic function as node.

And let's build one together with Google Agent Development Kit 2.0 to help you better understand it. So we will use this one example. Race day. A runner is about to run a marathon and they want an agent that answers one question how should I run this race? And what are you looking at right now is attempt number one, one agent, one giant prompt. It promises everything. It fetches the weather, analyse the course, it checked my fitness, built my race strategy.

It has this all the workflow inside the prompt. So watch what happens if I run it. Look at the answer and is so confident. It is very specific. But it has one problem. It has no weather API, it has no course data. So every one of those numbers is invented. Is hallucinating. So this is a disease. When every step leaves inside one model call, nothing can be fetched, nothing can be tested, and nothing can be trusted. So the fix is not a better prompt.

The fix is structure. And here is where Graph Engineering fits. So first we learn Prompt Engineering what to say to the model. Then Context Engineering, what to put around the model. Then Loop Engineering letting agent plan, act, check in a cycle. So Graph Engineering is a next layer. Many pieces of work wired together. The pieces are nodes, the wiring is edge. So let's solve this some problem using Graph Engineering mindset.

First, let's build the smallest possible graph to solve it. You know we want to first fetch race day condition and then come up with a strategy. So we have two nodes. Node one is a plain Python function. It fetches race day conditions, no model, no cost. And node two is an agent, it reads those conditions and writes advice. And this is a part that surprise people. You know the function and agent there appears same list, same wiring.

So if you look at the edges start to fetch to advise. That's the entire orchestration. And now let's run it. The function fetched zero LLM cost. The agent reason one LLM call. Real data in, real advice out. And here is one principle and you probably already have it. Predictable work goes in functions and reasoning goes in the model. And now let’s iterate to the next shape. So here we have three concepts. Fan out, Join, and Router.

So my risk strategy needs three inputs. Weather, Course and Fitness. They don't depend on each other. So why don't we run them together in parallel? So let's draw three edges out of start. First we have this fan out pattern. These are parallel processes. We have all three fetches leave at once and process them at the same time. You know in ADK 2.0 you can also create dynamic fan out. If you have parallel process, but you don't know how many of them will run at the same time.

And we can create the shape in runtime with dynamic workflow and that is what we call dynamic fan out. And now let's get back to our marathon example. Once we get all the input and then they meet at the join node. This is a second concept. It's like a synthesizer in a gigantic system. So it waits for all three branches, waits for the slowest process. And bundles the outputs into one dictionary keyed by node name. And here you never need to write a merger.

You never wrote an aggregator agent. A join node can just work in the graph. And now the last concept, Router Pattern. It is also the shape everyone gets wrong easily. You know, in this situation we have Hot day, Cold day, Normal day. Three strategies. You have three specialist agents and we need to pick one. So how we define this router here to pick one strategy? You have option one LLM router. They can ask the model to classify.

It works but it cost tokens. And it can misread because AI is non-deterministic. Option two, Deterministic router. We can put a deterministic router node with fixed views and conditions in the graph. You know we make hot points to hot strategy, normal to normal strategy, and cold to cold strategy. So how do we pick one? So for example if you have a free tax request if user types anything they want and there is no signal for an if statement to read.

And that is an open set and that LLM router is the best tool. The if statement deterministic router means when the set is closed and the signal is in the data. And in our race example, we use a deterministic router because it's more reliable and it also cost less. Okay, now we cover three concepts in this graph workflow Fan out, Join and Router. So let's count the cost. We have three parallel fetches, one join and one strategist.

Still exactly one LLM call, because only one strategist agent node required LLM call. Other nodes are all the terms of logic that don't require any LLM call. And now we see this example of Graph Workflow. But sometimes you don't need a graph at all. So here are some questions to help you figure out whether to use graph or not. So first question is can you draw the workflow before the input arrives? If yes, draw it and use graph workflow.

Second, what if the shape itself depends on the input? For example, the deep research scenario. You do not know how exact the graph looks like. You can create a dynamic workflow with ADK 2.0 and your code will decide the graph shape and runtime. All right that's it for today's Graph Workflow, Graph Engineering. And let me know how you create your own workflow. And don't forget to share your experience in the comments.

Thank you so much for watching the video and I will see you in a future one. Bye.