Log In to continue learning
You've seen that agents can do more than just respond once. They can repeatedly act, get feedback, and adapt to what happens next. In this lesson, you'll learn four ways to engineer these loops: the agent, verification, event-driven, and hill-climbing loops, and see how each expands what the system can do. Let's dive in. Let's start by looking at where loop engineering fits within the broader field of agent engineering. As agents have evolved, several areas have received focused attention. The first was Prompt Engineering, which focuses on optimizing the instructions sent to a model. Closely related is Context Engineering. The prompt is part of the context, but the context also includes tool descriptions and results, human and AI messages, retrieved documents, memory, and many other types of information. Context engineering focuses on ensuring that the right information is available to the LLM at the right time. Harness engineering is broader and can encompass context engineering. It concerns the systems surrounding the model that make an agent effective. As you'll see in the next lesson, these systems can include file systems, code interpreters, and sandboxes that allow agents to generate and execute code, dynamic sources of instructions and memory, and a growing range of other capabilities that make long-running agents more useful and effective. So that brings us to Loop Engineering, the focus of this course. Loop Engineering focuses on building agents that improve over time. First, I'm going to talk about why loops matter, If we zoom out and think about why agents matter in the first place, it's because they can take action and perform work for us. Agents are only as useful as the model and harness around them, though. An important part of building a robust harness is in building the loops around it. I've identified four levels of loops, which we'll explore in more detail in the coming slides. First, you have the agent loop, the basic model calling tools loop which most agents are based. The second is the verification loop, against a given rubric. Third is the event-driven loop, which connects the agent to an application and invokes it in response to real-world events. And the fourth, and maybe most exciting, is the hill-climbing loop, which uses what happens during each run to improve the agent over time. Having loops as a part of every agent that you build ensures that every time you run an agent, it can get better and improve from the learnings of that run. Let's look at all these in more detail. The first loop is the core agent loop. First, a model receives context for a given task. Then, it calls tools to complete work for that task. Tools return observations, and then the model continues in that core loop until it's done with the given task. And so when we talk about loop engineering here, what does that mean at loop level 1? It means that you're selecting the right model. You want to match the model intelligence to the complexity of the incoming task in order to optimize cost. So in practice, this means you might select a cheaper, faster model for simple tasks, and a slower, more capable model for complex. It also means that you're giving the model the right tools for the given task. And then for tools, you can also do prompt engineering here, right? Like, are your tool descriptions good enough that the model uses them effectively? So really, this is a pretty simple loop, but at every level, there's optimizations you can make. For each of these loop levels, I'm going to talk about an example agent. It's an agent that we use every day at LangChain. This is our docs improvement agent. So we'll start with the very basic infrastructure here. We send a docs improvement request. The model plans and drafts changes, and then we give it tools to clone the docs repository, read existing docs, write new docs, and then open a pull request with an appropriate diff and description. So this is a basic docs writer agent, and it uses that core agent loop. So the second loop is probably the loop that started to popularize the term loops in the first place, And that's what you might call a goal loop or a verification loop. And this adds reliability to agents via grading and rubric criteria. So what does this look like? You can see outlined in purple here, I have the core agent loop. But now we have this green grader. You send a request to that core loop and it returns a result. So that's a cycle of the core agent loop. That gets fed into our grader agent, which decides if the task is actually complete. The grader scores the result against a given set of criteria. If those criteria are not met, we feed it back into the core agent loop. Otherwise, we move to complete. So one basic example might be a goal to implement a new feature in a codebase, and don't stop until all tests are passing and coverage is at 95%. So your coding agent would take a pass at implementing that new feature, and then we have the grader run over those criteria. In LangChain's agents, the grader is an option that you can add on to your agent. You provide a rubric and instructions, and the grader will determine if the rubric criteria have been satisfied. The result is a more reliable and trustworthy agent against your end goal. So what does this look like for our docs agent? We have the docs improvement requests coming in. The core agent loop opens a pull request, and then the grader agent ensures that all links resolve and that CI passes before an actual complete notification, right? Like, it's a little bit of a waste of a human reviewer's time to review a docs PR, if there are faulty links, for example. The last thing that I'll note about verification loops is that they are particularly powerful when you want to use a cheaper model on challenging tasks. The verification loop can help keep those core agent loop cycles on track. All right. So, the third loop is the event-driven loop. The reason that I'm excited about this loop is because it's what makes me personally actually use agents. become more powerful when they are looped into the actual systems where they're relevant. So, what do I mean by this? The TL;DR is basically, I want to be able to use my agents in Slack and GitHub and any of the places where I'm having important conversations, with smart people. I think this one might be a little bit of a stretch to call a loop, but really, the loop idea here is that you're able to trigger the agent in the system where it's relevant, and then inherently you're making that system better, and so you've got this improvement loop for the system. We consider loop 3 to be a loop because you're looping an agent into your existing workflows. So what do these triggers actually look like. They can be scheduled or they can be ad hoc and event-driven. For example, I could have a background agent that's scheduled to run over my calendar every morning and gives me a summary of my day and anything that I might need to prep, etc. I also have an email assistant agent that is triggered when I receive an email. The agent can read the email, draft a reply, decide if it's spam or worth surfacing to me, etc. Again, I'm pretty excited about this one, because I think agents don't have that much value unless they're incredibly easy to use. You can see in the diagram, we have the event trigger, then our nested verification loop, the nested core agent loop, and then also a system update. I'll also note in these diagrams I'm doing the Russian doll thing of nesting every loop inside of another. You don't necessarily have to do that for all four loops. For example, You could just nest a core agent loop in with an event-driven loop. You don't need the verification loop per se, but this just shows that they are all composable. So tying this back to our docs writer agent, What does this actually look like? So at LangChain, we have a Slack channel called docs-plz. I can send it a Slack message and say, "Hey, can you please update our DeepAgents docs to showcase the value of verification loops?" Then the core agent runs and drafts a PR. The verification loop decides if links resolve and CI passes. We actually go ahead and send a Slack notification back that's like, "Hey, Sydney, here's your PR, please review." After I approve and merge, we now have this live and discoverable docs enhancement. So event-driven loops allow you to embed the agents you've built into the systems or applications you're using every day. All right, maybe I said the most exciting loop is the event-driven loop, but I take it back. I think the self-improvement loop is actually the most exciting. We also call this one the hill climbing loop, the learning loop, self-improvement loop, all things of that nature. This loop automates agent improvement by finding signal in traces, which are records of every step an agent took for a given task. Agents are inherently non-deterministic, in contrast with traditional software where the truth was in the code itself and you could tell exactly what a program was going to do. for agents, the story is actually in the traces. And so, you need that trace signal to tell you how to improve your agent. So, what does this mean? We run our agent, and then in the background, a trace is stored. After the main agent run is done, we run another agent over that trace, and that helper agent is able to detect various failure modes from the trace itself. So what does that look like? Maybe a tool call was called with improper arguments. Maybe a critical tool call was missed because the relevant context wasn't there. Maybe the system prompt had some misleading information. So this helper agent helps to identify recurring issues or gaps in the core harness. And then the super exciting part is that this helper agent has the capability to update the prompts, tools, skills, memory, basically anything that's part of that core harness and port that back to the source code. And so this outer loop makes each inner loop more effective. So the first category of things that you can do with the hill-climbing loop is improve those basic procedural things, such as tool descriptions and prompts. I would even say skills are pretty procedural. The second category is focused more on memory type information, that's persisted across runs. So let's go back to the email assistant example. I probably want my email assistant to respond more formally to my boss versus my co-worker, right? I might provide feedback to the agent that an email to my boss needs to be more formal. I would hope that it would actually remember that guidance for future runs, and so one job that this background agent can do is memory consolidation so that the harness is learning over time. A lot of that comes in the form of user preferences, for example. The final note that I'll add on the hill climbing loop is that it's pretty hard to have confidence merging changes to your core harness if you don't have good evals that can help you validate those changes. So your helper agent has made some changes, it's added a skill, changed a prompt, and updated memory for some user. How do you feel confident with that merge? By running your eval suite and making sure there are no regressions, or maybe that there are even improvements on some tasks. So just bringing this back to our core example, what do we do with our docs writing agent? At LangChain, we built an agent called engine for this continual improvement loop. So we run engine over the docs agent traces, and then we can update all the things that you just learned about on that last slide. One really important note that I'll add here is that while we talk about automating things, human input is still really important. Let's talk about this at each loop level. So let's go back to that email assistant. if there is a send email tool, I probably want human approval in that cycle. So you can still add human approval at important or sensitive tool calls in that core loop. The second is that you can add a human to the grader or verifier cycle, basically plugging in some form of human approval in the grader stage. The third case is human approval on agent artifacts or results. So, in our docs writer example, we always have human approval on those PRs before they merge. And then the fourth case is approving harness and code changes to your core agent. So, for a quick recap of all the loops you just learned about: The first, the core agent loop, does the work. The model calls tools, allow the agent to take action, and the fact that this is done in a loop makes it pretty powerful. The verification loop improves quality, especially in cases where models aren't as individually powerful. The event-driven loop helps scale execution and make sure that agents are actually getting used. And then the fourth, my favorite, is the Hill-climbing loop, call it the learning loop or the self-improvement loop. This improves your agent system over time. And so, the key takeaway here is that the advantage is not just in the agent that you build to automate work, but rather in the loops that you build around it. Loops amplify impact. We know agents are already impactful, so building loops around them helps them do more. All right, that's an introduction to loop engineering. In the next lesson, you will learn a bit about DeepAgents, the agent harness you will use in the remaining lessons.