What You Should Know About Loop Engineering (Part 2)
Welcome to the 60th issue of AI Agents Simplified 🍻
This issue is brought to you by HubSpot
Last week I got a bunch of replies to Part 1 that all said some version of the same thing: “okay, I get what loop engineering is now, but show me one.” Fair. A framework with no real example is just a nice diagram!
So that’s what today is.
Quick recap in case you’re just joining, or Part 1 already feels like a while ago. Loop engineering means building a system that prompts your agent for you, instead of you doing it by hand every time. We talked through the five moves every real loop makes, and the one mistake that ruins almost every first attempt: letting the agent decide for itself whether its own work is any good.
If any of that sounds unfamiliar, go read Part 1 first, this one builds directly on it and won’t make much sense without it.
If you’re caught up, here’s where we’re headed today:
Two loops actually running right now → one built by a single developer before breakfast, one running inside a company shipping over a thousand pull requests a week
What it actually costs you when a loop goes wrong → four specific costs, and none of them show up until they already have
A five-step plan to build your first loop this weekend → smaller than you think, on purpose
Let’s get into it.
Two Loops That Are Actually Running Today
This isn’t theoretical. Two public examples show the range, from a single developer to a whole company.
Addy Osmani runs a personal loop every morning: it reads yesterday’s CI failures, open issues, and recent commits on its own, opens an isolated workspace for each thing worth fixing, has one agent draft a fix and a second agent review it, opens a pull request automatically when it passes, and drops anything uncertain into an inbox for him to look at. Nothing requires him to be awake for it to happen and nothing merges without a check.
At the other end of the scale, Stripe built an internal system nicknamed “Minions.” Engineer Steve Kaliski described it on the How I AI podcast: you tag the bot in Slack or react with an emoji, and Stripe’s agents were landing around 1,300 pull requests a week with no human writing the code, just humans reviewing it. The trick isn’t a smarter model. Before the agent even starts “thinking,” a separate, hard-coded system gathers the relevant tickets, docs, and code so the agent isn’t left guessing at its own context. Anything that can be handled by predictable, rule-based logic never gets handed to the probabilistic model. The humans didn’t disappear from the process, they moved from writing code to reviewing it.
Same five moves, wildly different scale. That’s the point! Loop engineering isn’t a specific tool, it’s a shape you can build small or big.
What It Costs You If You Get It Wrong
None of this is free, and the costs don’t show up while things are going well, that’s exactly what makes them dangerous.
Verification debt. Every PR the loop opens without a real check is a small loan against your future time. It looks fine today because the tests that exist are green. The problem lives in what the tests don’t cover, and it compounds quietly until it all surfaces at once.
Comprehension rot. The faster a loop ships code you didn’t write, the bigger the gap between what your codebase actually is and what you think it is. You stop reading line by line because the loop took over the writing, and your mental map goes stale while the code keeps moving.
Cognitive surrender. This is the psychological version of the first two. Once a loop runs reliably enough, it’s tempting to stop having an opinion about what it hands you and just click merge. The more you trust it, the less you look. The less you look, the less you’re able to judge and that’s a slope, not a step.
Token costs. Autonomous loops spawn their own sub-agents, retry on their own, and run on a timer whether you’re watching or not. One stuck loop, retrying all night, and you wake up to a bill instead of a fixed bug. Set a hard budget cap and a max-retry limit before you ever let a loop run unattended, don’t find out the ceiling exists by hitting it.
The uncomfortable truth underneath all four is that a loop doesn’t have opinions of its own. It amplifies whatever you bring to it. Bring good judgment and habits, and it scales your judgment. Bring the desire to never think about this again, and it scales that just as efficiently.
Unlock Your Next Income Stream: 100 Side Hustles for Ambitious Founders
In a world where financial freedom feels like a distant dream, smart women are building wealth on their own terms.
Finally, a curated database of 100 proven side hustles (that actually work)
Each idea comes with required startup costs, time investment, and potential earnings
Exclusive insights from founders who've turned side gigs into 6-figure empires
Detailed skill requirements so you can match your talents to the right opportunity
Bonus: Priority scoring system to identify which hustles align with your lifestyle
Don't let another month slip by watching others build their empire. Your next income stream is hiding in our database, waiting to be discovered.
Should You Actually Build One? Start Smaller Than You Think
You don’t need Stripe’s setup to get value from this. Start with something that barely looks like a “system”:
Pick one recurring, low-stakes check. Something like “did CI pass overnight” or “summarize new issues.” Not your production deploy pipeline.
Give it memory. A single markdown file the agent reads at the start and updates at the end is enough to make runs build on each other instead of starting from zero.
Add a second agent to check the first one’s work, before you add anything else. This is the step people skip, and it’s the one that matters most.
Only then, schedule it. Claude Code has /loop for time-based reruns and /goal for condition-based stopping; Codex has an equivalent Automations tab. Both platforms also support isolating parallel agents in separate git worktrees so they don’t overwrite each other’s changes, and both support MCP connectors to plug into tools like your issue tracker or Slack.
Set a spending cap and a human checkpoint, before you let it run while you sleep.
If you want it to run even with your laptop closed, you’ll need cloud-based scheduling (Claude Code’s Cloud Routines, or a GitHub Actions cron trigger) rather than a local scheduled task, local automations stop the second your machine sleeps.
The Real Skill Hasn't Changed
Here’s the thing worth sitting with. Generating code, plans, and pull requests has become nearly free. When something can be produced without limit, it stops being the scarce resource.
What’s still scarce is judgment, knowing which output is actually right, not just plausible-looking. A loop can generate a hundred options. It can’t tell you which one is correct; it can only tell you which one looks reasonable to it. That gap is exactly why you still need to be involved.
Two people can build the identical loop and end up in opposite places six months later. One person used it to move faster on work they already understood, kept reading the output, and got sharper. The other used it to avoid ever having to understand the system again, stopped checking, and quietly became a stranger to their own codebase. Same tool, same code, the difference was whether they stayed the engineer or just became the person who presses go.
Build the loop. Just build it like someone who still plans to know what’s happening inside it.
The Only Insurance That Can Make You Richer
Most insurance costs you money. But there’s a kind that can pay you when the stock market drops. One example turned $200 into $2,000 during a downturn. And you don’t even need to own stock to use it!
It protects your portfolio and can generate profits when stocks fall. You’ll find the step-by-step breakdown in this free guide. It's simple, fast to read, and made for regular, at-home investors…
And today, it’s totally free, but won’t be for long.
What’s Next
That’s Part 2. If Part 1 was about understanding the shape of a loop, this one was about watching two working examples, seeing what breaks when nobody’s checking, and having an actual plan to build one yourself.
Here’s the thing I want you to sit with more than any tactic in this post: the tools got faster, but the job didn’t get easier, it got narrower. Writing code was never really the scarce skill. Knowing which code is right was. Loop engineering doesn’t remove that skill, it just makes it more obvious when you don’t have it.
So build the loop. Give it memory. Make the evaluator genuinely skeptical before you make anything else fancier. And check on it, not because you don’t trust it, but because that’s the part of the job that’s actually still yours.
Before you go, I wanted to share a quick note about an event I’ll be attending at the end of July. The Packt team has been kind enough to offer AI Agents Simplified readers a 40% discount code, so if you’re interested, you can check it out too.
Build AI Agents That Reason Over Connected Knowledge
Production AI needs to connect evidence across sources, reason through relationships, and remember what it has already discovered.
Join the live, hands-on Building Intelligent AI Agents with GraphRAG workshop led by David Knickerbocker, and learn how to build agents that run multi-step investigations, maintain investigation memory, answer follow-up questions, and use graph, timeline, sentiment, and geospatial tools for deeper insights.
Move beyond basic retrieval and start building AI systems designed for complex, real-world questions, guided by an expert at the forefront of GraphRAG innovation.
As an AI Agents Simplified subscriber, you can get 40% off with code AIAGENTS40.
Seats are limited. Secure yours before the offer ends.
You’ll also receive:
One complimentary Packt eBook worth $70
A Packt Certificate
Recording access
Join us and learn how to build AI agents that do more than retrieve documents.
Let’s Connect
If you build one this weekend, I’d genuinely like to hear how it went, what broke, what surprised you, what you’d change. Find me on LinkedIn or reply to this post.
See you in the next one!












Part 2 makes sense as a natural follow-up, curious how you're handling the retry/failure boundary once the loop runs past the first couple of iterations.
I built awesome-agent-architecture, which breaks agent loops (including error recovery) into runnable Python examples.
https://github.com/hardness1020/awesome-agent-architecture/tree/main/sections/21-loop-engineering