Transcription
Today, I'm going to talk about loop engineering. We're going to build your first autonomous agent using the concepts of loop engineering, using Claude code, the goal command, and routines. We're going to talk about what loop engineering actually means, and then we're going to implement it for real using a Claude code goal command. And then we're going to build our first autonomous agents by combining the concepts from loop engineering into a Claude code routine. Even though we're using Claude code, you do not need to know how to code. The only prerequisite here is setting up Claude code. So, if you haven't done that, click on this link or go to my YouTube and search Claude code tutorial for beginners so that you can set it up.
Let's just talk about what loop engineering means. So, the typical way people do things is they prompt AI, could be chat, it could be Claude, they type, they read the answer from AI, and they type again, they read the answer from AI, you type again. So, in that case, you are actually part of the loop. Loop engineering, all it really means is taking you out of that loop and building a little system that does the prompting for you, meaning it checks the AI's work, and then it decides what the next step should be. And when I say it, I mean another AI agent. So, now we're going to have two AI agents, one doing the work, and the other one doing what you would have done, which is review the work and then decide what the next step should be. There have been different ways to do this. Like, for example, I often will append this to the end of a complex prompt, "Don't stop until dot dot dot." But now, with Claude code goals and routines, there are more formalized ways that you can do this.
There's six key concepts in what people are calling loop engineering today. So, the first one is automations. So, all we mean by automations is like there's some kind of schedule, and then your AI agent runs, and it completes certain tasks, and it's running by itself. So, instead of you sitting there every time and telling AI, "Here's what you should do, the loop is running on its own. It's running by itself on a schedule or you can trigger it with an external event." So, that's automation.
The second part of the loop is called work trees. And this The concept here is when you have many different AI agents and they're all working on the same project, they can easily conflict. So, what you want to do is give each agent its own lane. If you have like six agents all working on the same project, changing the same files, it's very likely to end up in a complete mess. What you want is different work trees for each agent. You don't actually have to implement this yourself. It's now part of cloud code and tooling, but conceptually, this is a really important concept because once you're orchestrating multiple agents, you want each one to have its own lane, its own work tree, so it can safely make changes without disrupting the work of other agents simultaneously.
Now, concept number three is skills. You can think of them as a playbook. Let's say you reply to customer support tickets a certain way, you want a playbook that the AI agent can follow so it can consistently reply to customer support tickets the exact same way that you would. So, a skill.md just formalizes whatever your playbook is. For example, how you want to name things, the conventions you want the AI agent to follow, the mistakes that it should never make, any constraints or guardrails. You would include all of this in your skill.md file or your playbook. So, you teach AI once and it will follow this playbook skill every single time.
Key concept number four is connectors. You can think of this as AI being able to use the tools that you use every single day, such as Gmail, Slack, Intercom, etc. Connectors allow your agents to go implement the fix for you. Like it'll fetch your code base, find the bug, try to fix it, add helpful comments, and check it back into your code base. So, when you connect your AI agent to connectors, it can basically use all of the tools that you use.
Concept number five in loop engineering is sub-agents. This one is really important. So, the easiest way to think about it is you have two agents, the one who's actually doing the work, the maker, and then a second agent, the checker. And the reason why you want to have two separate agents is because one agent will do all of the work, and the second agent will independently review it. If the checker says, "Hey, this isn't good enough, or this isn't ready yet," it's going to tell the maker, "Here's why, and here's what I think you should do next."
So, the final concept in loop engineering is memory, and you can think of this as like a shared notebook, so that your AI agents on each run has context on what's been done, what else needs to be done, what should I do next. Now, practically, when you hook up Claude Code to your GitHub repo or your GitHub project, that serves as a sort of memory. For example, in my social media posting project, my agent tracks like all of the posts it's made, like it has a little log file that tracks that. The reason this is important is without some kind of shared notebook across all of your agents, every run would start from zero. Like it really wouldn't know what the previous agent has already accomplished, what blockers they're running into, and what it should do next. Yeah, I will caveat this. It sounds simple, but actually the hardest part is defining the checker. Let's take a social media post for example. How do you define what a good post is? Defining what good and done looks like is the hardest part of creating the loop.
So, now we're going to dive into the actual practical part of this tutorial. So, make sure you have Claude Code open. The very first thing we're going to do, just think about a task you repeat every week. So, when do you start the task? Is it a certain time of day? Is it when an email arrives? And then define what done looks like. So, for example, in the morning at 8:00 a.m. I want to go through all my emails and label them accordingly, surface the three most urgent ones to my attention by DMing me on Slack. And then here's the check, how the AI proves it's done. That would mean like every email it has been labeled or archived. So, think about this for one task that you repeat every single week.
Here's how you type it. You just type {slash} goal and it should turn blue and then you can see here it's trying to help you with documentation, like what is the condition you want AI to keep going until this condition has been met. So, here's a simple example we're going to do. Sort every file in my downloads folder into subfolders by type. Keep going until no files are left. Do not delete anything and stop after 30 turns. Let's just paste this, run it and see what it does. So, now it's found 17 files, counted how many are in each category. Now it's creating the folders and moved everything turn by turn, okay? And pretty much done, found 17, let me to create the folders and move everything. All files moved, zero remaining at the top level. Now it's going to verify its work, verifying the counts. Done, your downloads folder sorted, no files left at the top level, nothing deleted. Boop boop boop. Okay, and then you can see goal achieved. Here is how like that prompt was structured. So, Claude was moving each file at a time, checking what's left and moves on to the next file and repeats. There were three things that made this like a good goal prompt. We have [music] a clear end state, right? Like keep going until no files are left. It had a check it can run, right? Counts the loose files and still in the folder and a guardrail do not delete anything and stop after 30 turns. Here's our goal, sort everything, keep going until blank. This is the end condition. So, when you type this, the small fast model, which is default Haiku, is going to check that no files are left. Like that's one of the goal conditions that it must check. And these are constraints, like don't delete anything and stop after 30 turns.
So, here five intermediate level examples. You don't have to run them right now, but I'm just giving you ideas of what else you can do. Standardizing a lot of messy files until every name matches specific formats. For example, I have a ton of invoices and receipts. So, you can rename them all in this particular format in date order and keep going until no file has its original name. Do not delete or move anything and stop after 25 turns. So, this is one The end state here, like what is the goal condition that our checker agent can verify? We have zero files left with the old style name. Practical example number two, categorizing a spreadsheet until no row is missing a label. Here's practical example number three, working through a stack of documents until none are left. Practical example number four, cleaning up a bunch of social media captions until they fit all of your brand voice rules. And then, this one is turning a list of rough ideas into hooks until the list is done. Turn each of these ideas into hooks, keep going, don't change other files, and stop after 30 turns.
Here's the cheat sheet number two. So, this is just generally the framework to think about when writing your goal prompt. /goal, what done looks like, checked by how? Like, how do you prove it? Is it a count? Is it that all of your tests pass? Is it that your you have zero bugs in this area? And stop after X number of turns. So, practice that, like try it with some of these examples. You can tweak them so it makes sense for your use case or industry, but like really get in the hang of thinking in this way. You want to think in terms of loops where there is a verification step in the task itself. Cuz a lot of people actually don't ever add a verification step.
Now, we're going to build our first autonomous agent with a Claude code routine. Okay. So, click new routine and then you should have a form that looks like this. This is the name of the routine. These are the instructions. We're going to read all of your unread emails, figure out the three most important ones, and send a Slack message to myself, and do not reply with anything. This is the constraint or guardrail. This is where you can select a project. This is where you select the model, and this is the trigger. When do you want this loop to run? Just click schedule and then run daily at 9:00 a.m. You can edit this as well. And then connectors here is what this loop will have access to. So, remember one of the key concepts of loop engineering is connectors, the ability for your AI agent to use tools you use. For this example, we're just going to use Gmail and Slack. To add connectors, you can click add connector here. And we will cover how to add tools that don't have these nice [music] connectors. Click save, so then you'll have it here. This is where you'll see all of the routines you have running. So, obviously I just created this one. You can test it by clicking run now. You can actually click this to expand it and see what it's doing. Okay, so that one finished running. So, you can see check mark here today at 12:44 p.m. So, let's go to my Slack. Here are my top three unread emails. You can see the timestamp is literally right now. Someone sends a long book excerpt. So, these are my top three most urgent emails. It was sent to my Slack. Okay? And again, you can open the conversation here. You can continue the conversation if you want to update anything, and you can update the routine itself. So, once you create it, it's kind of going to look like this. Click this pencil button in the top right corner if you want to go ahead and update it again.
Here are some intermediate-level examples. Let's say you do have like thousands of unread emails, it can completely sort your inbox, label every single email, and archive the ones you don't want, okay? So, you can set that up as a routine running on a daily or a weekly basis.
Now, I'm going to show you a real example of a Cloud Code Loop including the main agent that does the work and the checker agent that independently reviews the work. So, it's going to be these two. This one everyday runs at 8:00 a.m. and cleans up support tickets and also surfaces any issues and gives product roadmap recommendations. This is the checker, so it will review all of the closed tickets that were closed by this agent and confirm they should have been closed. Here's what this looks like. So, it's actually not that much longer, but it utilizes different things. I have a skill already in this GitHub project. By the way, this is where you can add your GitHub projects. So, run the clean up ticket skill on all open customer support tickets using the Intercom API. Provide a summary in Slack #support channel, and when referencing conversations, always provide the full link so I can easily click and open it. Do not delete tickets. Here are constraints and guardrails, and do not stop until you've processed all currently open tickets. Here's the trigger. This runs daily at 8:00 a.m., and then here my connectors Intercom and Slack. In this routine, I also actually have an API key. So, what you can do is you can create a separate environment that stores like your environment variables. So, the default environment for me does not have any environment variables, and then my support environment contains my API key for Intercom. And the reason for that is using the Intercom API, I have access to a lot more things than using the Intercom MCP. For example, the Intercom MCP does not allow me to close open tickets, but the Intercom API does. So, for those of you who are feeling limited by connectors or you want to integrate an API that doesn't have a connector, you can just create a new environment like click add environment, and then you can put your environment variables here. So, let's say this is our research environment, and we want to put our Perplexity API token equals and then put the token here.
This is the maker agent, the primary one doing the work classifying tickets, analyzing them, and then I have the checker agent here. So, this will run about 2 hours after the other one, and its job is to independently verify all of the support tickets that were automatically closed today. Confirm that each ticket should remain closed. If the support responses received by a customer do not clearly solve their problem, reopen the ticket. So, again, in loop engineering, the concept here called it sub agents. One primary agent do the work and another agent to verify the quality and accuracy of the work. So, this is the checker agent that helps verify it. So, it's set up similarly. The only difference really is it runs 2 hours after the first one runs cuz the first one takes a while to actually process all of those tickets.
Here's a cheat sheet number three. Think about when should it run? What is the trigger? What should it do? Fill that in here. What are the tools it needs? Connectors and API. Make you can make a list here. And what is the limit that you want it to have? Like don't reply to emails or don't delete something. Think about this cheat sheet and fill it out, and this will help you create the Cloud Code routine.