State in long-running agents: what breaks after step three

Key takeaways

• Long-running agents fail when their internal state diverges from external reality — a record updated by another process, a session that expired, a rate limit that was not anticipated after step two.
• State corruption compounds: by step five of a ten-step agent, a stale assumption from step two has influenced every downstream decision, and the final output is wrong in ways the agent cannot detect.
• The fix is checkpointed state with external verification: at each step, read the authoritative source before writing, not just the agent's internal model of it.
• Design for interruption from the start — every agent should be able to resume from a checkpoint, not just restart from zero. Restart-on-failure is expensive; checkpoint-and-resume is cheap.

Your agent read the metadata at step 1. By step 5, a human had changed it. The brief is wrong, and the agent has no idea.

This is state drift — the gap between what an agent believes about the world and what is actually true. It is the most common failure mode in production agentic systems, and it is almost never caught until something ships broken.

What state drift actually means

State is the agent's internal model of the world: the values it read, the assumptions it made, the decisions it cached. Reality is what is actually in the systems at any given moment.

In a short, single-step task, the gap between state and reality is negligible. In a multi-step agent run — especially one that spans minutes or hours — the gap compounds. Every step the agent takes on stale data is a step in the wrong direction.

The content brief example is instructive because it looks fine from the outside. The agent completes. It returns a document. No error is thrown. The problem only surfaces when a human reads the brief and notices the target keyword, audience segment, or product name is wrong — because someone updated the source record between step 1 and step 5.

Three failure modes

1. Stale reads

The agent reads a value once, then acts on it repeatedly across many steps.

This is the default behavior of most agent implementations. Fetch the context at the start, pass it through the chain, produce the output. It works fine when runs are short and the underlying data is stable. It breaks when either condition fails.

The fix is targeted re-reads at decision points. Before any step that produces a consequential output — a write, a branch, a final answer — re-fetch the values that output depends on. Do not assume the value you read three steps ago is still current.

2. Assumed durability

The agent writes a value and assumes the write succeeded.

Network calls fail silently. Queues back up. Databases return 200 with a deferred commit. An agent that writes a record and immediately reads it back expecting the new value will sometimes get the old one. An agent that writes and never confirms will sometimes produce downstream steps built on a write that never landed.

Every write that subsequent steps depend on needs explicit confirmation before those steps proceed. Read-after-write is not paranoia — it is the minimum viable consistency check.

3. Concurrency drift

Another process modifies the same resource the agent is working on.

This is the hardest failure mode to detect because the agent's reads can be perfectly fresh and still become stale between the read and the next action. A human edits the document. A parallel agent updates the record. A scheduled job runs. The agent's model of the resource is now wrong, and it has no signal.

The practical mitigation is optimistic locking: read a version identifier or timestamp alongside the value, and include it in any write as a precondition. If the precondition fails, the write is rejected and the agent knows to re-read before continuing. Most modern APIs and databases support this pattern natively.

The checkpoint pattern

For any agent task beyond a handful of steps, checkpointing is not optional — it is the mechanism that makes the task recoverable.

A checkpoint stores three things:

• Current step index — where in the task sequence the agent is
• Verified state snapshot — the values the agent has confirmed are current, with timestamps
• Pending decisions — any branching logic that has been resolved, so it does not need to be re-evaluated on resume

Store checkpoints in an external, durable system — not in the context window, not in a local variable. A database row, a document store entry, or a queue message with a stable ID all work. The key requirement is that the checkpoint survives the agent process dying.

Resume logic is straightforward: on start, check for an existing checkpoint at the task ID. If one exists, validate that the state snapshot is still current (re-read the critical values and compare). If the snapshot is stale, re-fetch and update before continuing. If the snapshot is current, resume from the stored step index.

This pattern eliminates both the cost of restarting from scratch and the risk of resuming on bad data.

Context window as state

There is a second, less obvious form of state drift that affects long-running agents: context window truncation.

An agent that accumulates context across many steps will eventually exceed the model's context window. When that happens, early content is dropped. The agent loses access to decisions it made, constraints it was given, and values it confirmed — without any signal that the loss occurred.

For tasks beyond roughly 15 steps, relying on the context window as the agent's memory is not a viable architecture. External memory — a structured store the agent can read and write explicitly — is required. The agent should write key decisions and confirmed values to external memory as it goes, and read from it at each step rather than relying on what is still in context.

This is the same principle as checkpointing, applied to the agent's reasoning state rather than its task progress.

The design rule

Treat your agent's internal state as a cache, not as the source of truth.

A cache is useful. It makes agents faster and cheaper to run. But a cache has an expiry, a validation mechanism, and a fallback to the authoritative source. An agent that treats its internal state as ground truth has none of those properties — it will drift, silently, until something breaks visibly enough to notice.

Build the re-read. Confirm the write. Check the version. Store the checkpoint externally. These are not edge case concerns. They are the baseline for any agent task that runs longer than a single round trip.

Frequently asked questions

Why do long-running AI agents fail partway through a task?

Long-running agents fail mid-task because they hold all working state in memory — when the process is interrupted by a timeout, API error, or resource limit, that state is lost and the agent has no way to resume. Without explicit checkpointing, the only recovery option is a full restart from the beginning. The longer the task, the higher the probability of an interruption, which makes stateless agent designs fundamentally unreliable at scale.

What is a checkpoint in the context of AI agents?

A checkpoint is a persisted snapshot of an agent's working state — including completed steps, intermediate outputs, and any context needed to continue — written to durable storage at a defined interval or decision boundary. When an agent resumes after a failure, it loads the latest checkpoint and continues from that point rather than restarting. Checkpoints are the primary mechanism for making multi-step agent workflows fault-tolerant.

How do you prevent state drift in multi-step agent workflows?

State drift occurs when an agent's internal model of the world diverges from actual external state — typically because the agent assumes earlier steps succeeded without verifying their outputs. The fix is external verification: after each consequential step, the agent reads back the result from the authoritative source (a database, API, or file system) rather than trusting its own memory. Combining read-back verification with immutable, append-only checkpoints eliminates the conditions under which drift accumulates.