From Agent Engineering to Harness Engineering to Loop Engineering

If you've been building with LLMs for more than a year, you've felt the ground move under you at least twice. The thing we call "the work" keeps changing shape. First it was about the model. Then it was about the agent. Now, increasingly, it's about the loop the agent runs inside. Each shift looked at the time like a minor tooling update, but in hindsight each one redefined where the leverage lives.

Here's how I'd map the three eras — and why the latest one, loop engineering, is the part most teams are still underinvesting in.

Era One: Agent Engineering

The first wave was about getting a single model to do something instead of just say something. You took a capable base model, handed it a system prompt, gave it a few tools, and tried to coax reliable behavior out of it. The craft was prompt design, tool schemas, output parsing, and the endless tuning of "when should it call this function versus that one."

This era produced a lot of demos and very few durable products. The reason is that agent engineering treated the model as the whole system. If the agent misbehaved, the fix was always "better prompt" or "better model." We anthropomorphized the thing — we talked about whether the agent was "smart enough" or "confused" — and that framing quietly capped how good our systems could get. You can only prompt-engineer your way so far before you're fighting the model's stochasticity directly, one-shot, with no recourse when it guesses wrong.

The lasting lesson from this era: a single model call, no matter how well-prompted, is a fragile unit. It has no memory of its mistakes, no ability to verify itself, and no second chance. Agent engineering was necessary, but it put all the weight on the least reliable part of the stack.

Era Two: Harness Engineering

The second shift was the realization that the interesting part isn't the model — it's everything wrapped around it. The harness is the scaffolding: the tool definitions, the context management, the retrieval layer, the permission system, the way results get fed back in, the way errors get surfaced and recovered. Claude Code, Cursor, and the better internal agent platforms are fundamentally harness achievements, not model achievements. They run on the same models everyone else has access to.

Harness engineering changed the central question from "how do I prompt the model?" to "what environment do I put the model in?" And that turns out to be a much richer design space. A good harness gives the model clean, well-scoped tools instead of a giant grab-bag. It manages context deliberately — deciding what the model sees, when to compact, what to keep out of the window entirely. It makes failure observable, so a bad tool call returns a useful error the model can react to rather than a silent wrong answer.

The mental shift here is the important one: you stop trying to make the model perfect and start engineering the system so that an imperfect model still produces reliable results. That's a fundamentally different posture. You're no longer arguing with the model's intelligence — you're shaping the surface it acts against. The same model that flails inside a sloppy harness becomes dependable inside a tight one.

This is also where the economics flipped. In the agent era, capability scaled with model upgrades — you waited for the next release. In the harness era, capability scales with engineering effort you control. Two teams with identical model access now ship wildly different products, and the difference is entirely in the harness.

Era Three: Loop Engineering

The newest shift is subtle, and a lot of teams haven't named it yet even though they're starting to feel it. Once you have a solid harness, the next leverage isn't in any single agent run — it's in the loop. How does the agent iterate? When does it stop? How does it know it's done? What happens between attempt one and attempt five? Who verifies the output, and what feeds the next iteration?

Loop engineering treats the agent run as one tick of a larger control system rather than as the whole event. The questions that matter at this layer are control-flow questions: termination conditions, verification gates, retry-with-feedback strategies, fan-out and fan-in across parallel agents, and convergence — how you keep a loop from spinning forever or declaring victory too early.

Concretely, this looks like things such as: run a generate step, then run an independent verify step that tries to refute the output, and only accept it if it survives. Or: spawn N agents on the same problem from different angles and reconcile their answers instead of trusting one. Or: loop a "find issues" pass until two consecutive rounds surface nothing new, rather than running it a fixed number of times. None of these are prompt tricks or harness features. They're orchestration — deterministic control flow written around the nondeterministic agent.

The key insight is that loops let you trade tokens for reliability in a way single runs never could. A one-shot agent is a coin flip you can't re-flip. A well-engineered loop turns that same unreliable agent into something that converges, because each iteration carries information forward — the error from attempt one becomes context for attempt two, the verifier's objection becomes the next prompt's constraint. Reliability stops being a property you hope the model has and becomes a property the loop produces.

Why the Progression Matters

These three eras aren't a story of one approach replacing another — they stack. You still need prompt craft. You still need a good harness. But the frontier of leverage has moved outward each time: from the model, to the environment around the model, to the control flow around the environment.

The practical consequence is that the highest-value engineering increasingly looks less like ML and more like distributed systems. Termination conditions, idempotency, verification, fan-out/fan-in, convergence guarantees — this is the vocabulary of orchestration, not prompting. The teams pulling ahead right now aren't the ones with secret model access. They're the ones who figured out that a mediocre agent in a great loop beats a great agent in no loop.

If you're deciding where to invest, here's the heuristic I use. If your agent fails because it doesn't understand the task, that's a prompt problem — fix the agent layer. If it fails because it can't see the right information or act cleanly on the environment, that's a harness problem. But if it fails because one run simply isn't enough — because the task genuinely needs verification, iteration, or multiple perspectives to get right — no amount of prompt or harness work will save you. That's a loop problem, and loop engineering is where you'll spend the next year of your attention whether you've named it yet or not.