Hey Everyone!
I know. It has been a while.
The newsletter went quiet, life got crazy, and instead of pretending this was some grand content strategy, I'll just tell you what happened.
I moved from Miami back to Chicago. I got married (also in Chicago). I closed the Getting Automated community. That said, I have been spending most of my time doing the work I probably should have been focused on the whole time: making useful AI content and building serious automation systems for clients.
The community was a good experiment. I'm glad I tried it. But if I'm being honest, I just didn't enjoy running it. It didn't feel like a good fit for me, how I like to work, or what I wanted Getting Automated to become.
My best work is showing what Business AI and automation look like when the hype gets stripped away and the system still has to run on Monday morning.
So that is the direction from here: fewer grand promises, more useful breakdowns, more real builds, and more practical systems thinking.
Which brings me to this week's topic: loop engineering.
I hate AI buzzwords as much as the next guy, but when Peter Steinberger (creator of OpenClaw) AND Boris Cherny (Creator of Claude Code) speak about something pivotal in how they work with AI all within the same week, I listen.
Loop engineering is everywhere right now, and I get why people are excited. The idea is genuinely useful. But it also has the same problem every AI buzzword has: people are going to say it a lot before they define what actually makes it work.
Here’s a sneak peek of what it all entails…
And more importantly, I don't want this to just be another "here is a concept" email.
I built a free pre-loop skill you can use before handing work to Claude Code, Codex, or any agent-style coding workflow. The whole point is simple: before you tell an agent to go loop on a goal, the skill helps you slow down for five minutes and define the task, scope, verifier, stop conditions, and guardrails.
Because the truth is, most bad agent runs don't fail because the model is dumb.
They fail because we hand it a vague goal and act surprised when it wanders.
Get the free pre-loop skill:
/plugin marketplace add Getting-Automated/skills
/plugin install pre-loop@getting-automatedThis Week's Must-Watch
Loop Engineering Needs a Finish Line
Loop engineering is the hot new phrase in the AI agent world, which means it is already at risk of becoming meaningless.
But the idea underneath it is actually important.
Right now, in most AI workflows, you are the loop.
You prompt the agent. You wait. You read the answer. You decide if it was good. You tell it what to do next. Then you do that again. And again. And again.
Sometimes that is exactly what should happen. If the work needs taste, judgment, or a high-stakes decision, you should stay close to it.
But a lot of the time, you are not adding judgment. You are just typing "continue" with extra words.
That is the part loop engineering is trying to fix.
A prompt is a request. A loop is a control system.
A prompt says, "Do this thing."
A loop says, "Keep doing this thing until the work is done, prove it is done, and stop when the stop condition is met."
That sounds subtle. It is not.
The Demo Version
In the video, I show a very small demo with a repo that has intentionally broken code.
The agent gets a goal: fix the failing tests. It looks at the code, makes changes, runs the verifier, and stops when the tests pass.
Is the demo itself complicated? No.
That is kind of the point.
The interesting part isn't that an AI agent fixed a tiny bug. The interesting part is that the agent had enough structure to keep working without me steering every step.
It had a goal. It had a verifier. It had a finish line.
That same pattern gets a lot more valuable when the work is bigger:
Build a feature, test it, click through it in a browser, and prep the PR.
Fix every failing test in a repo, not just the first one.
Clean up a messy content library against a formatting standard.
Review a queue of support tickets against an SOP.
Classify a backlog of emails, leads, files, or records.
Run a QA pass until the app actually works, not until the agent sounds confident.
In those cases, the human should not be the thing saying "next" forever.
The human should define the system.
Why This Is Happening Now
For a long time, the model was the slow part.
You would ask for something, wait for the response, skim it, correct it, and wait again. Keeping a human in the middle felt natural because the tools were slower and less capable.
That is changing.
The model can often move faster than we can read, decide, and re-prompt. The bottleneck becomes the human sitting there deciding whether to say, "Yep, keep going."
That's silly when the next step is obvious.
If the agent already knows the task, has access to the files, has a verifier, and knows what success looks like, it should not need you to tap it on the shoulder every few minutes.
This is why prompt engineering isn't going away, but it's not the whole game anymore.
Prompt engineering is about getting one response right.
Loop engineering is about designing the conditions where an agent can keep making progress without wandering off a cliff.
The Part People Skip
The dangerous version of loop engineering is basically:
Go do this until it is done.
That's not a system. That's a wish.
This is exactly why I built the free pre-loop skill.
It's not glamorous. It's not trying to be a big agent framework. It's a forcing function that asks the questions you should answer before you unleash an agent on a repo, content library, queue, or messy workflow.
Instead of starting with:
Go fix this.
It pushes you toward:
Here is the goal. Here is the scope. Here is what good looks like. Here is what not to touch. Here is how to verify it. Here is when to stop.
That difference matters.
A useful loop needs a few boring things, and the boring things are what make it work:
The task: What should repeat?
The scope: What is in bounds and what is not?
The done condition: What does success mean?
The verifier: What proof says the work is actually done?
The stop condition: When should the agent quit trying?
The verifier is the piece I care about most.
Hope is not a strategy. Proof is.
For code, proof might be tests passing, a browser flow working, a clean API response, screenshots, or a PR summary with evidence.
For operations, proof might be a queue count, a saved audit file, a status change in the source system, or a reconciliation report.
For content, proof might be a checklist, a formatting validator, or a final artifact that can be reviewed.
If the agent can't prove it's done, it's not done. It's just done talking.
When I Would Actually Use This
I would use a loop when the work is broad, repetitive, and verifiable.
That is the sweet spot.
You know what good looks like.
You can define the boundaries.
You can give it examples, specs, SOPs, or tests.
You can verify the output with something stronger than vibes.
You are comfortable letting the agent make small decisions inside the box you drew.
That makes loops useful for coding work, QA sweeps, data cleanup, content migrations, support queues, inbox triage, research passes, and a lot of the operational work nobody wants to babysit.
It's not magic. It's just delegation with a finish line.
When I Would Not Use This
I would not use a loop when the definition of "good" is still fuzzy.
If you are making a brand decision, writing a high-stakes sales deck, figuring out product strategy, or doing anything where the taste and direction still needs to be discovered, don't throw it into an unattended loop and hope for the best.
Loops are great when the destination is clear.
They are a mess when the destination is "make it better."
The Money Problem
There is one more thing nobody should gloss over: loops can burn money.
The labs like this direction because more looping means more tokens. That is not a conspiracy. That is just the business model.
If you are on a fixed plan, maybe you don't care. If you are paying usage-based pricing, you absolutely should care.
A vague loop can cost $5, $50, $500, or more before you realize it has been politely spinning in circles.
So don't give your agent a blank check.
A better loop instruction sounds more like this:
Keep working until all tests pass, the browser smoke test succeeds, and the PR summary is written. Stop if the same failure repeats three times, if the budget is hit, or if a destructive action would be required.
That is the difference between an agent with a job and an agent with your credit card.
My Practical Checklist
Before I hand something to a loop, I want answers to these questions:
What exactly should repeat?
What is the outcome?
What is off limits?
What proof counts as done?
What should stop the loop early?
What requires human approval?
How much time or token spend is acceptable?
What artifact should exist at the end?
If those answers are fuzzy, the loop is not ready. Tighten the spec first.
That is what pre-loop is meant to do for you.
It helps turn "I want the agent to work on this" into a real loop brief with the things an agent actually needs:
The intent.
The scope.
The plan.
The definition of done.
The verifier stack.
The anti-goals.
The safe execution rules.
The budget and stop conditions.
If you are going to experiment with loop engineering, this is the place I would start.
Don't start by giving an agent a huge vague task and hoping it figures it out.
Start by making the loop brief better.
What This Means for Getting Automated
This is also a good example of where I want Getting Automated to go next.
I'm less interested in AI theater, well really, I never have been.
I'm more interested in the systems that actually survive contact with a real business.
That means I will still cover Claude Code, Codex, n8n, Make, MCP, browser agents, and all the tools people are talking about. But the tool is not the story.
The story is whether the thing works when there are real files, real customers, real costs, real approvals, and real consequences.
That is what I am building for clients. That is what I want to make more content about. And that is the lens I am bringing back to this newsletter.
Less hype.
More proof.
More systems that actually do the job.
Before You Go
Know that I’m actively working on my next YouTube video and am putting out new content every day on TikTok.
Was this newsletter automated? A little. But the judgment still has to be human.