Long-running agents that take hours require durable execution rather than a simple in-memory loop, meaning the agent's state must be checkpointed to persistent storage after each meaningful step so the task can survive a process restart, deployment, or infrastructure failure without losing hours of progress. Workflow orchestration engines such as Temporal, or the checkpointing built into LangGraph, are designed specifically for this pattern, automatically persisting state and allowing a task to resume exactly where it left off rather than restarting from scratch. The execution environment should run as a background job or queued worker process rather than tied to a single synchronous request, since no HTTP request should stay open for hours, and the system needs a way to notify the user or trigger the next step asynchronously when the task completes or needs input. Cost and runaway-execution controls matter even more for long-running tasks, since a stuck agent left unchecked for hours can accumulate substantial token costs before anyone notices, making step limits, time budgets and periodic health checks essential rather than optional. Providing visibility into progress partway through, rather than only a final result, also matters for user trust on tasks that take this long. Nanobase AI builds these durable, checkpointed execution patterns for clients running long multi-hour research, analysis or migration agents.
Three execution architectures compared
A task that takes hours cannot live inside a single HTTP request or an in-memory process, since either one dying loses all progress with nothing to resume from. Choosing the right execution architecture upfront avoids the common failure mode of an agent that works fine in a short demo and then loses hours of progress the first time it hits a routine deployment or restart.
| Architecture | How state survives a restart | Best fit |
|---|---|---|
| Synchronous HTTP request | It does not; a dead request loses everything | Never appropriate for multi-hour tasks |
| Queue-based background worker | State written to a database or cache after each step; worker picks up where it left off | Most multi-hour agent tasks with well-defined steps |
| Workflow orchestration engine (e.g. Temporal-style) | Automatic durable execution and replay built into the engine | Complex, long-running workflows needing strong guarantees and built-in retry logic |
| Graph framework with built-in checkpointing | State persisted at each graph node automatically | Teams already using a graph-based orchestration framework for the agent's control flow |
Why checkpointing after every meaningful step matters
Checkpointing only at the very end of a multi-hour task defeats the purpose entirely, since a failure at hour three still loses three hours of work. The state must be persisted to external storage after each meaningful step, not just the final result, so a process restart, a deployment, or an infrastructure failure loses at most the work since the last checkpoint rather than the entire task. This also means the execution environment cannot rely on anything held only in local process memory surviving between steps; every piece of state the next step needs has to be readable from that external store.
Controls that keep a long task from running away
- Set an explicit time budget per task, not just a step count limit, since some steps can individually run long even within a reasonable total step count.
- Cap the maximum number of steps or tool calls regardless of elapsed time, catching a task stuck in an unproductive loop that has not yet exceeded its time budget.
- Track cumulative cost per task in real time and halt if it exceeds a threshold well before the task would naturally complete, since a stuck agent left unchecked for hours can accumulate substantial spend before anyone notices.
- Run periodic health checks that verify the task is making forward progress, not just still running, since a hung process consuming resources without progressing is a distinct failure mode from one still working correctly.
- Alert a human when any of these limits trigger, rather than only logging it silently, so a stuck task gets attention promptly instead of being discovered hours later. Alerting a human when any limit triggers, rather than only logging it, gets a stuck task attention before it becomes expensive.
Giving users visibility during the wait
A task that runs silently for hours and then returns only a final result erodes user trust even when it eventually succeeds, since there is no way to tell a slow-but-working task apart from a stuck one from the outside. Providing intermediate progress updates, what step the task is currently on, what has been completed so far, and an estimated time remaining where feasible, matters as much for trust as the final output's quality once a task's duration crosses from seconds into hours. Intermediate progress updates matter as much for trust as the final output's quality once a task's duration crosses from seconds into hours.
Frequently asked questions
Does a long-running agent need a dedicated workflow engine, or can a simple queue suffice?
A simple queue with a database-backed checkpoint often suffices for tasks with straightforward, mostly linear steps; a dedicated workflow engine earns its added complexity for tasks with complex branching, frequent retries, or strict durability guarantees that a hand-built queue system would need to reimplement anyway.
How does this connect to LangGraph's checkpointing feature?
LangGraph's built-in state persistence provides exactly this kind of checkpoint-and-resume capability for teams already using it for the agent's control flow, removing the need to build a separate durability layer from scratch.
What is a reasonable time budget to set for a multi-hour agent task?
It depends entirely on the task, but the budget should be set based on the slowest realistic legitimate completion time observed during testing, with meaningful margin, rather than an arbitrary round number, so it catches genuinely stuck tasks without prematurely killing slow but valid ones.
Should long-running agents run on the same infrastructure as short, interactive ones?
Generally no. Long-running background workers benefit from separate scaling and resource policies from short, latency-sensitive interactive agents, since mixing the two on the same pool of resources makes capacity planning and autoscaling harder for both.
How Nanobase AI helps
Nanobase AI builds durable, checkpointed execution patterns for clients running multi-hour research, analysis or migration agents, using queue-based workers or workflow engines depending on the task's actual complexity, paired with time budgets, cost caps and progress visibility so a long-running task stays observable and controllable rather than a silent black box.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.