Stop Prompting Your AI. Start Engineering Loops.

The bottleneck in AI-assisted work is no longer the model. It's you.

I say this as someone who uses these tools every waking hour. I run a software company and a publishing operation as a solo operator. Multiple products, multiple sites, a content pipeline, monitoring I built myself. The models got good enough a while ago. What didn't scale was me sitting in the chair, typing the next prompt, reading the output, deciding what to do, and typing the prompt after that.

That pattern has a name: you are the loop. The model does the thinking in the middle, but you do the observing, the verifying, the scheduling, and the deciding-what's-next. Every agent workflow that dies in production dies for this reason. Not because the model was too weak, but because a human was load-bearing in a place where no human wants to stand at 2 a.m.

The fix isn't a better prompt. The fix is to stop being the loop and start engineering one.

What a loop actually is

Picture this: at 2:47 a.m., a system notices a broken dependency, fixes the failing tests, opens a clean pull request, and goes back to sleep. You find out over coffee and click merge. Nobody wrote a prompt at 2:47 a.m. Somebody wrote a loop, weeks earlier.

That's the shift. A prompt is a one-shot request. A loop is a closed cycle that runs without you in the middle:

1. Observe. Discover the work. A queue, a webhook, a cron tick, a failing check, an unread inbox.
2. Reason. The model decides what to do about it, with real context.
3. Act. Execute through a harness of tools with a controlled blast radius.
4. Verify. Something other than the actor checks the result.
5. Persist and schedule. Write down what happened, decide when to run again.

Most "agents" people ship today do steps 2 and 3 and skip the rest. That's not an agent. That's a prompt with extra steps, and it fails the same way a prompt fails: silently, confidently, and while you're not looking.

The one rule I'd tattoo on every agent architecture

If you take a single idea from this post, take this one: the thing that builds must never grade itself.

Ask a model to write code and then ask the same model, in the same context, whether the code is good, and you'll get a yes. Of course you will. It's grading its own homework with its own rubric while holding its own red pen. The failure isn't dishonesty; it's shared blind spots. Whatever assumption produced the bug also produces the approval.

Generator/evaluator separation fixes this. The evaluator is a different process, with different context, ideally with a different disposition: skeptical, narrow, empowered to reject. In my own pipelines, the single biggest jump in reliability didn't come from a better model or a cleverer prompt. It came from splitting "do the work" and "check the work" into separate runs that don't share a context window.

This is also why loops beat one-shot prompts even when the model is identical. A one-shot prompt gets one chance to be right. A loop gets to be wrong, get caught, and try again before you ever see the output.

What a minimal loop looks like

Strip away the frameworks and a production loop is embarrassingly small. Here's the skeleton in Node.js:

async function runLoop() {
  const task = await discoverWork();        // observe: queue, cron, webhook
  if (!task) return scheduleNext(IDLE_INTERVAL);

  const state = await loadState(task.id);   // persist: memory across runs
  const plan = await generator(task, state); // reason
  const result = await harness.execute(plan, {
    allowedTools: task.policy.tools,        // act: bounded blast radius
    timeout: task.policy.timeout,
  });

  const verdict = await evaluator(task, result); // verify: separate context
  if (verdict.pass) {
    await commit(task, result);
  } else if (state.attempts < task.policy.maxAttempts) {
    await saveState(task.id, { ...state, attempts: state.attempts + 1, feedback: verdict.reasons });
    return scheduleNext(RETRY_INTERVAL);    // loop back with the critique
  } else {
    await escalate(task, verdict);          // know when to stop
  }

  return scheduleNext(NEXT_INTERVAL);
}

Every line of that skeleton is a design decision people skip. What counts as work? What tools is this task allowed to touch? Who verifies, and with what context? How many retries before a human gets paged? Skip any one of them and you've built a demo. Answer all of them and you've built infrastructure.

Notice what's not in there: a human. You show up at the escalation point and nowhere else. That's the whole point. Your attention becomes the scarce resource the system spends deliberately, not the glue holding every iteration together.

Where this bites you

I'll be honest about the failure modes, because the agent hype wave mostly wasn't.

Loops without backpressure will happily discover infinite work and burn your budget doing it. Loops without blast-radius control will act on things you never intended to be in scope. Loops without independent verification will ship confident garbage on a schedule, which is worse than shipping it manually because now it's automated garbage. And loops without a stop condition don't stop.

None of these are model problems. They're systems problems, and they have systems answers: task policies at the entry point, worktree isolation for anything that mutates state, circuit breakers, cost ceilings, and escalation paths that treat the human as a deliberate fallback instead of an accident.

That's engineering. Which is exactly why "prompt engineering" was always the wrong name for the discipline that matters. Prompts are an input format. Loops are an architecture.

The book

I just released Loop Engineering, and it's the manual I wanted two years ago: practical and code-heavy, written for people who are tired of brittle agent demos that die on contact with production.

It covers the full anatomy in depth: triggers and work discovery, execution harnesses and MCP tool integration, memory tiers and persistent state, scheduling and retries and escalation, generator/evaluator separation, and governance and cost control for when your loops multiply. There are ten core loop design patterns (ReAct, Supervisor, Circuit Breaker, and more), real case studies including inbox automation and autonomous PR pipelines, and a step-by-step build of your first production loop, along with the failure modes that will bite you on the way there.

The examples run on Claude, Grok, OpenAI, and custom MCP setups, because the architecture matters more than the vendor.

If you read Building AI Agents from Scratch with Grok, this is the orchestration layer that sits on top: less "how do I make an agent" and more "how do I make agents I can walk away from."

Loop Engineering is available now on Amazon.

The era of hand-crafting every prompt is over. The teams and solo operators who win the next few years won't be the ones with the best prompts. They'll be the ones whose systems were working while they slept.

Stop prompting. Start engineering loops.