Transcript
00:00:00You've probably already heard about agent loops since everyone is hyping them up a lot right now.
00:00:05And you might think they're just a way for these AI companies to get you spending more on their
00:00:09products since these loops chew through a lot of tokens. But that only happens when you're using
00:00:13the wrong type of loop for the job. As you already know, we're a software company and we've been
00:00:18experimenting with these loops in our AI coding tasks. Along the way, we've mapped out the different
00:00:23types of loops and which use cases each one is actually suited for. So out of all the loops we've
00:00:28set up, we're going to share the ones we found genuinely useful. We'll also show you how to set
00:00:33up each one and how each loop is going to impact your workflow. Before we get into the different
00:00:38types of loops, let's quickly recap what loop engineering actually is for those of you who are
00:00:43new here. We won't go deep here, but if you want the full breakdown, we covered it in a previous video
00:00:48on the channel. The core idea of loop engineering is that you stop being the person writing the prompts
00:00:53that drive the agent and you turn it into a system that writes the loop itself. Instead of spending your
00:00:58time setting things up and writing long, carefully structured prompts just to get it to build, you
00:01:02let the agent handle everything on its own. It learns as it goes, grows from the problems it hits
00:01:07along the way and figures out what it needs to do next. That's what an agent loop really is. In that
00:01:12previous video, we split loops into two types based on the outcome you get, the deterministic loop and
00:01:18the non-deterministic loop. A deterministic loop is the kind where you already know the outcome,
00:01:22so the agent has a solid way to check its own work against it, and it keeps working until
00:01:27it gets there. A non-deterministic loop is the kind where you don't, so there's no solid way for
00:01:32the agent to check its work, which means you need other ways to handle it. But that was a broad split,
00:01:36and we showed just one way to set each of them up. They can be built in a lot of different ways,
00:01:41and each setup changes what you can do. The first type is one most of you have probably already used.
00:01:46It's basically the building block of every other loop, and the clearest example is the goal command.
00:01:51We call it the stateless loop, and basically it means the loop doesn't hold on to anything or improve
00:01:56itself as it works. There's no part where it learns from what happened and gets better. That's exactly
00:02:01what makes these the simplest loops there are. The one you've probably already seen of this type
00:02:05is the ralph loop, and it's stateless because it never kept any memory. It just ran the same task
00:02:10again and again, and the moment it saw the task was finished, it stopped. As you might already know
00:02:15about the goal command, it is the best example of the stateless loop. To use it, you tell it what
00:02:19you want to build, right after the goal command. From there, Claude sets that as the goal and starts
00:02:25working on it. Then every time the main agent decides a task is done, it uses a smaller model to
00:02:30double check the work. In Claude code, that smaller model is haiku. It checks everything the agent
00:02:35did against the requirements you gave in the prompt, and if the task isn't fully done,
00:02:38it re-prompts the agent to finish what it missed. But there's a problem with this loop. It leans
00:02:43entirely on the model to decide whether a task's done, with no standard to measure the work against.
00:02:48That's why it works best on features whose requirements you can check in some hard concrete
00:02:53way. One way to do that is with tests. Like we talked about in our previous video, we write the tests
00:02:58before asking Claude to build any feature. That way, if Claude changes that feature in a way it shouldn't,
00:03:03the tests throw an error and tell Claude its implementation is off. And once we've got tests
00:03:08for every feature, we can hand the agent real autonomy and let it work without worrying it'll
00:03:12break the other features or build the one we want the wrong way. Once you've written the tests,
00:03:17you can ask Claude code to set the goal as getting that feature to pass all the tests. And it keeps
00:03:22writing code, running the tests to check itself and keeps going until every test passes. Once they all
00:03:27pass, that means the feature is built correctly and Claude will mark the goal as complete. Since the agent's
00:03:33working on its own, you'll want to add one line to your Claude.md file. That line tells the agent to
00:03:38save every working version of the app. That way, if it breaks the app somewhere down the line,
00:03:43it can just roll back to the last version that worked and carry on from there instead of trying
00:03:47to undo changes from memory. But before we move on to more types, let's have a word by our sponsor.
00:03:53Minimax. Minimax just dropped M3 and it's the first open weight model to hit the frontier on three things
00:03:59at once. Coding, a one million token context and native multi-modality. So we plugged the M3 API
00:04:06straight into Claude code and gave it one real job, researched the top electric cars on sale now and
00:04:11build a live comparison dashboard. M3 took it from there on its own. It browsed the web, pulled real
00:04:17specs and prices, then shipped a working dashboard from scratch. You can search different EV brands,
00:04:22browse their latest models and everything updates in real time. On autonomous browsing, it beats Opus 4.7
00:04:28and its million token context held every page plus the whole code base in one window. But agent runs
00:04:34like this burn a lot of tokens and that's where the Minimax token plan comes in. Pick token plan for fixed
00:04:40costs or pay as you go for flexibility. Text, image, speech and music share the same token pool with the
00:04:46highest quotas. Plans start at just $20 per month, so hit the first link in the description
00:04:51and get an exclusive 12% off. The stateless loop we just walked through holds no state. It does everything
00:04:58on its own from the instructions with no self-improvement in the process. The next type works the opposite
00:05:03way and we call it the learning loop. A learning loop works differently. Instead of just getting a
00:05:08task done and stopping, like a stateless loop or the goal command, it focuses on improving something
00:05:13you'll use repeatedly, whether that's a skill or a workflow. The way it does that is simple. It runs the skill,
00:05:18observes how it performed and then improves it based on what it learned, keeping a complete record of
00:05:23every lesson along the way. So that when you run the skill, when you're actually using it, the agent
00:05:28knows what caused issues in past, so it won't lean towards that. You can put this kind of loop to work
00:05:33for a lot of things. For example, on the community website of ours, we built multiple skills to handle
00:05:38different repeated workflows while putting the site together. But building a skill raises an obvious
00:05:43question which is how you'd even know whether it's working the way it should. So to answer that, we set
00:05:48up a full learning loop. We did it by creating a skill loop command that triggers the loop. This command
00:05:53contains instructions to call a skill improver agent and keep calling it until there is no more
00:05:58improvements left. This skill improver is actually an agent we created which improves the skill by
00:06:03assessing its quality, testing it across multiple areas and watching for the issues that come up. To use it,
00:06:08you just run the command and pass in whichever skill you want to improve and it gets to work. This loop
00:06:14runs in multiple rounds. In each round, it runs a set of tests and checks after making its changes.
00:06:19Then it launches a separate Claude session that works only on the prompt you pass it, running in the
00:06:24background without stopping to ask permission for anything and reporting the output back. Inside those
00:06:29sessions, it runs the implementation two ways, one with the skill and one without, so it can measure the
00:06:34actual impact the skill has. That comparison lets it pin down exactly what needs improving and it makes
00:06:40those changes directly. But the most important part is the learning.md file it creates. This file
00:06:46gives the agent a way to know what works and what doesn't and it lives inside the skill itself. It's
00:06:51basically an improvement journal that documents everything the agent learns in a structured format.
00:06:56It records what it tried and what the result was, both with the skill and without it, then lists the
00:07:00lessons it picked up across all the rounds it worked through and that's how it keeps going round after
00:07:05round until the skill is refined into the best possible version of itself. You can use the same
00:07:09setup to improve any workflow you've got. In our previous video, we showed how to build a loop with
00:07:14two agents, one that handles the implementation and another that reviews the work and reports backfixes for
00:07:20the implementation agent to apply. There's a problem with that setup which is that a single review agent is
00:07:25handling every aspect of the review on its own. But a review is never about just one aspect. It always
00:07:30comes from different perspectives and that's too much ground for one agent to cover alone. It's
00:07:35better to split those across different agents because when multiple agents review across multiple
00:07:40dimensions, they cover the blind spots any single agent would miss and that makes the review way more
00:07:46complete. The idea is close to the LLM council that Andrei Karpathy released, which is a council of
00:07:51multiple agents that talk to each other and argue over a topic you hand them using the reasoning of
00:07:56several models to land on the right answer. For creating a multi-agent loop, you need to create
00:08:00multiple agents. So for example, we created four agents in the loop we set up. The first checks for
00:08:05factual correctness and it comes with tools like web search so it can ground itself in real sources.
00:08:10The second is a domain checker agent which checks whether whatever is being reviewed is actually
00:08:15relevant to what we're trying to do. The third is a safety critic agent which looks at the safety issues
00:08:20like sensitive content along with security risks and policy violations that could cause problems
00:08:25down the line. And the last is the style critic which makes sure the content is clear and well written
00:08:30and tailored to the style we're after. You can use these agents for any task whether it's coding or not.
00:08:35What ties these four together is an orchestrate command that we created. This command contains the
00:08:40detailed instructions for how it should manage and coordinate all four agents and handle the feedback
00:08:46each one reports back. To start the loop, you run the orchestrate command and ask it to review whatever
00:08:51you want and it spins up all the agents for the process. The orchestrate command runs in multiple
00:08:56rounds too, spinning up every agent in each round. The main agent applies all the fixes reported in round
00:09:01one then spins them all up again for the next round. By the end of the final pass, you're left with the
00:09:06app in way better shape. If you'd rather the agents communicate directly, you can use the agent team's
00:09:12workflow we covered in a previous video which gives you more of the LLM Council experience without one
00:09:17agent handling all the communication. But we chose the orchestrator because one agent needs to hold the
00:09:22context of the previous rounds to coordinate the workflow properly. Another type we reach for often
00:09:27is the verification loop. It uses multiple agents as well where one does the implementing and the other
00:09:33scores that implementation and the implementer's whole job is to get that score as high as possible
00:09:38against a set metric. To set that up, we created a command that coordinates the entire loop running the
00:09:43whole review workflow on its own. As you already know that Cursor has thermonuclear review. It's actually
00:09:48a really powerful review skill that checks how clean and healthy the code is so it stays easy to build on
00:09:54later. It audits all of the code and hands back an in-depth review with non-negotiable standards so
00:09:59you're guaranteed the highest quality review it can produce. To do that, it runs a dynamic workflow.
00:10:04The review has to span a lot of categories and a dynamic workflow is the best way to handle that,
00:10:09since it fans the work out across multiple sub-agents that each take on a different aspect at once.
00:10:15Like we mentioned earlier, we created two agents that act as the players in this loop. The first is
00:10:20the implementer whose job is to read the PRD and then build the required functionality. The second
00:10:25is the thermonuclear code reviewer and its only job is to hand back a review score. Since all it does
00:10:30is review and score, it doesn't have tools for editing. To trigger it, you run the review loop command.
00:10:35It starts by understanding what the app is meant to build, then kicks off a thermonuclear review for
00:10:40round one. That first review flags the issues it finds, including a critical one that's stopping the
00:10:45app from even starting. It records the findings in a JSON file and spins up the implementer agent to
00:10:51fix them. The loop keeps going from there, but keep one thing in mind. Because it's reviewing across so
00:10:56many dimensions, it takes a really long time and eats up a lot of tokens, since the dynamic workflow
00:11:01driving it fans the work across a whole set of sub-agents at once. So we wouldn't recommend it unless
00:11:06you've already built the whole app at a larger scale and want it thoroughly reviewed. You can also build
00:11:12this same loop without the dynamic workflow by using a normal reviewer agent, which takes less time and
00:11:17burns through way fewer tokens. And if you're enjoying the video so far, subscribe to the channel and hit
00:11:22the hype button. This small gesture of support goes a long way for us. Out of every loop we've shown you
00:11:28so far, none of them had a separate step for improving the loop itself, but that's really a core of what a
00:11:33loop is meant to do. That's where the workflow improvement loop comes in. What this loop does is go a
00:11:38step beyond just repeating the task. Instead of just running it again and again, it looks at the process
00:11:43itself and suggests improvements to the workflow. Now you might think the learning loop from earlier
00:11:48already does this, but there's a real difference. The learning loop improves a skill, one piece inside
00:11:53the process. This one improves the loop itself, the whole process you've set up. The entry point is an
00:11:58iterate command that acts as the orchestrator for everything that happens during each run. There are
00:12:03three agents this time. The first is a builder agent, which handles the implementation and delivers one of
00:12:08the app's requirements on each run. The second is a scorer that checks that implementation against a
00:12:13rubric we defined to act as the app's quality guardrail and scores the work out of 100. And the
00:12:19third is the process optimizer agent, which is the one that actually handles self-improvement.
00:12:24Normally, a loop runs through the same cycle where it plans, implements, verifies, and repeats, but this
00:12:29agent adds an extra step of going back over the loop iteration and suggesting ways to make it better.
00:12:35To use it, you just run the command iterate all. By all we mean we're implementing the entire app,
00:12:40broken into parts inside a single workflow. The loop starts by spinning up the builder agent,
00:12:44then the scorer evaluates what it built against the rubric and records the score in a JSON file that
00:12:49tracks every round. Then the process optimizer agent kicks in, going through the conversation to spot
00:12:55anything that could improve the workflow, making sure the app is built to a high quality and the
00:13:00right steps are being followed. So by the end of this workflow, you don't just walk away with a
00:13:04built app, you walk away with a workflow that's been tested and refined, with every step validated as
00:13:10one that actually needs to be there. That brings us to the end of this video. If you'd like to support
00:13:15the channel and help us keep making videos like this, you can do so by using the super thanks button below.
00:13:20As always, thank you for watching and I'll see you in the next one.