How Long-Running AI Agents Work
Long-running AI agents work on tasks for hours or days by storing progress outside the model's context window. They keep durable state and checkpoints, summarise and retrieve context instead of accumulating it, track asynchronous jobs, resume after failures, enforce budgets, and pause for human review at defined points.
What changes when a task runs for hours
Short agent tasks fit a simple loop: read the request, call tools, reason, answer. Everything lives in one context window.
Long tasks break that model in predictable ways.
Context overflow. Tool outputs, file contents, and reasoning accumulate until they exceed the window or crowd out the instructions.
Drift. The agent loses track of the original goal, repeats work, or pursues a side issue introduced hours earlier.
Process failure. Crashes, deployments, network errors, and provider timeouts interrupt runs. Without saved state, work is lost.
Waiting. Builds, data jobs, and external approvals take minutes or hours. An agent that blocks while waiting wastes resources; one that moves on can forget the job exists.
Cost growth. Every step resends context, so cost per step rises as the run continues unless context is managed.
Compounding errors. A wrong assumption early can shape hours of subsequent work.
Long-running agent design is mostly about addressing these, not about the model itself.
Why a bigger context window does not solve it
Larger windows delay overflow, but they do not provide resumability after a crash, protect against drift, or stop per-step cost from rising. A long task still needs state that survives the process and context that is curated rather than accumulated.
The architecture
Durable task state. Store the goal, plan, completed steps, decisions, open questions, and artefacts in a database or files outside the model. The model reads the relevant parts each step instead of carrying everything.
Checkpoints. After meaningful progress, save state so the run can resume from the last checkpoint rather than the beginning. Make steps idempotent where possible, so retries do not duplicate side effects.
Context compaction. Periodically replace old history with a structured summary of state, keeping recent turns verbatim. Start fresh contexts for new phases with the summary as input.
Retrieval for memory. Index notes, findings, and prior outputs so the agent retrieves specific details when needed instead of keeping them in context.
Asynchronous jobs. When starting a long tool operation, record a job identifier, expected completion, and what to do next in task state. Poll or receive callbacks, and have the agent check pending jobs at each step.
Orchestrator and workers. A coordinating process tracks the overall plan and delegates bounded subtasks to fresh agent contexts, collecting their results. Workers stay focused; the orchestrator keeps the big picture.
Observability. Log every step, tool call, cost, and decision so humans can inspect what happened and why.
Keeping track of long MCP jobs
When an MCP tool starts work that outlasts a single response, return a job handle immediately rather than blocking, expose a status tool, and write the handle into the agent's task state. The agent's loop should list outstanding jobs every step. Relying on the model to remember a job from earlier conversation is the most common way long jobs get forgotten.
Plans as data
Store the plan as a structured list of steps with status, rather than prose in context. The agent updates step status as it works, humans can read progress at a glance, and a resumed run knows exactly which step comes next.
Safety and cost controls
Budgets. Set limits on tokens, spend, time, and tool calls per run. When a limit is reached, pause and report rather than continuing.
Stop conditions. Define what done looks like and what failure looks like, so the agent does not loop indefinitely.
Human checkpoints. Require approval before irreversible or high-impact actions such as deploying, deleting, spending money, or contacting people, and at phase boundaries in long plans.
Scoped permissions. Give the agent only the tools and access the task requires. Long unattended runs magnify the damage from over-broad permissions.
Progress reports. Have the agent summarise progress at intervals so humans can intervene early when direction is wrong.
Evaluation of the outcome. Check final results with tests or review, since long runs can produce large amounts of plausible but incorrect work.
Cost control through reuse. Long runs repeatedly look up the same references and re-derive the same facts. Retrieving stored knowledge instead of regenerating it keeps per-step cost from climbing across hours of work.
Frequently asked questions
- How do long-running AI agents work?
- They store task state, plans, and progress outside the model, checkpoint regularly so they can resume, compact and retrieve context instead of accumulating it, track asynchronous jobs explicitly, and run within budgets and human approval checkpoints. The model runs inside a loop designed for persistence.
- How do you keep an agent from forgetting a long-running job?
- Return a job handle from the tool immediately, record it in durable task state with expected completion and next steps, expose a status check, and make the agent loop review outstanding jobs on every step. Do not rely on the model remembering the job from conversation history.
- Why do long agent runs drift off task?
- Accumulated context crowds out the original goal, early mistakes compound, and side issues introduced hours earlier stay in view. Regularly restating the goal from stored state, compacting history into structured summaries, and starting fresh contexts for new phases reduce drift.
- How do you control costs for long-running agents?
- Set budgets for tokens, spend, time, and tool calls, pause when they are reached, compact context so each step does not resend growing history, delegate subtasks to fresh contexts, and retrieve stored knowledge instead of regenerating the same references repeatedly.