Decomposition, checkpointing, and failure recovery — how agents plan and persist across tasks that take minutes, hours, or days
Imagine you hired a talented contractor to renovate your kitchen. A bad contractor would show up each day, look around confused, and ask "where did we leave off?" A great contractor keeps a detailed project notebook: phases completed, materials ordered, decisions made, and what to do if the tile supplier goes out of business. Long-horizon agent tasks are the difference between these two contractors — the question is: how do you build the notebook, the recovery plan, and the task structure that lets an AI work for hours without losing its mind?
Most agent loops you've encountered (ReAct, Tool Use) are designed for short-horizon tasks: answer a question, write a function, look up a fact. These complete in seconds to minutes with a few dozen tool calls. Long-horizon tasks operate on a fundamentally different timescale — "migrate this entire codebase to TypeScript," "research and write a 50-page report," "autonomously manage our social media presence for a week." They require persistent state across tool calls, the ability to recover from failures mid-task, and structured planning that spans multiple sub-goals.
Every long-horizon agent system must solve three tightly coupled problems:
Solving only two of three is insufficient. A system that decomposes well but can't recover from tool failures will collapse mid-task. A system that checkpoints but can't re-plan gets stuck replaying the same failed action.
Decomposition is not just "split the task into steps." It is an active planning process that produces a task graph — a directed acyclic graph (DAG) where nodes are subtasks and edges encode dependency relationships (B can only begin after A completes). There are three main decomposition strategies:
The hard part is dynamic re-planning: when a subtask fails or returns unexpected results, the agent must update its task graph (not just retry), potentially promoting or demoting entire branches based on new information. Static plans degrade badly in open-ended environments.
Context windows are finite. Even a 1M-token window will overflow during a 10-hour task. Checkpointing is the practice of periodically serializing all state the agent needs to resume execution — essentially saving your game so you don't restart from level 1 after a crash.
A complete checkpoint contains:
The two main checkpointing architectures are event-sourcing (store every state-change event; replay to reconstruct) and snapshot (store full state at intervals; resume from nearest snapshot). LangGraph uses event-sourcing — every node execution is appended to an immutable log, enabling time-travel debugging and precise resumption.
Without checkpointing, the failure at t=41m would restart the entire task from t=0, discarding 41 minutes of work and all associated API costs. With checkpointing, only 7 minutes of work (t=34m to t=41m) must be redone.
Long-horizon tasks fail in categorically different ways than short tasks, and each failure mode demands a different recovery strategy:
From a software architecture standpoint, long-horizon agents are durable workflows — long-running processes that must tolerate infrastructure failures. This borrows from distributed systems concepts: sagas, two-phase commit, and write-ahead logs have direct analogues in agent execution.
The emerging pattern is workflow-as-code (exemplified by Temporal, LangGraph, and AWS Step Functions): the developer writes the agent's logic as regular code, and a workflow runtime handles persistence, retries, and fault tolerance automatically. The agent code is deterministic; all side effects are logged. On failure, the runtime replays the logged events to restore state without re-executing expensive LLM calls.
VOYAGER is the first LLM-powered agent that plays Minecraft continuously across multiple sessions without human intervention, obtaining progressively harder in-game items, discovering new areas, and accumulating a reusable skill library of executable code. The agent uses GPT-4 as its backbone with three modules: an automatic curriculum that proposes always-just-difficult-enough goals, a skill library that retrieves and composes previously learned behaviors, and an iterative prompting mechanism that corrects itself using execution feedback.
What makes VOYAGER specifically about long-horizon execution is that skill accumulation is its solution to the horizon problem: instead of planning a 1,000-step sequence, the agent learns to compose short skills into longer behaviors, effectively extending its effective planning horizon without ever needing to reason about 1,000 steps at once.
Optimus-1 proposes a hybrid memory architecture combining a hierarchical knowledge graph (structured long-term facts about the environment) with an experience pool (past successful action sequences). When the agent encounters a new task, it queries both memory types: the knowledge graph provides factual grounding (what materials craft what) while the experience pool provides procedural templates (how similar tasks were solved before).
On Minecraft long-horizon benchmarks, Optimus-1 achieves over twice the success rate of GPT-4V with basic prompting, while using substantially fewer steps per task. The key finding: structured memory dramatically outperforms raw context — the agent doesn't need to "remember" everything in its context window if it has a queryable external store.
The Tool Decathlon introduces a benchmark of 600+ diverse tools derived from real-world software environments, with tasks requiring agents to chain together long sequences of tool calls across unfamiliar APIs to complete end-to-end goals. Unlike prior benchmarks that test individual tool invocations, the Decathlon tests compositional long-horizon tool use — can the agent figure out which of 600 tools to use, in which order, with correct parameters, across 20+ step plans?
The benchmark reveals that state-of-the-art agents degrade rapidly with task horizon: performance on 5-step tasks is reasonable, but 15+ step tasks expose systematic failures in tool selection, state tracking across steps, and error recovery. The paper provides a diagnostic framework showing where in the plan agents tend to fail (early steps vs. late steps) and why.
Note: Direct social media and blog access was unavailable during this session. Positions below are paraphrased from verified recent public sources (GitHub releases, conference talks, documented blog posts). No fabricated quotes.
| Platform | Decomposition | Checkpointing | Failure Recovery | Max Effective Horizon |
|---|---|---|---|---|
| Claude (Anthropic) | Projects feature enables persistent context across sessions. Claude Sonnet 4.6 produces structured multi-step plans with explicit dependency notation. Relies on developer to implement task graph externally. | No native built-in checkpointing at model level. Projects provide cross-session memory. Developers must implement checkpoint serialization (commonly with LangGraph as a wrapper). | Strong self-correction within a context window via iterative prompting. Context summarization keeps older steps retrievable. No native crash-resume — relies on wrapper framework. | Moderate. 200K context + Projects = multi-day tasks viable with careful memory management. Weakest on automatic failure recovery compared to framework-native solutions. |
| Claude Code / OpenClaw | SKILL.md architecture enables hierarchical decomposition: complex tasks are broken into sub-skills that invoke other skills. Hub-and-spoke model means coordinator agents manage sub-agent task trees natively. | Session state persists across tool calls within a session. Workspace folder acts as a persistent shared state store across sessions — effectively a filesystem-based checkpoint. Skills can read prior session outputs. | Built-in retry on tool failures. Skills designed to be idempotent. Hub coordinator can detect sub-agent failure and re-route to alternative skills. Malicious skill detection (flagged 1,184+ bad actors) adds a recovery safety layer. | Strong. Designed explicitly for hour-long agentic workflows. Skill library architecture directly implements the VOYAGER pattern: reuse learned procedural knowledge across tasks. |
| GPT-4o / Codex CLI | Codex CLI generates structured reasoning with sub-task dependencies. ChatGPT's Task feature enables multi-step background execution with scheduled sub-tasks. OpenAI's Responses API supports stateful multi-turn. | Codex CLI is stateful within a session via the conversation object. ChatGPT Tasks persist between sessions natively. Responses API allows thread resumption by ID. | OpenAI's operator layer includes automatic retries on transient tool failures. Codex CLI's background execution mode supports continuation on failure. Limited automatic re-planning on non-transient failures. | Moderate-high. ChatGPT Tasks designed for multi-day background agents (check-in scheduling, monitoring tasks). Strong for periodic recurrence; weaker for complex stateful recovery mid-execution. |
| Gemini 2.5 (Google) | Native long-context advantage (1M+ tokens) reduces urgency of decomposition — Gemini can often hold an entire project's context in-window without summarization. Gemini's planning mode produces structured XML task trees. | Gemini's context caching (up to 1M tokens) acts as an implicit checkpoint for frequently referenced state. Vertex AI Agent Builder provides managed workflow checkpointing for Gemini-backed agents. | Google's infrastructure-level durability (Vertex AI pipelines) handles crash recovery. Gemini can re-read its cached context on resume. Weaker at agent-level re-planning vs. framework solutions. | High for context capacity, moderate for recovery sophistication. Best suited for tasks where the bottleneck is context length (large codebases, long documents) rather than complex multi-branch recovery. |
The enterprise customer's perception of AI value shifts completely when agents can run overnight tasks. Here's how to position and sell this transformation: