The harness matters more than the model now.

The harness is every piece of infrastructure between "the model produced a response" and "the task is actually done." For a single-turn chatbot, the harness can be thin: call the model, return the answer. For an agent that runs for twenty minutes across fifteen tool calls, researching, writing, and revising, the harness is most of the engineering effort.

It includes: durable state that survives a server restart, checkpoints after each meaningful step, a retry policy with backoff for transient tool or network failures, a hard budget ceiling on tokens and wall-clock time, and a recovery path that resumes from the last good checkpoint rather than starting the entire task over. None of this is visible in a demo, which is exactly why it gets underbuilt.

In 2023 and 2024, model quality gaps were large enough that a model swap was often the fastest fix for a struggling agent. By 2026, the gap between frontier models on most reasoning and tool-use benchmarks has narrowed to single digits, and in practice, on real workloads, the difference is often smaller than the variance introduced by prompt design or harness bugs.

This means the question "which model should we use" now returns diminishing gains, while the question "what happens when a tool call times out at minute fourteen of a twenty-minute task" is where the actual failures live. We cover the model-selection side of this separately in how to pick a model with your own workload, but the harness question is the bigger lever for anything that runs longer than a single turn.

The common narrative right now is "just use an agent framework, it handles all this for you." Frameworks help, but most ship with defaults tuned for demos, not production: in-memory state that vanishes on restart, retry logic that retries indefinitely without a ceiling, and no built-in budget enforcement. Teams adopt a framework, see it work in a notebook, and assume the hard problems are solved.

They aren't. A framework gives you scaffolding for calling tools and managing a loop. It does not give you an opinion on how much a single run is allowed to cost, what happens when your database is down for ninety seconds, or how to safely resume a task that failed at step nine of fourteen. Those are business decisions specific to your workflow, and no framework can make them for you.

1. Durable state. Persist the agent's current task state, accumulated context, and step history to a database, not to memory. This is the single highest-leverage fix for a stuck long-running agent, since it's what allows anything else on this list to function.
2. Checkpoints after every meaningful step. A meaningful step is any tool call, any significant reasoning milestone, or any point where reverting would waste more than a few seconds of work. Checkpoints should capture enough to resume, not just enough to log.
3. Bounded retry policy. Retry transient failures (network timeouts, rate limits) up to a fixed count with exponential backoff. Do not retry logic failures (a malformed tool response that will fail the same way every time) more than once.
4. Hard budget ceiling. Set a maximum token spend and wall-clock time per run, enforced in code, not just monitored in a dashboard after the fact. When the ceiling is hit, the agent should checkpoint, escalate, and stop, not silently keep going.
5. Recovery from last checkpoint. On any restart, crash, or manual intervention, resume from the last good checkpoint instead of re-running the entire task. This alone can cut compute cost dramatically on long tasks.
6. Idempotent tool calls where possible. Design tools so a retried call doesn't duplicate a side effect, like sending the same email twice. Use idempotency keys for any tool that writes data.
7. Observability tied to each checkpoint. Every checkpoint should emit a log entry with step, cost so far, and elapsed time, feeding into your existing dashboard, so a human can see exactly where a stuck run is stuck.

• Does the agent survive a process restart mid-task without losing progress?
• Is there a hard ceiling on tokens and time per run, enforced in code?
• Do transient failures retry with backoff, and do logic failures fail fast instead of looping?
• Can you point to a specific checkpoint and know exactly what state the agent was in?
• Are your tool calls idempotent, or could a retry double-send an action?
• Is there a dashboard showing cost and elapsed time per run, visible before a run finishes, not just after?

If more than two of these are "no," the harness is the bottleneck, not the model. This is the exact audit we run during a $1,000 AI Audit, and it's usually where the ranked fix list gets the most entries.

A long-running agent without a budget ceiling is a loop waiting for the wrong input. We've seen a research agent enter a retrieval loop that ran for six hours overnight and generated a five-figure token bill before anyone noticed, because nothing in the system stopped it. A ceiling would have caught this in minutes.

Set two ceilings: a per-run maximum (tokens and wall-clock time) and a per-day aggregate maximum across all runs of that agent. When either is hit, the agent should checkpoint its current state, log the reason, and escalate to a human rather than silently terminating or, worse, silently continuing. This ties directly into the escalation design covered in when to hand an agent back to a human: a budget breach is one of the clearest escalation triggers there is.

A well-harnessed long-running agent is boring to watch run. It checkpoints quietly, retries transient failures without drama, hits its budget ceiling occasionally and escalates cleanly, and resumes from the right point after any interruption. None of that is exciting, and that's the point: boring infrastructure is what lets the model do interesting work without an engineer babysitting every run.

Teams that invest in the harness before scaling up an agent's scope consistently outship teams that keep swapping models to chase reliability gains. If your agent's reliability problems have survived two or three model swaps already, the harness, not the model, is almost certainly where the next fix lives. That's a pattern we also see in agentic system builds broadly, where the orchestration layer, not any single model call, determines whether the system holds up under real load.