Loop Engineering: The Part of Agents Nobody Talks About

Everyone is obsessed with prompts. The real leverage is in the loop.

What Loop Engineering Actually Is

There is a term making the rounds right now. Loop engineering. People are describing it like it is a frontier, something new to figure out. I had a funny moment with it. I went digging, fully expecting to find something I needed to go learn. Instead I found something I had already built. Not in a slide deck. Not in theory. Running in production on my platform every day across multiple agents. The trend caught up to me, not the other way around.

For two years the whole conversation has been about prompts. Write the perfect instruction, get the perfect answer. Prompt engineering. Prompt libraries. Prompt marketplaces.

But a prompt gets you one answer. One shot. The model reads, the model replies, the model stops.

That is not an agent. That is a very smart vending machine.

An agent is what you get when you wrap that single reply in a loop. Think, where the model looks at the goal and the current state. Act, where it calls a tool, runs code, hits an API, reads a file. Observe, where it reads the result of what it just did. Then Repeat, where that result goes back in and it decides the next move.

Loop engineering is the discipline of designing that cycle. Not the words you send, but the machinery around them. How many times does it iterate? When does it stop? What happens when a step fails? What does it remember between turns? What is it allowed to do, and how many times?

Why the Loop Is the Whole Game

A single model call is stateless and bounded. It cannot go wrong in interesting ways. But the moment you put it in a loop, you have built something that can self-correct, chain steps it could never do in one shot, and work while you are asleep. Those are the superpowers. But every one of them is also a failure mode if the loop is not engineered.

An agent that self-corrects can also loop on the same error forever. An agent that chains steps can chain into a cycle. An agent that works while you sleep can also spend $400 while you sleep.

So the four things that actually define a well-engineered loop are not glamorous. They are a stop condition, a bound, guards, and no accidental cycles. That is it. That is loop engineering. Mundane, and everything.

How I Already Built It: Three Loops, Three Lessons

Here is the part that made me sit up. When I went looking for loop engineering I found it already running in my own codebase at XYZAgents.ai. The receipt is the code.

1. The Bounded Reasoning Loop

Mona is my wellness agent. When you talk to her, she does not just reply. She runs a tool-use loop. Here is the actual shape of it from the codebase:

let iterations = 0;
const MAX_ITER = 6;              // the stop condition

while (iterations < MAX_ITER) {
  iterations++;

  // THINK: ask the model what to do next
  const data = await callModel({ tools: TOOLS, messages: apiMessages });

  // DONE? model says it is finished, break the loop
  if (data.stop_reason === "end_turn") { finalText = ...; break; }

  // ACT + OBSERVE: run the tool, feed the result back
  if (data.stop_reason === "tool_use") {
    apiMessages.push({ role: "assistant", content: data.content });
    const toolResults = await runTools(data.content);
    apiMessages.push({ role: "user", content: toolResults });
    continue;                    // repeat
  }
}

That is the textbook agentic loop in about fifteen lines. Think, act, observe, repeat. The continue is the magic. When Mona decides she needs a tool, she runs it, appends the result back into the conversation, and loops, so on the next pass she is reasoning with the information she just gathered.

2. The Bounded Action Loop

Reasoning loops are one thing. Loops that take action on the world are where bounds stop being optional. My autonomy agent runs on a schedule, scans my repos, and acts on the ones that are flagged. But it does it under a hard cap. MAX_ACTIONS_PER_RUN = 5. Even if forty repos are flagged, one run touches at most five. The loop physically cannot run away.

This is the difference between a reasoning loop and an action loop. A reasoning loop that over-iterates wastes tokens. An action loop that over-iterates changes things. Branches, files, notifications. So the bound here is not about cost. It is about blast radius. You cap an action loop not to save money, but to make a runaway impossible.

3. The Loop That Hands Off Without Forming a Cycle

The most subtle part of loop engineering is not a single loop. It is what happens when loops connect. When the autonomy run finishes, it hands off to another agent, the digest agent that summarizes what happened. That is a cross-agent trigger, and cross-agent triggers are exactly where loops turn into cycles. Agent A wakes agent B, B wakes A, and now you have built a perpetual motion machine that bills by the token.

So that handoff is engineered to be safe in two ways. First, it is strictly one-way. Autonomy calls the digest, the digest never calls autonomy back. No cycle can form. Second, it is wrapped in a guard, a Promise.race with a 15-second timeout, so if the digest hangs, the autonomy run does not hang with it.

And there is a third layer that I am genuinely proud of, because it is the kind of bug you only catch after you have been burned. The digest reads from an event log to decide what to summarize. But the digest also writes its own runs to that log. See the trap? Left alone, the next digest would summarize the last digest, which would get logged, which would get summarized. A feedback loop made of data, not function calls. The fix is one line in the query: explicitly filter out its own meta-events so a digest can never feed itself.

The Principle Behind All of It

There is a single idea underneath these three examples. An agent is only as good as its loop is disciplined. Anybody can wrap a model call in a while loop. That part takes ten minutes. The skill, the actual engineering, is in everything that stops the loop, bounds the loop, guards the loop, and keeps it from eating its own tail.

What This Means If You Are Building With AI

The reason I am writing this down is that the conversation around agents keeps pointing at the wrong half. Prompt engineering got all the attention because it is the visible, shareable, screenshot-able part. But prompts are the easy half. They give you one good answer. The loop is what turns one good answer into work that actually gets done. Research finished, code fixed, repos scanned, a summary in your inbox before you wake up.

And the loop is also the part that can quietly hurt you if you do not engineer it. So if you are building anything agentic, even just stringing together a few AI tools, spend your time on the loop. Ask the four questions. Put in the ceiling, the cap, the timeout, the one-way handoff. That is not the boring scaffolding around the interesting part. That is the interesting part. It just does not fit in a screenshot.

I went looking for a frontier this week and found it already running on my own platform. Turns out the thing people are just now naming is the thing I had been forced to get right the moment I let my agents act without me watching. Loop engineering is not a trend I need to catch up on. It is the receipt for a system that is already running.

Want to see the loops in motion? The agents and the framework they run on are live at XYZAgents.ai/agents, sixteen specialists, six clusters, one hub, zero manual handoffs. But that is just one platform. If you want to see the full picture, AgentPark.io is where I track everything I am building across multiple platforms, and that number is already over 40 agents and growing. Subscribe so you do not miss what comes next. This space is moving fast and I am going to keep showing up to tell you exactly what changed, what it means, and why it matters in plain language. No CS degree required. Just curiosity and a willingness to spend a few brain tokens on the thing everyone else is just now naming.

The loops referenced here live in app/api/mona/route.js (bounded reasoning), the autonomy executor (bounded action), and the digest handoff (one-way trigger + event filtering). The bounds are deliberate. They are the whole point.