loop engineeringagentsmomentum

Entering the world of loops

A video about loop engineering sent me down a rabbit hole. Every good process I could think of turned out to be a loop, some with smaller loops tucked inside. Here's how I think about it now, what dynamic loops are, and where Momentum fits.

A while back I was watching a YouTube video about loop engineering. It was about AI agents, mostly: how the cycle an agent runs (look, decide, act, check, go again) matters more than any one prompt you give it.

Somewhere in the middle of it my ADHD kicked in and I stopped paying attention. But as the video turned into background noise, something else clicked.

Every good process I could think of is a loop.

Not just agent stuff. Everything. How a team ships content. How sales follows up. How support handles a ticket. How I build software. The ones that work all go around and come back to where they started, a little smarter than last time. And the ones that don't work usually have a missing piece of the loop, most often the part where somebody checks whether it actually worked.

I'm not great at explaining this stuff in the abstract, so let me just show you.

#A loop is a process that learns

Here's the simplest version:

Notice what's going on. Decide what to do about it. Do it. Check whether it worked. Then go around again, and the next decision is better because of what the last check told you.

A straight line does the first three and stops. That's the difference. A straight line can be fast, but it can't get better on its own. A loop can.

#Real examples

Content. You plan a post, write it, publish it, and then look at how it did. What people read, where they dropped off, what got shared. That feeds the next plan. A content team that skips the last step is just publishing into the void and calling it a strategy.

Sales follow-up. Reach out, see who answered, adjust the message or the timing, reach out again. The good reps do this in their heads without thinking about it. The process only works if the "see who answered" part actually changes the next move.

Support. A ticket comes in, someone answers it, the customer replies or doesn't. Zoom out and there's a bigger loop: the same question keeps showing up, so someone fixes the docs or the product, and that question stops coming in. Same work, two loops running at different speeds.

Hiring. Write the role, interview, hire, see how the person does after a few months. If nobody ever goes back and asks "did our interview actually predict this?", the hiring process never improves. It just repeats.

#Loops inside loops

This is the part that really got me. A lot of the time, one step in a loop is its own loop.

Take the content example. "Write the post" isn't one action. It's draft, review, fix, review again, until it's good enough to ship. That whole thing lives inside one box of the bigger loop.

The outer loop runs maybe once a week. The inner one might go around five times in an afternoon. Different speed, different people, different idea of "done", but the same shape.

Once you start seeing this you can't stop. Any step that's hard enough to get wrong usually turns into a little loop of its own: try, check, adjust. That's just what doing something carefully looks like.

#Even one-shot things live inside a loop

The obvious pushback is that some things really are one and done. You file taxes once a year. You launch a product once. You write one contract.

But each of those sits inside something bigger that should be a loop. Filing taxes is one step in a yearly loop of tracking money, filing, and then looking at what you'd do differently next year. A launch is one step in a loop of build, launch, learn, build again. The contract is one pass in a loop of how you do deals.

Here's the taxes version. The yearly loop goes around forever, and one of its spokes is a straight shot that starts and finishes while the loop keeps going.

The one-shot part is fine. The problem is when nobody owns the bigger loop around it, so every year it starts from scratch and the same mistakes come back.

#The check is where a loop gets smart

Most processes people write down treat the check as a formality. Did it work? Okay, next. But the check is where a good loop makes its real decisions:

  • Failed? Don't start over. Fix that one thing and check again, as many times as it takes.
  • Nothing changed? There's no reason to run the full process again just because it's on the calendar. Wait longer before the next pass.
  • Worked? Go around again, with whatever you just learned.
  • No progress at all? Stop and say so, instead of spinning forever pretending to work.

Same loop every time, but the check decides which way the work goes next.

That last one I learned the hard way. When I was building StateFrame, the agent loop had all of these problems in miniature. It reread the same files over and over because of a bug in what my loop showed it. It sometimes didn't realize it was already done. Teaching it to notice when it was stuck, and to stop instead of burning money, mattered as much as anything about the model. The full story and numbers are in StateFrame so far. The short version: when an agent looks dumb, check the loop first.

#Dynamic loops

Then I started thinking about what bounded autonomy actually looks like in practice. Surprise, surprise: it looks like dynamic loops. Loops that change and adapt over time, on their own for the small, low-risk stuff, and with a person signing off on anything that actually matters.

Everything above is still one fixed loop. The steps never change, only the path the work takes through them. A dynamic loop goes a level further: it looks back at how it's been doing across many passes and changes itself.

  • It adds steps that keep proving necessary. If the same kind of problem slips through every time, the loop grows a check for it.
  • It drops steps that never catch anything. A review that hasn't found a problem in months is just slowing things down.
  • It retunes its own rhythm. If weekly turns out to be too slow to catch problems, it moves to daily. If daily is mostly noise, it backs off.
  • It asks before anything big. Small, reversible changes it can make on its own. Anything with real consequences becomes a proposal that waits for a person.

Say a content loop notices that posts without a fact check keep getting corrected after they go out. Adding a fact-check step is small and easy to undo, so it just does it and tells you. Now say it notices a whole category of posts never performs and wants to stop writing them. That's a real decision about the business, so it goes to a person.

That second loop, the one that improves the first, is the part I think most processes are missing entirely.

#Signs it's a line pretending to be a loop

Plenty of processes look like loops on paper and act like lines in real life. A few tells I've learned to watch for:

  • Reports get made and nobody reads them. The checking happens, but it never reaches the next decision.
  • The same mistake keeps coming back. Every quarter, same problem, same surprise.
  • Retros happen and nothing changes. Everyone agrees on what went wrong, then next time runs exactly like last time.
  • Metrics get tracked but never move a decision. If the number went the other way, would anyone do anything differently?
  • Nobody owns the bigger loop. Each step has an owner, but no one is responsible for whether the whole thing is getting better.
  • It runs on the calendar, not on what's happening. The meeting happens every Monday whether there's anything to talk about or not.

#Where this is going: Momentum

This way of thinking is basically what the Momentum Engine is built on.

Momentum is the next thing I'm releasing. It treats a business as a set of loops, one for each part of the company, each running on its own rhythm. Each one notices what's changing, decides whether anything deserves a move, makes the small moves people have already approved, brings the bigger ones to a person, and then comes back later to check whether the move actually worked. That last step is the whole point. Every move it makes comes with a prediction, and it gets scored against what really happened.

And yes, there are loops inside those loops.

I wrote a little about it in Day 1 and in the mission. I'll go much deeper when it ships, with the same rules as everything else here: what I measured, what still breaks, and what I only believe so far.

#The short version

Good processes are loops. Big ones have smaller loops inside them. The best ones change shape as they go. And the step people skip most, checking whether it worked, is the one that makes the whole thing improve.

If you run a team, try drawing one of your processes as a circle instead of a list. I'd bet you find the gap pretty fast.