Long-running agents are agents that operate across extended timeframes rather than a single request-response turn. They monitor systems, perform research, execute multi-step workflows, wait on events or human approval, and coordinate work over hours or days. The defining property is not that the agent is smarter. It is that the run outlives the request that started it.
That one change breaks most of the assumptions a short-lived agent gets away with. The run will not fit in the context window. The process running it will be interrupted, because every process eventually is. And the world the agent observed at hour one will not be the same world at hour nine. Everything else in this entry follows from those three facts.
When many of those runs are active at once, swarm management is the control plane that keeps them addressable, bounded, and recoverable.
Key takeaways
- A run that outlives its request needs externalized state, because in-process memory disappears on the next deploy, restart, or timeout.
- Context is a budget spent over the whole run, not per call. Compaction, summarization, and keeping large artifacts behind references are the standard responses, and each loses something.
- Assume interruption rather than defending against it. Durable execution and checkpointing exist so a restart resumes from the last completed step instead of starting over.
- Anything the agent read early can be stale later. Cache with timestamps, re-read what changes, and expect credentials to expire mid-run.
- Evaluation moves to the task and session level. Scoring individual responses tells you almost nothing about whether a nine-hour run accomplished the goal.
What actually breaks
Context does not fit. A run with hundreds of steps generates far more tokens than any window holds, so something gets discarded or compressed at every step. The failure this creates is specific: a constraint given in the first message is summarized away deep into the run, and the agent violates it without knowing it existed. Keep task-level constraints in a structured, always-included section of the prompt rather than trusting them to survive history compaction.
The process dies. Deploys, pod evictions, out-of-memory kills, network partitions, API timeouts. Over hours these stop being edge cases and become expected events, and if the run’s state lives only in process memory, each one destroys hours of work.
Time changes the inputs. The ticket was updated. The auth token expired. The file it planned to edit was deleted. Short agents are effectively transactional. Long ones are not, and they have to re-validate assumptions before acting on them.
Cost compounds quietly. A loop that wastes tokens on every step is trivial across a handful of steps and expensive across hundreds, so budget caps have to be enforced against cumulative spend rather than per-call size.
Nobody is watching. No user sits waiting for the output, so a stuck agent can spin for hours before anyone notices. Progress heartbeats and a no-progress detector are worth more than they sound.
What you build in response
Externalized state. The authoritative record of what has happened lives in a store keyed by a run identifier, not in a variable, so a different worker can pick the run back up.
Durable execution and checkpoints. Persist each completed step so a resumed run skips work it already did. Checkpointing is the mechanism, durable execution is the guarantee it provides, and both have their own entries in this glossary.
Idempotent tool calls. Once resumption exists, a step can be attempted more than once. Any call with a side effect needs an idempotency key derived from the run and step, so the external system deduplicates the repeat instead of issuing a second refund.
Budgets and deadlines. Cumulative token and dollar caps, a wall-clock deadline, and a step ceiling, all enforced by the runtime rather than requested in the prompt.
Event-driven waiting. An agent waiting three hours for an approval should not hold a process open and poll. Persist the run, register the wake condition, and resume when the event arrives. This is why long-running agents end up on workflow infrastructure rather than in a request handler.
Human checkpoints. Long autonomous stretches accumulate error. Approval gates before irreversible actions bound the blast radius and double as natural resume points.
A fleet of these adds its own problems, since concurrent long-lived runs contend for rate limits, budget, and shared state. The operational questions around owning long-running agents at scale are about scheduling and supervision rather than prompting.
Evaluating a run that takes nine hours
Per-response scoring falls apart here. The unit of success is the task, and three things are worth measuring:
- Task outcome. Did the run produce the required end state, verified against the external system rather than the agent’s own claim of success. Agents report completion they did not achieve.
- Trajectory quality. Were the steps reasonable, or did it reach the right answer through forty redundant searches. Cost and reliability both live here.
- Progress over time. Whether state is advancing at all midstream. Stall detection catches problems hours before the final output would.
Long-horizon tasks are hard to benchmark honestly, and published long-horizon agent benchmarks measure quite different things from one another, so a score from one transfers to your workload less than the number suggests.
Instrumentation has to match the shape of the work. A trace spanning days needs a stable session or run identifier that survives restarts, or a single logical run shows up as fourteen unrelated traces. Sampling changes too, since keeping every span of every long run gets expensive, so teams commonly keep full detail for failed runs and sample successful ones. The practicalities of tracing and evaluating agents across a full session matter more here than in a chat application, because no user is in the loop to notice that something went wrong.
FAQ
How long does a run have to be to count as long-running?
There is no threshold, and the useful test is structural rather than temporal. If the run can outlive the request that started it, exceed a serverless function timeout, or survive a deploy, it is long-running and needs persistence. That can happen at ninety seconds. A run that always finishes inside one request does not need any of this machinery, regardless of how many steps it takes.
What happens when the process dies mid-run?
With in-process state, the work is gone and a retry starts from zero. With persisted state and per-step records, the runtime restores the run and continues from the last completed step. The remaining hazard is a step that was executing when the crash happened: it may have completed its external effect without recording it, which is exactly the case idempotency keys exist to handle.
How do you stop a long-running agent from drifting off task?
Re-anchor it. Keep the goal and hard constraints in a structured section of the prompt that never gets compacted, re-validate the plan against the original task periodically, and enforce limits in code rather than instructions. Drift usually starts as context loss, not a change of intent, so the fix is in context assembly more often than in wording.
Do long-running agents need a workflow engine?
Not necessarily, but they need what one provides: durable state, resumable steps, timers, and retries with backoff. Teams either adopt infrastructure with those properties or rebuild a partial version of it. The rebuild holds up until the first multi-day pause.
How do you control cost on runs that last hours?
Enforce a cumulative budget in the control loop and stop the run when it is exhausted rather than checking individual call sizes. Then attack the two largest line items: context that grows without compaction, and repeated tool calls that produce nothing new. Both are visible per step in traces, and both usually save more than swapping to a cheaper model.
