Loop Engineering: the next era of AI

Every generation of AI tooling has been defined by what engineers had to get good at next. First it was prompts. Then context. Then the harness around the model. Now it's the loop — the thing that turns a smart response into a finished outcome.

If you've built anything with AI over the last few years, you've lived through this progression even if nobody named it for you. Each era didn't replace the one before it — it sat on top, because the earlier skill was still necessary, just no longer sufficient on its own.

Era 1: Prompt Engineering

In the beginning, the entire interface to AI was a text box. The model had no memory, no tools, and no sense of your codebase, your company, or your task beyond what you typed. So the craft was entirely about the prompt: word choice, examples, formatting, "act as an expert," chain-of-thought hints, few-shot demonstrations.

Prompt engineering was real skill — small wording changes could swing output quality dramatically — but it had a ceiling. A perfect prompt still failed if the model didn't have the right information to answer with. You can't prompt your way around missing context.

Era 2: Context Engineering

The next unlock wasn't a better prompt — it was better inputs. Retrieval-augmented generation, embeddings, document chunking, system messages, memory files: the discipline shifted from "what do I say to the model" to "what does the model need to see to say the right thing back."

Context engineering asks harder questions than prompting does: What's relevant right now? What's stale? What fits in the window? What should be summarized versus included verbatim? Teams that got good at this stopped fighting the model and started feeding it — and answer quality jumped because the model was finally reasoning over the right facts, not guessing at them.

But even a model with perfect context is still just answering one question at a time. It can tell you what to do. It can't do it.

Era 3: Harness Engineering

This is where AI stopped being a chatbot and started being an operator. A harness is everything wrapped around the model that lets it act: tool definitions, function calling, file access, a shell, a browser, permission boundaries, error handling when a tool call fails.

Harness engineering is why an AI can now read a file, edit it, run a test, see the failure, and try again — instead of just describing what you should type. The model provides judgment; the harness provides hands. Get the harness wrong — too few tools, unsafe defaults, no error recovery — and even a brilliant model produces brittle, unusable behavior. Get it right, and the model can operate inside real systems instead of talking about them from the outside.

Most of the current wave of "AI agents" is really harness engineering wearing a new name. And it's necessary. But a harness with a great model still only executes one instruction at a time unless something ties those instructions together toward a goal.

"Prompting tells the model what to say. Context tells it what to know. The harness tells it what it can do. The loop tells it when to stop."

Era 4: Loop Engineering

This is the era we're in now. A single prompt, however well-crafted, and a single tool call, however well-harnessed, still only gets you one step. Real work — a feature shipped, a bug fixed, a report generated, a month of performance data turned into a fair rating — isn't one step. It's a sequence: try something, observe the result, decide what's still missing, adjust, try again, and know when to stop.

Loop engineering is the discipline of designing that sequence deliberately, instead of hoping the model figures it out inside one giant context window. It covers:

• Termination conditions — what "done" actually means, so the loop doesn't run forever or stop too early.
• Feedback signals — what the system checks after each step (a test result, a diff, a metric, a human approval) before deciding what to do next.
• State across iterations — what gets carried forward, what gets discarded, so the loop doesn't repeat its own mistakes.
• Escalation paths — when the loop should stop looping and hand control back to a human, instead of confidently going in circles.
• Cost and time budgets — because an unbounded loop is just an expensive way to be wrong slowly.

A well-designed loop is what separates an AI that answers a question from an AI that finishes a job. The prompt, the context, and the harness are all still there — the loop is the layer that decides how many times to use them, and in what order, before calling something complete.

Why this era matters more than the others

Each earlier era made a single AI turn better. Loop engineering is the first era that makes an entire outcome reliable. That's a different kind of problem — closer to systems design and operations than to writing or retrieval — which is why it tends to trip up teams who mastered the first three eras and assumed the model would "just handle the rest."

It won't, on its own. A model with a great prompt, rich context, and a full toolbox will still spin — repeating a failed fix, declaring victory too early, or burning budget on a task that needed one human decision five steps ago. The loop is what catches that. It's the part of the system with a memory of what's already been tried and an opinion about whether trying again is worth it.

What Loop Engineering looks like in practice

You don't need to be building an AI company to feel the difference. A few concrete patterns:

1. Generate → verify → repair. The model produces an output, a deterministic check verifies it (a test suite, a schema, a linter), and failures get fed back in as the next iteration's context — automatically, without a human re-typing the prompt each time.
2. Plan → act → observe → replan. Instead of committing to a full multi-step plan up front, the loop re-evaluates after every action, because the world (a file, an API response, a database row) changed and the original plan may no longer be the right one.
3. Draft → review → escalate. The loop runs autonomously up to a defined boundary — a risky action, a low-confidence result, a budget limit — and then deliberately stops and asks a human, instead of guessing past the boundary.

None of these patterns are exotic. They're closer to how good engineering teams already work — ship, test, fix, repeat — than to anything uniquely "AI." Loop engineering is really just applying that discipline to a system where one of the participants in the loop happens to be a model instead of a person.

The through-line to how we think about performance

We didn't set out to write about AI architecture on a performance-management blog, but the parallel was too obvious to skip. A single standup entry is a prompt. A month of standups, tasks, and delivery data is context. The systems that turn that data into a rating are a harness. And the reason performance management works at all — the reason it's not just a snapshot judgment once a year — is that it's a loop: daily input, monthly reflection, an improvement plan, and then the next month's data testing whether anything actually changed.

Good performance management was loop engineering before the term existed. Good AI products are converging on the same idea from the other direction. That's probably not a coincidence — any system meant to produce a reliable outcome over time, whether it's built from people or from models, eventually has to become a loop, not just a single well-crafted turn.