Speaker A
Everyone's the Sean. So, today let's talk about loop versus graph engineering, two biggest buzzwords in the AI agent space recently.
Learn AI agent engineering concepts including loop, graph, system design, and Waku-Agent in 21 minutes with practical examples.
Ask about this video. Answers come from its transcript only — with the timestamp, so you can check them.
Generated from the transcript and can be wrong — check the timestamp.
Key Takeaways
- AI agent engineering has evolved from prompt to context, skills, loops, and graphs.
- Loops allow flexible, goal-driven tool use by AI agents, while graphs enforce structured workflows.
- Combining loops and graphs provides a balanced approach for complex AI agent tasks.
- Waku-Agent is a practical example demonstrating these concepts with real coding and dashboard.
- Understanding these concepts is essential for building advanced AI agents in real-world applications.
What the video covers
- Introduction to loop versus graph engineering as key concepts in AI agent development.
- Explanation of the AI agent engineering ladder: prompt engineering, context engineering, skills, loop, and graph.
- Prompt engineering as role-playing with LLMs to control responses.
- Context engineering involves feeding data to AI agents for real workflows like customer service.
- Skills represent procedural memory to teach AI specific workflows and reduce repetitive instructions.
- Loop engineering enables agents to iteratively use tools and APIs to achieve goals without predefined procedures.
- Graph engineering combines skills and loops to create deterministic workflows with some flexibility.
- Demonstration of Waku-Agent, a GitHub project that integrates loops and graphs for AI agent tasks.
- System design insights on how loops discover next steps and graphs manage structured workflows.
- Overview of practical use cases like calendar checking, GitHub issue triage, and web search integration.
Chapters
- 00:00Introduction to Loop vs Graph Engineering
- 01:07Waku-Agent Coding Example Overview
- 02:22Prompt Engineering Explained
- 03:44Context Engineering and Data Feeding
- 05:04Skills and Procedural Memory in AI Agents
- 06:07Loop Engineering and Tool Usage
- 07:13Graph Engineering and Workflow Design
- 08:26Combining Loops and Graphs for AI Agents
- 09:26System Design: Loop and Graph in Action
- 09:35Practical Use Cases and Community Invitation
Full Transcript — Download SRT & Markdown
Speaker A
I am probably exactly like most of you guys, which is I don't know how to keep up with all these new concepts, but I still find it very interesting because whenever a new concept becomes viral, you don't care about what triggered it.
Speaker A
What I find out is that this guy called Peter Steinberger, who's also the author of this little lobster, which is OpenClaw, said, "Are we still talking about loops or did we shift to graphs yet?" And he posted this on July 18th,
Speaker A
2026, which is about 13 days ago. And he got 3 million views. And look at this first comment. It said, "Bro, stop.
Speaker A
I am on vacation." So, sometimes, you know, these important people in the space who mention a keyword and then everybody's going to start talking about it. I remember exactly something like that in context engineering. And for today's video,
Speaker A
we're going to demystify all of these core AI agent concepts and especially on loop and the graph. We're going to jump in a little bit on the system design real quick. And at the same time, we're also going to walk you through a real
Speaker A
coding example called Waku-Agent, which is under my GitHub, Shen Sean Chen. And we published this about 2-3 weeks ago and we got more than 700 stars. If you think this video is helpful for you, please give us a
Speaker A
star, give us a like, and that will be very helpful for us. With Waku Agent, you can launch a dashboard like this and you can just ask something like, "What's up on my Google calendar on Thursday?" Right? And then it's going to check what
Speaker A
kind of graph it's going to use, decide if it needs to retrieve some memories, and then eventually decide, you know, what kind of tools it should be using, right? Right here it's listing the events from my Google calendar and
Speaker A
eventually sends you the reply. And it did a bit of testing in the eval system and then, you know, it spit out the final answer for the results. I'm going to talk a bit more
Speaker A
details into this, but without further ado, let's get started on the system design. First thing first, I want to talk about the AI agent engineering ladder that we have come across over the past 3 years, because I think that it
Speaker A
helps us to kind of understand where we came from and where we're going. And the first one is obviously prompt engineering. And to me, prompt engineering was the very first or early version of how people start to get used
Speaker A
to how to use an LLM. I feel the most accurate word to describe this was role-playing, because at the very beginning, we didn't know how to use LLMs. We had ChatGPT 3.5, and we tell it, "Hey, you are the best poet, like
Speaker A
you're Shakespeare or Li Bai, right? Write me a poem about this scenario I'm looking at right now in Switzerland." Then, it's going to pretend that it's one of those poets you just mentioned and then talk to you back, right? That
Speaker A
was prompt engineering. You basically draft the prompt so that you control the LLM to talk to you in a certain way you want. And then we quickly evolved into what we call context engineering, and that is because when people move from
Speaker A
just playing with LLM as a consumer product to actual workflows, you realize that you not only need prompt, but also you need to feed in data. For example, if you build a customer service chatbot or if you build a sales agent like
Speaker A
Automaton, which is my company, you need to really think about how do you construct the context for the agent so that the agent will be able to talk to the clients on behalf of the businesses, right? So, you not only will say, "Hey,
Speaker A
you are the best salesperson in the world." You will talk in certain ways, do not say certain things. You also need to feed in data such as what are some of the customer relationship data people already have on
Speaker A
their Excel sheets, Google sheets, CRM system, all these kinds of things. And you need to really put them together and ensure that the agent can accurately be fed with the right information. So, we moved from prompt to context very
Speaker A
quickly to fix that problem. And then we moved on to skills, which I think is sort of teaching the AI what kind of procedure it should follow. Right? It's a procedure-following process. In AI agent harness, this is called procedural
Speaker A
memory. It's a memory that you tell, say, you tell a kid, "Hey, when you walk home, walk on the right-hand side if you're in the US or in China. Right? Walk on the left-hand side if you're in the UK or
Speaker A
Japan." That is a procedural memory that you want a person or you want an LLM to remember and there's no, you know, extra data. It's just a fact that it should be doing when a certain situation happens.
Speaker A
Okay? So, why do we need skills? It's because that if you just, if you provide a lot of context to the AI, sometimes it can be a little repetitive.
Speaker A
You don't want to always provide, you know, the same order to AI again and again and again. So, having a skill to determine a workflow becomes really, really handy. Just like, for example, if you're coding on Claude code, you don't
Speaker A
want to explain to Claude that do not use emoji. Do not use emoji. Do not use emoji. Or I prefer to use emoji. Use these emojis. Don't use the brain emoji.
Speaker A
I hate that. Right? These kinds of things you have to repeatedly tell the context, then it's becoming less convenient. So, you can build up skill to make sure the LLM is following that procedure. Then comes with loop.
Speaker A
What does loop do? A loop is basically saying, "Hey, maybe sometimes you have a goal and you want to finish that goal, but we don't know the exact skills that you should have to finish that goal. We might tell you, 'Hey, there are a bunch
Speaker A
of tools you can use.'" Right? That's why Anthropic came up with MCPs. You can call your Google calendar. You can call your Gmail APIs, you can call your GitHub APIs. These tools become handy and then you're telling the LM, be like,
Speaker A
"Okay, run a loop. Know your goal, which is maybe help me fix this bug that the customer came up with.
Speaker A
Run this loop and here are a bunch of tools. Here's a web search tool. Here's a bunch of API calls. Here's a bunch of MCPs.
Speaker A
Use them. Loop it until at some point you finish the goal and that's the end of the iteration." And then the question comes, why do we need graph?
Speaker A
What does graph do? Because graph technically is a procedure that is predetermined. Many people are criticizing graph engineering is not new because maybe in 2023, I remember people were already using Airflow, people are using step functions, people are talking about how
Speaker A
do we make sure that a deterministic workflow can be set up properly so that we don't just tell LM to make all the decisions. Because sometimes we know exactly how a certain task needs to be done. There's a step there. There's an
Speaker A
SOP there. So, to me, it kind of feels like, "Okay, we moved from skills, which is strict procedure following, to loops, which is, 'Hey, agents, go figure it out yourself,' to eventually we realize that, 'Hey, we need a mixture of both.'
Speaker A
That, in my opinion, is graph. Okay. Technically, sometimes you should write the skill first.
Speaker A
Okay? How do you cross the road? On what side do you walk on the pavement depending on which country you're in?
Speaker A
And how do you respond to a client? How do you respond to me when I'm coding with a coding agent, right? And then you should turn that into graph. If you see that there's a lot of repetition in the
Speaker A
workflows, especially if you're building a workflow for corporate, right? If you're working in e-commerce, maybe you see exactly how your customer service should be answering questions related to logistics, to refund, to checking samples. You realize that you
Speaker A
can really consolidate this into a graph when the workflow stops changing. Perhaps there's still part of the workflow that you need to use a loop, where the loop is basically doing this exploratory work out there, right? It's probably doing, you know, a bunch
Speaker A
research for you. Um, I think deep research is one of the early examples of a loop engineering workflow here, where you just say, "Hey, go crazy. Just go search the internet. I want a report." These kind of work are, you know, less
Speaker A
standardized or it doesn't have an SOP in it. It's just about, "I want more information or I have a certain goal.
Speaker A
Use the tools available to you to figure it out for me." It's quite different from graph, because sometimes we know exactly what tools they should be using to uh finalize a task for me. Okay, guys, that was a conceptual walk-through
Speaker A
of this AI agent engineering ladder. Now, let's take a look at what a loop and a graph look like. What a loop does is that it discovers what to do next.
Speaker A
So, maybe this is you, and you ask a question to the LLM, and the LLM is basically saying, "Hey, do I need to use any tools? If yes, choose a tool, run it, and check if it finished the task,
Speaker A
come back to the LLM, and then loop it again and again and again until at some point LLM is like, "Hey, we don't need a tool anymore. Let's reply to the user." Examples here could be like, you are trying to fix a bug on
Speaker A
a pull request on GitHub. You basically ask Claude Code or a Codex and be like, "Fix this bug. Tell me when it's fixed." And it's going to go ahead and then use a bunch of tools like web search, GitHub
Speaker A
CLI, checking your Supabase, checking your AWS, checking your Google Cloud, all these kind of stuff. And then at the end saying, "Okay, we're done. Okay, and the bug is fixed because ABCD." That is a loop.
Speaker A
A graph, on the other hand, is somewhat similar, but uh it's not exactly the same. So, you might have a So, you might have a standardized process every day and be like, "Ooh, I want to understand how many people have
Speaker A
submitted pull requests overnight, and who are these guys who submitted some tasks? Can we take a look at them? And uh tell me if uh things are fixed or not. And maybe at the same time, I want to understand you know, what are some of
Speaker A
the latest news out there on AI agents? And maybe we want to do some web search as well. Maybe we want to run some, you know, get commands. At the same time, we know exactly how it works. Okay.
Speaker A
And then, you probably want this to be done in parallel. So, you ask a question, and then it's going to check out the GitHub to check out the pull request. It's going to search the website for you to do some exploratory
Speaker A
analysis. And it's probably also going to check your calendar, plus the memories stored locally or on the cloud.
Speaker A
And then it's going to synthesize these information and tell us, "Hey, is there anything else to do? If not, end this and reply. If yes, please explain what kind of things do you still need to do?" Okay. You see the difference here? So,
Speaker A
sometimes you can have some loops here. Okay? Maybe having agent Maybe having an agent loop to search the web or have an agent loop to fix the bugs on GitHub is part of this graph.
Speaker A
Okay? So, you can see graph is basically saying, "Okay, I know exactly what you should be checking. Maybe they're in parallel. Maybe they are happening in sequences.
Speaker A
Do it the way I want. And uh once you finish, uh synthesize it and tell me the answer." Are you guys still with me?
Speaker A
Let's check a real example first. Come back here. Let's come to Waku agent dashboard. The way you set it up, by the way, is come to this website, github.com/jasonchan/waku-agent.
Speaker A
You can either click on code and copy this and then type into your terminal and say get clone and paste that in and hit enter, which is this way, and you can just copy this and paste in your
Speaker A
terminal. Or recently, we released a new package in Python called waku-agent. All you need to do is copy this, pip install the Waku agent into your terminal, set up your environmental keys, and then you can launch a dashboard. Copy this.
Speaker A
Paste this in. Because I'm already using port 777, so let's use 778 as an example.
Speaker A
Paste that in. You can see, this is it. Okay. Since I already set it up, I'll come back to this local host 7777.
Speaker A
So, what you're seeing right here is is an entire AI agent harness starting from the gateway, which can be the chat of here, or you can use some other channels such as Discord, Telegram, WhatsApp, stuff like that.
Speaker A
And then it's going to check out the retrieval gate to see if you we need any procedural memory, which is skills, as we mentioned, or semantic memory or episodic memory, which are durable facts or the dated events that happened in
Speaker A
your local memories. Okay. And then it's going to run through an agent loop using LLM agents and calling tools, and eventually give you the reply, during which the LLM ops is going to trace the data, test it, and then release it, the
Speaker A
new version of the prompt, and the feedback to the harness. But this is the entire harness, okay? And loop engineering is happening here in this little loop.
Speaker A
A graph workflow is basically after this gateway, you can predefine some of the process in between here. So, we have a new tab called graph. We currently have two graphs here. One is called triage, another one is called gather. For triage
Speaker A
graph, what it does is that it's saying, okay, start point, and then it's going to classify if it requires some agent calls, and then at the same time, it might just check out my calendar and see what's going on. Okay. And I can just be
Speaker A
like, what's up today? All right. You can see the trigger this triage first. Right. It checked the Google calendar for me, and also at the same time it was checking, you know, if we need to have some uh
Speaker A
need to do some serious agent calls here. And it eventually decided that, okay, it's going to use some tools, so they used the list events, read the Apple calendar for me. So, you just saw a very simple graph kind of call
Speaker A
already, okay? So, what it did was that it checked, as I mentioned, if it needs some serious agent calls, and in parallel at the same time was already checking my calendar because I was asking what's up today. And then after
Speaker A
that, use this loop to run to call the tools like list events, read Apple calendar, and all these kind of stuff, and then give me the reply, okay? But what if I need to test something else?
Speaker A
So, here in this local agent harness, what I recently updated is that you can very clearly mention the workflow you built in the graph we have gathered. So, we can clearly say {slash} gather, and then say, "Tell me what's up with Waku
Speaker A
agents and any new PRs, any competitive projects?" Let's see what happens. You see that it triggered this graph instead, okay? Let's come back to the overview. It's showing me that it was triggering triggering this graph, and it used these tools simultaneously,
Speaker A
and then it's synthesizing the answers for me, okay? So, So, what it did was that it gave me a morning brief on what kind of PRs are out there, and we have released a new package, which you can
Speaker A
check in this GitHub. If you scroll down a little bit, we have released a new package for agent graphs recently.
Speaker A
And also there are some PRs to be reviewed, okay? Let's come here. So, if you click into pull request, you can see there are some PRs here for me to be reviewed. And for the web search, you can see that it researched about
Speaker A
Harrison Chase published your harness, your memory, and your own videos in Harness Eval our ranking.
Speaker A
Okay? It was doing the committed research for me as well. All right. So, you might be wondering, how did this work? If we come back to the tab for graph, you can see that we clearly defined two different use cases
Speaker A
of graph. One is triage, another one is gather, and they have very specific ways of running the agents. And they both use loops because when it does the web search, it needs to search for the information and come back to me, right?
Speaker A
When it does the check calendar, it's going to check the calendar until it find out what's going on in my calendar and then come back to me. Okay? These things are all kind of intertwined in this agent harness system. So, if we
Speaker A
come back to the system design, there's something interesting I wanted to show you, which is how exactly did the workflow finish from the beginning to the end from a time usage and parallel processing perspective. For the loop, an
Speaker A
agent loop, for example, web search is going to decide what's going to do first, right? It's going to check out my GitHub calling tools one by one, right?
Speaker A
Maybe after the first call, the agent decided, "Okay, we need to do one more call." And then it called again. And then it checked the calendar. And then it synthesized information for me.
Speaker A
But in the graph example, which is this which is this workflow for gathering information, it used multiple tools in parallel because we already told it, "You need these four tools." All right? Maybe each one of them spent different amount of time. And then it
Speaker A
did the GitHub first and the web search did the most amount of time. Calendar check and memory retrieval did the least amount of time because it's instant or maybe because you did not need any memory retrieval at all. And then it's
Speaker A
going to synthesize the information because it's got a lot of context at the same time. So, you cannot say So, you cannot say graph engineering is replacing loop engineering because they're coexisting. And you cannot say loop engineering or graph engineering is
Speaker A
better than the other one because we need them in different use cases. A loop is something you need when the model decides what to call one step at a time.
Speaker A
A graph is something like when you know the shape and you just want them to move together. Okay? It really depends on the situations you're building for. In your local files, we have a Waku folder and then we have a graph folder.
Speaker A
And within the graph folder, we have defined the graph engines, which is literally a graph.
Speaker A
And you're going to add nodes, which in our case could be web search tools, could be agent calls, could be MCPs, anything. Right? And then you're also defining edges, which is okay, do we where do we go after using one tool?
Speaker A
Right? After the web search, do we go synthesizing or do we go somewhere else?
Speaker A
Right? graph We also defined nodes, which is basically saying what kind of things can be a node, right? Tool calls, LLM calls, agent calls, router, these kind of things.
Speaker A
And then under this graph folder, we also have another folder called workflows. You can see we have triage here. Right?
Speaker A
Remember triage was the chart we showed you, which is it's going to classify if it needs to use some complex models to do agent calls or is it doing some calendar checking at the same time? These two things are
Speaker A
happening in parallel at the same time. And the code is actually very simple. You define these functionalities to make sure that the triage graph is working properly with this predefined workflows. Right?
Speaker A
You add node when you need to add in one more tools. You add edges by defining initial prompt from start can go to either classify or check calendar at the same time.
Speaker A
If we check out the gather tool as well, remember it's the similar thing as our previous chart. You can scan the GitHub, website, check calendar, memory. Okay?
Speaker A
GitHub website calendar memory. These are all the nodes and after that you synthesize it and then you decide if we should return the answer. Obviously, we're doing the same thing. We're building the graph here, right? We're adding these nodes
Speaker A
and we are adding those edges too. I hope this is easy to understand. And you can feel free to add more .py files here to make this graph workflows even larger. And in that case, I will have to
Speaker A
work with you and then you can feel free to contribute to this repo and be one of our contributors and submit your own workflows because once you submit your own workflows and it's approved, it will be available here. If I type in {slash}
Speaker A
graphs, it's going to tell me that it has gather, it has triage, and triage is the router. It's basically going to read the local files of these workflows from graphs, and people can use it. This would be very cool, and it will probably
Speaker A
become a community if you guys are interested. And feel free to be our contributors. And also, if you're interested in talking more in depth of these concepts with us, if you feel you want to discuss with me about your
Speaker A
workflows and any questions you have about system design, about these agent harness, all these kind of stuff, you can feel free to come to my personal website, shaunchand.io, and then click on join over here to join our community.
Speaker A
I'm just getting started to do this because I don't have enough time to answer all of your questions. I feel like the most efficient way is that I can host some live sessions with you uh twice a month, so that I'll be able to
Speaker A
answer most of your questions, and we can prepare some, you know, build sessions real time, showing you my real setup, all these kind of stuff. If you join this community, you will be assigned to a private Discord, and I will share more details there,
Speaker A
including the original files of all of these system design charts that I have built in the past uh in real code, so that you can sort of open it in your own Excalidraw website to learn about it.
Speaker A
So, last but not least, I think this is an important question we should ask ourselves, which is isn't this just a deterministic workflow from 2023? What is new now is that some of the nodes we're using right now are
Speaker A
non-deterministic. Could be a LLM call. And at the same time, sometimes the model can pick the edge, all right? The routing is the way that, you know, you're letting the LLM as a judge, do I pick a simple model to answer the
Speaker A
questions, or do I use a more complex model to answer this question? And also, you need some guards, which a previous directional graph scheduling never did.
Speaker A
These are buzzwords, as I mentioned, but buzzwords are viral for a reason. Sometimes it's because of famous people, sometimes because it's actually useful.
Speaker A
So, I hope this kind of videos is helpful for you. And again, if you have any questions, feel free to ask me. And I would love to answer your questions live in our community. Just come to my personal website shaun.io and then there
Speaker A
are a bunch of sources here. Looking forward to And if you love this project, please give a star on GitHub repo and I would love to work with you. Thank you so much for your attention. Appreciate it.
Topics:AI agent engineeringloop engineeringgraph engineeringsystem designWaku-Agentprompt engineeringcontext engineeringprocedural memoryAI workflowsSean Chen
