---
title: "Long-Horizon Agents Are Batch Jobs. Build Them Like It."
description: "Every 2026 model launch claims long-horizon capability, and teams keep shipping agents that lose two hours of work to one failed API call. The fix is not a better model, it is thirty years of batch processing practice: checkpoints, idempotent steps, and resume from the last good state."
image: "https://foundrysoft.co/api/og?type=article&title=Long-Horizon+Agents+Are+Batch+Jobs.+Build+Them+Like+It.&cat=AI+Engineering&rt=12+min+read&au=Varun+Raj+Manoharan&dt=2026-08-06"
url: "https://foundrysoft.co/blog/long-horizon-agents-checkpoint-resume"
---

AI Engineering 2026-08-06 12 min read

# Long-Horizon Agents Are Batch Jobs. Build Them Like It.

Every 2026 model launch claims long-horizon capability, and teams keep shipping agents that lose two hours of work to one failed API call. The fix is not a better model, it is thirty years of batch processing practice: checkpoints, idempotent steps, and resume from the last good state.

![Varun Raj Manoharan](https://foundrysoft.co/images/about/founder.webp)

Varun Raj Manoharan Founder & Principal Engineer

AI Agents Long-Horizon Tasks Reliability Checkpointing Production AI

## Key takeaways

-   A long-running agent has the failure profile of a batch job, not a web request, and the remedies are the ones batch processing worked out decades ago: checkpoint state, make steps idempotent, resume rather than restart.
-   Restarting a failed hour-long run is not just slow, it doubles the token bill for that task and re-executes every side effect the first attempt already committed.
-   Model capability improvements raise per-step reliability, which helps, but the compounding arithmetic over a long loop means step count is the variable with the most leverage. Fewer steps beats a better model at the same step count.
-   The checkpoint has to capture the working set and the goal, not the raw transcript. A resumed run that inherits a saturated context inherits the condition that caused the failure.

"Long-horizon" is the phrase of the year. Kimi K3 was positioned around long-horizon knowledge work. OpenAI shipped ChatGPT Work alongside GPT-5.6, an agent meant to carry out whole jobs rather than answer questions, gathering context across connected apps and files to produce documents, spreadsheets, and presentations. The framing across the industry has moved from answering to completing.

The models really have improved at this. What has not improved, in most of the systems I see, is the engineering around them, and the gap shows up in a specific and avoidable way: an agent runs for ninety minutes, hits one transient failure, and starts over from nothing.

That is not a model problem. It is a workload classification problem. Somebody built a long-running job on the assumptions of a request handler, and long-running jobs have different assumptions.

## The workload is batch, not request

A web request is short, cheap to retry, and stateless by design. If it fails you run it again and nothing is lost but milliseconds. Every framework you use encodes those assumptions.

A ninety-minute agent run is a batch job. It is long, expensive, has partial results worth keeping, and commits side effects along the way. Batch processing has known this since long before any of us were writing software, and the practices are settled: checkpoint your progress, make each step idempotent, and on failure resume from the last good state rather than the beginning.

Almost none of that is standard in agent frameworks today, so it falls to you.

The cost of skipping it compounds in two directions. The obvious one is time. The less obvious one is money: a restarted run re-bills every token the first attempt consumed. Given that agentic workflows already burn five to thirty times the tokens of a simple query, a task that fails at 80% and restarts has cost you nearly twice its nominal price for one completion. Do that on a workload with a 15% transient failure rate and your effective cost per completed task is nowhere near your estimate.

## Four things that end long runs

Sorting real failures I have watched, they land in four buckets, and only one is about the model being wrong.

**Transient infrastructure failure.** A tool call times out, a rate limit hits, a deploy restarts the process, a network blip. The agent was doing fine. Something underneath it was not. This is the most common cause and the most infuriating, because nothing was wrong with the work.

**Context saturation.** The window fills with accumulated tool output, and behaviour degrades: instructions from the start stop being honoured, the agent repeats work it already did, or it starts summarising rather than acting. The run may not crash at all. It just stops making progress, and that is worse because nothing detects it.

**Goal drift.** Thirty steps in, the agent is working on something adjacent to what it was asked. Each individual step looks locally reasonable. The composition has wandered. This is the failure that produces a completed run with a useless output, and it is the hardest to detect automatically.

**Genuine dead end.** The task cannot be completed as specified, the data is not there, the API does not expose what is needed. The correct behaviour is to stop and say so. Many agents instead keep going, and produce something plausible.

Checkpointing addresses the first directly, mitigates the second and third, and is neutral on the fourth. That is a good return for a bounded amount of engineering.

## What a checkpoint contains

The naive version is to serialise the conversation and restore it. That is better than nothing and it inherits the problem, because if the run failed due to context saturation you have just restored the saturated context and will fail again in the same place.

A useful checkpoint captures state, not transcript. Concretely, four things.

**The goal, restated.** The original objective in its original form, so a resumed run is anchored to what was asked rather than to what the transcript drifted toward.

**The working set.** The facts established so far, in a compact structured form. Not the tool responses that produced them, the conclusions. If the agent has determined that the customer is on the enterprise plan, that is one line, not the four-hundred-token API response it came from.

**Completed steps, with their outputs.** What has been done and what it produced, so the resumed run does not redo it. This is also what makes idempotency checkable.

**The open question.** What the agent was in the middle of when it stopped.

Constructing that summary is a model call in its own right, and it costs something. It pays for itself, and there is a second benefit: a run resumed from a compacted working set often performs better than the run that failed, because it has shed the accumulated noise. The checkpoint doubles as context hygiene.

Take checkpoints at meaningful boundaries rather than every step. After a phase completes, after an expensive operation succeeds, before a risky action. Every step is too expensive and mostly redundant; once at the start is not a checkpoint.

## Idempotency is what makes resume safe

Resume is only correct if replaying a step is harmless. For read-only steps that is free. For anything that writes, sends, or spends, it has to be engineered.

The standard mechanism is the one payment systems use: an idempotency key derived from the task ID and the step identity, passed to the tool, with the tool responsible for recognising a repeat and returning the original result rather than performing the action again.

This has to live in the tool, not the agent. An agent that remembers it already sent the email is relying on state that may not survive whatever killed the run. A tool that recognises the key returns the same message ID whether it is the first call or the fourth, and that property holds no matter how the agent failed.

If you build one piece of infrastructure out of this post, make it this one. It is what turns retry from a risk into a routine.

## Detect stalls, not just crashes

Crashes are easy to notice. The failure modes that cost the most are the ones where the agent keeps running and stops accomplishing anything, and those need explicit detection.

Three cheap signals cover most of it.

**Progress per step.** If the working set has not grown in five steps, the agent is looping. Track the size of the established-facts set and alarm when it flattens while steps continue.

**Repeated tool calls with identical arguments.** Calling the same tool with the same input twice is occasionally legitimate and usually a loop. Three times is a loop. This is a two-line check and it catches a surprising amount.

**Step budget with a hard ceiling.** Every task gets a maximum step count derived from what similar tasks actually take, not from optimism. On hitting it, checkpoint and escalate to a human rather than continuing or silently truncating. An agent that hits its ceiling has produced information, which is that this task is not like the others.

## Step count is the variable with leverage

There is an arithmetic point underneath all of this, and I want to be explicit about it.

Per-step reliability compounds multiplicatively across a loop, so small per-step improvements have outsized effects on long runs and small per-step regressions do too. That cuts in an underappreciated direction: reducing the number of steps improves end-to-end reliability by the same mechanism as improving the model, and you control step count directly.

This is why the token efficiency framing on the 2026 launches matters beyond cost. Sol being described as 54% more token efficient on agentic coding tasks is, read through this lens, a reliability claim. Fewer steps to the same outcome means fewer opportunities to fail, less context accumulated, less drift.

The engineering version of the same insight: a tool that does one useful composite operation is better than three tools the agent has to sequence, because it removes two decision points and two failure points. Teams tend to build fine-grained tools because that feels more flexible. For long-horizon work, coarser tools that encapsulate a whole meaningful operation usually win.

## Where this leaves the model choice

Model capability is part of this. A model that is better at knowing when it has enough information, better at recovering from a malformed tool response, and better at holding an instruction across a long context will complete more long-horizon tasks than one that is not. Those properties are real and they differ across models.

They are also not what any public benchmark reports, the recurring theme of every model selection question that matters. If long-horizon completion is what you need, the eval that decides it is your own tasks run to completion with your own tools, measuring how many finish, how many steps they took, and what happened at the failures.

But build the checkpointing first. A better model on an architecture that loses everything on a transient timeout is a more expensive way to lose everything on a transient timeout. The infrastructure is what makes the model's improvements durable, and unlike the model, it is entirely within your control.

#### Related reading

[AI Agents Are About to Start Buying From You. Is Your Checkout Ready?

Agentic commerce protocols settled into a working stack this year: ACP for checkout, AP2 for payment authorisation, MCP and A2A underneath. Most merchant systems are built on assumptions that an agent breaks. Here is what to check before an agent tries to buy something.

Agentic Commerce AP2 AI Agents

](https://foundrysoft.co/blog/agentic-commerce-checkout-readiness)[The EU Just Gave You 16 More Months on AI Compliance. Do Not Spend Them.

The EU AI Act's high-risk deadline moved from 2 August 2026 to 2 December 2027. The transparency rules did not move. Here is what actually applies to your AI agents right now, and why the extension is a trap for anyone who treats it as free time.

EU AI Act AI Compliance AI Agents

](https://foundrysoft.co/blog/eu-ai-act-high-risk-delay-agents)[The Effort Dial Is an Architecture Decision, Not a Setting

Claude Opus 5 ships with a low, medium, high effort toggle, and most teams set it once globally and forget it. In an agent loop, effort is a per-step decision, and treating it as a global default costs you money on the mechanical steps and reliability on the one step that mattered.

Claude Opus 5 AI Agents Reasoning Models

](https://foundrysoft.co/blog/effort-dial-agent-architecture)

#### Next Article

[

Native Multimodal Models Beat Your OCR Pipeline, Then Take Away the Thing You Needed Most

](https://foundrysoft.co/blog/native-multimodal-document-extraction-provenance)

Available for new projects

## Let's build something great.

Have a project in mind? We are an elite software and AI development studio ready to bring your ideas to production. Let's talk about your roadmap.

Start a Project [See our work](https://foundrysoft.co/work)

```json
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co",
  "logo": "https://foundrysoft.co/logo.svg",
  "description": "FoundrySoft builds production-grade software and AI systems for US companies, from an India-based team of senior engineers.",
  "sameAs": [
    "https://github.com/foundrysofthq",
    "https://www.linkedin.com/company/foundrysoft",
    "https://www.instagram.com/foundrysoft/"
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "FoundrySoft",
  "url": "https://foundrysoft.co"
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Long-Horizon Agents Are Batch Jobs. Build Them Like It.",
  "description": "Every 2026 model launch claims long-horizon capability, and teams keep shipping agents that lose two hours of work to one failed API call. The fix is not a better model, it is thirty years of batch processing practice: checkpoints, idempotent steps, and resume from the last good state.",
  "url": "https://foundrysoft.co/blog/long-horizon-agents-checkpoint-resume",
  "mainEntityOfPage": "https://foundrysoft.co/blog/long-horizon-agents-checkpoint-resume",
  "image": [
    "https://foundrysoft.co/images/blog/long-horizon-agents-checkpoint-resume.webp"
  ],
  "datePublished": "2026-08-06",
  "dateModified": "2026-08-06",
  "keywords": "AI Agents, Long-Horizon Tasks, Reliability, Checkpointing, Production AI",
  "author": {
    "@type": "Person",
    "name": "Varun Raj Manoharan"
  },
  "publisher": {
    "@type": "Organization",
    "name": "FoundrySoft",
    "logo": {
      "@type": "ImageObject",
      "url": "https://foundrysoft.co/logo.svg"
    }
  }
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Home",
      "item": "https://foundrysoft.co/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Blog",
      "item": "https://foundrysoft.co/blog"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Long-Horizon Agents Are Batch Jobs. Build Them Like It.",
      "item": "https://foundrysoft.co/blog/long-horizon-agents-checkpoint-resume"
    }
  ]
}
```