Long-Running AI Agents

A request/response agent lives and dies inside one HTTP handler. Once an agent's work outlives a single request — because it's waiting on something, or doing a lot — the naive approaches break down. Keeping a worker blocked for hours is wasteful and fragile; the moment it restarts, the run is gone.

Long-running agents routinely have to cope with:

• Runs that last minutes, hours or days, not milliseconds.
• Human approval pauses in the middle of otherwise automated work.
• Rate limits that force backoff and spread work over time.
• External asynchronous jobs the agent must poll until they complete.
• Timer-based execution — "check again in an hour," "escalate after a day."
• Worker restarts and rescheduling under the orchestrator.
• Deployments that land while runs are in flight.

Waiting as durable state

The key move: a wait is not a blocked thread — it's a persisted position plus a wake condition. The run records "I'm paused at step 7 until time T (or event E)" and gives up the worker. This is what lets a run "sleep" for days cheaply.

Checkpoint recovery

Because progress is checkpointed, a restart doesn't reset the agent. Recovery means loading the last checkpoint and continuing, so elapsed work is preserved across crashes and deploys.

Deployment survival

Long-running runs must outlive the code that started them. Durable state decouples a run's lifetime from any single process or release, so shipping new code doesn't drop in-flight agents.

Idempotent resumption

When a run resumes, already-completed side effects must not repeat. Idempotency keys make "continue from here" safe even if the last step was interrupted after acting.

• Checkpointed runs. Every node records durable state as it completes, so a run always has a resume point.
• Resume across restarts and deploys. An interrupted run continues from its last checkpoint on the next available worker.
• Approvals without idle workers. A run suspends on a human decision and wakes when it arrives, holding state rather than a process.
• Retries with backoff. Rate limits and transient errors are absorbed over time instead of killing the run.
• Full event history. Even a multi-day run has a complete, replayable timeline of what happened and when.

What counts as a long-running AI agent?

Any agent whose work spans well beyond a single request/response — minutes, hours or days. Examples: an agent that polls an external job until it finishes, one that waits on a human approval, or one that runs a multi-stage pipeline across scheduled windows.

How can an agent run for days without holding a worker the whole time?

By modeling waiting as durable state. When an agent hits a timer, a backoff window, or an approval, it persists its position and releases the worker. A scheduler wakes the run when the wait is over and resumes it on any available worker, so no process sits idle for days.

What happens to a long-running agent during a deployment?

With durable execution, an in-flight run is checkpointed, so a deployment that restarts workers doesn't lose it. After the deploy, the run resumes from its last checkpoint on a fresh worker instead of failing or restarting.