Your Agent Dies at the Timeout

An AI agent at a cost-management vendor stayed open for four days and ran 4,819 calls for almost $4,000. That company's entire job is controlling AI spend. It lost control of one agent's spend for four days.

The reason is structural. Most teams ship agents as if they were web requests: a call comes in, work happens, a response goes out. But a real agent task makes dozens of model calls, waits on slow APIs, pauses for a human to approve something, and runs for hours. Put that on an ordinary serverless function and the platform kills it at the timeout. Halfway through. With no memory of what it already finished.

The agents are not broken. The execution model is. We covered runtimes and kill switches before. This Note covers the piece underneath both: durable execution, the difference between an agent that survives a crash and an agent that starts over and re-pays for everything it already did.

THE REQUEST-RESPONSE HABIT

Why did the web request mental model get baked into everyone's infrastructure? Because for twenty years it was the right model. A request comes in, the server does a bounded amount of work, a response goes out. The platform guarantees the function runs for a fixed window, then it dies. That is the contract.

Serverless timeouts are simple to understand. The platform kills your function after N seconds, period. On AWS Lambda the default is three seconds. On Cloud Functions it is sixty. Whatever the number, the platform enforces it mechanically. Your code does not get to argue.

An agent violates every assumption in that model. It runs for hours, not seconds. It waits on slow external APIs. It pauses for a human to approve a step. It holds multi-step state across dozens of model calls. None of that fits inside a request window.

The essay that made the rounds today put it plainly: an AI agent is a background job, not a web request. A request asks a question once. A job runs until it is done or someone stops it. Those are different infrastructure problems, and most teams are still building for the first one.

WHAT A CRASH ACTUALLY COSTS

Walk the failure mode through. Your agent dies at the timeout halfway through a workflow. It has already made paid model calls. It has already written partial results. It has already consumed tokens. Restart from scratch and you pay for all of it twice.

That is the quiet cost. Nobody budgets for the double charge. The first run is not free because it failed. Every model call you already paid for is gone, and the re-run pays for it again.

The four-day case shows what happens when the execution layer has no notion of budget, progress, or stopping. The Revenium agent ran 4,819 calls for $3,762. Nobody had budgeted for it. No alert fired. The company that makes its living controlling AI spend did not notice until the bill arrived.

The temporal-blindness analysis from The Decoder explains why. Agents cannot track how long operations take. They cannot tell you how long they have been working. They are not even aware of the limitation. So an agent cannot notice it has been running too long, because it has no clock. The infrastructure has to keep time for them.

THE CHECKPOINT-RESUME-VERIFY PATTERN

The fix is a named pattern you can build and quote: Checkpoint-Resume-Verify. Three parts.

Checkpoint. Persist agent state after every completed step, not at the end. Each checkpoint records what was done and what is left. The state lives outside the process, in a database or a durable queue, not in memory.

Resume. On crash or timeout, reload the last checkpoint and continue from there, not from scratch. Idempotency keys on every external action so a re-run does not double-charge or double-write. The key is the guard that makes resume safe.

Verify. At each checkpoint boundary, run a cheap deterministic check on the work so far. Do not trust the agent's own claim of progress. Verify it mechanically.

Here is the pattern as a small pseudo-code loop, so you can see the shape:

def check_and_persist(step, idempotency_key):
    if replay_log.has(idempotency_key):
        return  # already done, do not re-run or re-pay
    result = run_step(step)
    checkpoint.persist(step, result, idempotency_key)
    return result

for step in workflow:
    check_and_persist(step, key(batch_id, step))

The key is checked before the step runs, and the checkpoint is written after it completes. Crash anywhere in between and the next resume skips the work instead of repeating it.

You do not have to build all of this yourself. Established durable execution tools give you a ready-made path: Temporal and Restate provide durable workflows, checkpoints, and idempotency keys as a managed runtime, and even a database-backed queue that acts as a state machine covers most of the pattern for simpler tasks.

The verify step is where the tools from today's feed fit. Hedgemony catches AI code hallucinations deterministically, without asking another model to judge. VajraClaw enforces execution guardrails at the runtime level in under a microsecond, not at the prompt level. Both are the same idea: check the work mechanically, at the boundary, not by trusting the agent.

Anthropic's AI-native SDLC playbook makes the same point at the workflow level. Six stages, and each one commits an artifact the next stage reads. Stage 4 is the feedback loop where the agent verifies its own output. The mirrord critique of that playbook is the sharp part: Stage 4 only works if the agent runs against real infrastructure, not process documents. Checkpoints are those artifacts. They are the durable record that lets a crashed run resume and a verified step stand.

THE THREE-QUESTION TIMEOUT AUDIT

Here is a decision rule you can apply in ten minutes. For every agent in production, answer three questions.

1. One. Where does this agent's state live if the process dies right now? If the answer is "in the process," it dies.
2. Two. If this step re-runs, does anything double-charge or double-write? If yes, you have no idempotency.
3. Three. How does this agent know it has been running too long, and who enforces that? If the answer is "nobody," you have a four-day agent waiting to happen.

Any "I don't know" answer means the agent is not production-ready, regardless of how smart the model is. The model is not the risk. The execution model is.

WHAT TO DO TODAY

1. One. List every agent you have in production and ask where its state lives if the process dies right now. Write the answer down.
2. Two. Find your longest-running agent task and compare its worst-case runtime to your platform timeout. If the task is longer, you already have a scheduled failure.
3. Three. Add an idempotency key to every external write or paid call your agents make.
4. Four. Add a checkpoint after every completed step of your longest workflow, persist it outside the process, and test resume by killing the process mid-run.
5. Five. Put a hard spend cap and a wall-clock time limit on every agent, enforced by the runtime, not by the prompt.
6. Six. Re-read "Your Agent Has No Kill Switch" and confirm your checkpoint system gives that kill switch something to resume from.

THE UNCOMFORTABLE QUESTION

Your agent made 4,819 calls over four days and nobody noticed until the bill arrived. If your execution model cannot survive a timeout, what exactly do you think you shipped?