Inside the Agent Loop: The Pattern Behind Reliable AI Agents

In our last post we made the case that coding is becoming a loop, not a keystroke: call the model, run a tool, feed back the result, repeat. That’s the headline. This post is the engineering underneath it.

Because here’s the thing every team building agents eventually discovers: swapping in a smarter model rarely fixes a flaky agent. You upgrade from one frontier model to the next, watch your benchmark tick up two points, and your agent still loops forever on the same task, still forgets what it learned ten steps ago, still declares victory on code that doesn’t run. The intelligence got better. The agent didn’t.

The reason is that an agent is not a model. An agent is a loop with structure — and the structure is where reliability is won or lost. This is the part that doesn’t fit in a demo tweet, so it gets ignored. Let’s not ignore it. Here’s the agent loop pattern, dissected.

The loop in one breath

Start from the irreducible core. As Simon Willison puts it, an agent is “something that runs tools in a loop to achieve a goal.” The minimal version really is a while loop: give the model a goal and some tools, let it request a tool call, run the tool, hand back the result, and repeat until it says it’s done.

You can build that in an afternoon. What you can’t build in an afternoon is a loop that stays coherent over fifty steps, doesn’t blow its context budget, and doesn’t confidently ship broken work. The naive loop and the reliable loop have the same skeleton and completely different survival rates. The difference is everything we’re about to describe — collectively, the harness: the non-model runtime that wraps the reasoning loop with tool dispatch, context management, safety, and verification. As Firecrawl’s primer on agent harnesses frames it, the model is only half the system; the harness is the other half, and it’s the half most buyers don’t know exists.

The phases of a real loop

A production agent loop isn’t one undifferentiated “think and act” step. It’s a pipeline of phases, each doing a distinct job on every iteration:

1. Pre-check / compaction. Before the model thinks, the harness decides what it’s even allowed to see. If the conversation is getting long, it compacts — summarizing or dropping stale context so the important state survives.
2. Think. The model reasons about the goal and the current state, and proposes a next action (often in a ReAct-style “thought → action” form).
3. Act / execute. The harness dispatches the requested tool call — read a file, run a command, query an API — and captures the result. This is also where guardrails live: which tools are allowed, what requires confirmation, what’s outright forbidden.
4. Observe. The tool’s output is fed back into context as the model’s new evidence about reality.
5. Verify / post-process. Before looping, the harness (or a second model) checks whether the step actually moved toward the goal — and whether the agent is fooling itself.

The naive loop collapses steps 1 and 5 into nothing: it just thinks, acts, and appends everything to an ever-growing transcript. That works for ten steps and falls apart by fifty. The reliable loop treats pre-check and verify as first-class phases. That’s the whole game.

Context engineering: feeding the loop

The single biggest determinant of whether a long-running loop survives is what you put in front of the model at each step — what Anthropic calls context engineering. The model’s context window is a budget, not a backpack. You cannot just keep stuffing things into it.

Every loop iteration adds tokens: files read, command output, prior reasoning, tool results. On a real codebase, the relevant information eventually exceeds the window, and the model starts forgetting what it learned earlier in the run. Context engineering is the discipline of deciding, at each step, which instructions, evidence, and state actually need to be present — and ruthlessly excluding the rest.

For runs that genuinely exceed a single context window, the pattern gets more deliberate. Anthropic’s long-running agent harness, documented in the ZenML LLMOps database, uses a two-part design: an initializer that sets up the work and a coding agent that executes, with context resets and handoff artifacts between windows. Instead of one agent trying to hold an hours-long task in its head, the work is checkpointed into durable artifacts that a fresh context can pick up. The agent forgets — on purpose — and the harness makes sure nothing important is lost when it does.

This is the unglamorous reality of long-horizon agents: most of the engineering is about managing forgetting, not adding intelligence.

The verification loop: generator vs evaluator

Here is the failure mode that humbles every team: agents are bad at grading their own work. Ask a model “did you do this correctly?” right after it did the thing, and it will mostly say yes — including when the answer is no. Self-critique in the same breath as generation is weak, because the model is anchored to the work it just produced.

The fix is structural, not a better prompt. You split the loop into two roles. One model generates; a separate, skeptical model evaluates — adversarially, with a different framing and ideally different evidence. Epsilla describes this as a GAN-style agent loop: a Generator proposes, an Evaluator tries to tear it down, and only work that survives the Evaluator moves forward. The name is a nod to generative adversarial networks, and the intuition is the same — adversarial pressure produces better output than a single model marking its own homework.

In practice this is why a coding agent with strong tests outperforms one without by a wide margin: the test suite is the Evaluator. When you lack that signal — thin test coverage, no clear success criterion — the loop’s verification phase is blind, and the agent will sail confidently past bugs. Garbage feedback in, garbage confidence out. If you take one thing from this post: the quality of your verification phase caps the quality of your agent.

Constraints are a feature, not a limitation

The instinct when an agent misbehaves is to give it more freedom and a smarter model. The counterintuitive lesson from teams shipping real systems is the opposite: constraints in the harness are what make agents reliable. Augment Code’s writeup on harness engineering for coding agents argues exactly this — that constraints, not bigger models, are what ship dependable code.

Concretely, the constraints that pay off:

• Tight, well-described tools. A few sharp tools the model understands beat a sprawling API surface. Tool design is prompt engineering by another name.
• Permission gates. Decide what the agent can do autonomously versus what needs a human in the loop. “YOLO mode” has its place — but it’s a deliberate choice, not a default.
• Bounded steps and budgets. A loop that can run forever will. Caps on iterations, tokens, and wall-clock turn a runaway into a graceful give-up.
• Observability. You cannot fix a loop you can’t see. Logging each phase — what the model saw, what it chose, what the tool returned — is the difference between debugging and guessing.

None of these come from the model. All of them come from the harness. This is the heart of why model upgrades don’t fix flaky agents: the failure was never in the weights.

Where to put your effort

So you’re building an agent and you have limited engineering hours. Where do they go?

Not into chasing the newest model — that’s a setting you change in an afternoon when it’s worth it. The durable leverage is in the loop: a verification phase with a real success signal, context discipline that survives long runs, tight tools, and observability so you can actually see what’s happening. These are the parts that compound, and — notably — the parts that survive model upgrades. A better model makes a well-built loop better. It does almost nothing for a loop with no verification and no context strategy.

There’s a strategic version of this point too. As base models absorb more planning and tool-selection ability, some scaffolding does get “swallowed” by the model — but the system-level concerns (memory, orchestration, verification, governance) don’t come from the model alone, and arguably have to grow as the model gets more capable and is trusted with longer-horizon work. Bet on the layers that survive the next release.

Conclusion

An agent is a loop with structure, and the structure is the product. The model supplies intelligence; the loop decides whether that intelligence ever lands. The phases — pre-check, think, act, observe, verify — are where reliability is engineered. Context engineering keeps long runs coherent. A separate evaluator keeps the agent honest. Constraints keep it from running off a cliff. Swap in a smarter model and none of that comes for free; build the loop well and a smarter model makes all of it better.

This is the layer we work in. If your team has an agent that demos beautifully and breaks in production — or you’re designing one and want to get the loop right the first time — that’s exactly the work we do.

We design and audit agent loops and harnesses. Book a review with us.