When an AI agent fails in production, the instinct is often to blame the model — it should have "known better," reasoned more carefully, been smarter. In practice, most of the failures that show up once an agent leaves the demo stage aren't model problems at all. They're harness problems. The model decides what to do next; the harness decides what's allowed to happen, what gets remembered, and what happens when something goes wrong. A capable model wrapped in a thin harness will still loop, hallucinate tool results, and drift off task — because nothing outside it is keeping score.
The "harness" is everything surrounding the model that turns a single inference call into a working agent: the code that executes tool calls, tracks conversation state, enforces limits, and decides when a task is finished or has gone wrong. The model proposes an action; the harness is what actually runs it, validates it, and feeds the result back.
This distinction matters because it reframes where the real engineering work is. Prompting shapes what the model wants to do. The harness determines what it's actually able to do, and what happens when its first choice doesn't work.
Execution and Validation:
The harness is responsible for actually running tool calls and, critically, validating them before it does. That means rejecting calls to tools that don't exist, checking arguments against a schema before they hit a real system, and returning clear, unambiguous errors rather than silent failures. A loose harness that lets malformed calls through, or that returns an empty response on failure instead of an explicit error, is what allows an agent to fabricate a plausible "success" instead of recognizing that something actually broke.
State and Memory:
Agents don't naturally remember what they've already tried. That has to be built. A well-designed harness maintains a persistent record of prior actions and outcomes, so a repeated action is recognizable as repeated, and so the system has something to check "have I done this before" against. Without this, retry loops are close to inevitable — the agent has no way to distinguish a fresh attempt from the fifth identical one.
Termination and Exit Logic
This is the harness responsibility that's easiest to underbuild. Left to the model's own judgment, "when to stop" is a soft, prose-level decision — and a soft decision is exactly what breaks down under pressure to keep looking productive. The more robust approach is moving exit logic out of the model's judgment and into the workflow definition itself: every state in the process declares explicitly where failure routes to next. A failed verification step routes to "retry implementation," not back to itself. If there's no edge in the workflow that allows infinite self-repetition, that failure mode isn't just discouraged — it's structurally unreachable.
A Legitimate Way to Fail:
Just as important as controlling retries is giving the agent an honest way out. If "I can't complete this" is treated as a failure to be avoided at all costs, the agent has every incentive to fabricate progress rather than admit it's stuck — which produces exactly the kind of hallucinated-success failure that's hardest to catch. A well-designed harness treats a structured, explicit "I don't have what I need to finish this" as a neutral, first-class outcome, not a penalized one. When honest failure costs nothing, agents stop flailing to appear productive.
Budgets and Limits:
Turn limits, cost caps, and retry ceilings are the blunt instrument version of harness control — not elegant, but essential as a backstop. Even a well-designed exit-logic system benefits from a hard limit underneath it, because no detection mechanism catches every edge case. The budget is what keeps a missed edge case from becoming an expensive one.
Two failure modes in particular show why harness design matters more than model quality:
Retry loops are the easy case — the same action, repeated, with the same failing result. A harness that tracks action history can flag this directly: if an identical call has already failed once, don't let it fire again without some change in approach.
Oscillation is harder. No single action repeats — the agent edits a file one way, then reverses it, then reintroduces the original change a few steps later — so naive deduplication misses it entirely. One lightweight approach that works well before investing in full state hashing is tracking an outcome digest rather than full state: if the effects of the last several actions (files touched, calls made, results returned) start repeating with nothing net-new appearing, that's a strong signal of oscillation even though the specific actions differ each cycle. It's a lossy check — it'll miss cases where effects vary while progress still stalls — so it's worth pairing with a hard cap as backup rather than relying on it alone.
Both of these are structurally invisible from inside a single turn. Catching them requires the harness to hold a window of history, not just the current state, since the pattern only exists across steps.
It's tempting, when an agent keeps failing, to reach for a more capable model. Sometimes that helps — but often it just delays the same failure by giving the agent more attempts before it exhausts a budget. If the underlying issue is that nothing outside the model is tracking history, validating tool calls, or defining where failure routes, a smarter model will still eventually hit that same structural gap. The reliability gains that actually show up in production tend to come from strengthening the execution loop itself: validation, state tracking, and explicit termination logic — not from swapping in a bigger brain and hoping it self-corrects.
A capable model and a well-built harness are doing different jobs. The model reasons about what to try next. The harness is what turns that reasoning into safe, bounded, recoverable action — catching malformed calls, remembering what's already failed, and giving the system a real way to stop instead of spinning. Most of what looks like "the AI got confused" in production is actually "nothing was watching," and that's a problem no amount of prompting alone fixes.