Long-running tasks

Overview

Some agent tasks finish in seconds. Others take hours: migrating a codebase, building an application feature by feature, researching a market, processing thousands of documents, or training and evaluating a model. Long tasks bring problems that short ones never meet. The context window fills up. Processes crash and networks drop. People close their laptops. Small errors compound over hundreds of steps, and costs keep rising while nobody watches.

Designing for long-running work means making progress durable and visible. The agent should be able to stop at any moment and continue later, either itself or as a fresh session, without repeating or losing work.

Think of a long hike. A short walk needs no planning. A multi-day trek needs a route, a notebook of where you are, supplies, checkpoints and a plan for bad weather. If you twist an ankle on day three, your companion can read the notebook and know exactly where you were heading. Long-running agents need the same: a written plan, saved progress, a running log, regular checks and clear rules for when to stop.

What it is

"Long-running task" is not one product. It is a set of design techniques that work together.

Where it came from

Long-running, resumable work is an old problem in computing. Batch systems, database transactions and workflow engines have long used checkpoints, logs and retries. What changed with AI agents is that the worker itself has limited memory, the context window, and makes probabilistic decisions.

Through 2024 and 2025, agents became capable of longer stretches of independent work. In March 2025 the research group METR published a study measuring the length of tasks, in human working time, that models could complete, and reported that this time horizon had been doubling roughly every seven months. As tasks grew from minutes to hours, harness design became as important as model quality.

Practical patterns spread quickly. Coding agents adopted plan files, progress logs and context compaction. In November 2025 Anthropic's engineering team described a harness for multi-session coding work: an initializer agent sets up the project, a feature list and a progress file, and later coding agents work on one feature at a time, commit, and update the log. Protocols added support too. The A2A protocol models work as tasks with states, and MCP added a tasks mechanism so a tool call can return a handle immediately and deliver its result later.

How it works

1. Set up the plan

At the start, the agent, or a dedicated setup agent, turns the request into a written plan on durable storage: a list of steps or features, each with a test or acceptance check. A structured format such as JSON is harder for the model to rewrite casually than free text. Every item starts as not done.

2. Work in small, verified increments

Each session or loop picks one item, does it, verifies it and records the result. Doing one thing at a time stops the agent from running out of context halfway through a large change. Verification matters most: unit tests alone often miss problems that an end-to-end check would catch.

3. Checkpoint and log

After each verified item, the agent saves a checkpoint, for example a commit, and writes a short entry in the progress file: what changed, what passed, what is next. If something later breaks, the history makes it possible to go back to a known good state.

4. Manage context

As the session grows, older turns are compacted into a summary that keeps the plan, decisions and open questions. Large reading or searching jobs go to sub-agents so their raw output never enters the main context. See context engineering.

5. Resume cleanly

When a session ends, by design or by accident, a new session starts by reading the plan, the progress file and the recent history, running a quick health check, and then continuing with the next item. Nothing depends on what the previous session "remembered".

6. Expose progress

For callers, long work should return a handle at once. The caller can poll, stream progress or receive a notification. Durable execution engines add retries, timers and resume-after-crash for each step.

Key concepts and terms

A worked example

This is an illustrative scenario. An agent must upgrade a web service from one major framework version to the next. The change touches about 200 files.

1. Setup. The agent writes migration-plan.json with 20 batches of about ten files each, grouped by module. Each batch has the command that verifies it. It writes progress.md with "0 of 20 batches done" and makes a commit.
2. Batches. For each batch it updates the files, runs the module's tests, commits, and appends a line such as "Batch 7: 11 files, 64 tests pass, commit a1b2c3".
3. Context. After batch 9 the session is long, so the runtime compacts it. The plan and progress file are on disk, so nothing important is lost.
4. Interruption. During batch 12 the machine restarts. A new session reads the plan, sees 11 batches marked done, checks that the last commit builds, and starts batch 12 again from a clean state.
5. Problem. Batch 15 fails twice on the same test. The agent records the failure, skips the batch and moves on, as the plan allows.
6. Budget. The run has a limit of six hours. It finishes in four hours twenty minutes.
7. Report. The final message lists 19 of 20 batches done, 1,240 tests passing, and one batch needing a person, with the error and the agent's best guess at the cause.

Strengths and limitations

Strengths:

• Agents can finish large tasks without a person watching every step.
• Work survives crashes, restarts and context limits.
• A clear written record makes review and hand-over easy.
• Small verified steps catch problems early.

Limitations:

• Errors can compound over many steps if verification is weak.
• Costs can grow quietly without budgets and alerts.
• Compaction can drop details that turn out to matter.
• Agents may declare victory early unless the plan defines full scope.
• People may not notice drift until a late review.

How it compares with alternatives

Practical guidance and best practices

1. Write the plan and progress to durable storage, never only into the context.
2. Define full scope up front so the agent cannot finish early by forgetting items.
3. Work one item at a time and verify each one, ideally end to end.
4. Checkpoint after every verified step so you can always return to a good state.
5. Make steps idempotent, so a repeated step after a crash does no harm.
6. Set budgets for time, tokens and money, with alerts; see cost and latency budgets.
7. Send large reading and searching jobs to sub-agents.
8. Return task handles to callers and show progress somewhere a person can see it.
9. Ask for a final report: what changed, what passed and what remains.
10. Add review points for a person on risky or irreversible steps; see human in the loop.

Common mistakes

• Keeping the only copy of the plan in the model's context.
• Asking for the whole task in one go, so the agent runs out of context halfway.
• Marking steps done after a weak check, such as a single unit test.
• Letting later sessions edit or delete items from the plan.
• Running for hours with no budget, alert or progress view.
• Discovering at the end that a step early on was wrong, because nothing was verified along the way.

Frequently asked questions

Why do long agent tasks fail?

The usual causes are context limits, crashes, compounding errors, early declarations of success and unbounded costs. Written plans, progress files, checkpoints, verification and budgets address each of these.

What is context compaction?

It is replacing older parts of a conversation with a summary, so the agent can keep working without exceeding its context window. Compaction should keep the plan, key decisions and open questions, which is why those also belong in files.

How do clients wait for long tasks?

Through task handles. The server returns an id at once, and the client polls for status, streams progress or receives a notification when the result is ready. A2A and MCP both include mechanisms for this.

Do I need a workflow engine?

Not always. For many coding and research tasks, files and version control give enough durability. A workflow engine helps when steps call external systems, must never repeat or must wait for days, as in business processes.

How long can agents work on their own?

It depends on the model, the harness and the task. Measured time horizons have grown quickly, but reliability on your own work is what matters, so test on representative tasks and add checkpoints and reviews.

How do I stop a long task from drifting?

Fix the scope in a structured plan, verify each step against it, review the progress file at intervals and require approval before the agent changes the plan.

Glossary

• Checkpoint: a saved, known good state.
• Progress log: a running record of steps taken and results.
• Compaction: summarising older context.
• Handle: an id for work that completes later.
• Idempotency: the property that repeating a step has no extra effect.
• Resume: continuing from saved state after an interruption.
• Scope: the full list of what the task must deliver.
• Drift: slow movement away from the goal.
• Budget: a limit on time, tokens or money.

Summary

Long-running agent tasks outlive a single context window and often a single process, so they need durability by design. Write the plan and progress to disk, work in small verified steps, checkpoint after each one, compact context and delegate large reading to sub-agents, return task handles to callers and enforce budgets. With these habits, agents can work for hours, recover from interruptions and finish with a clear, reviewable record.

Related

It belongs to Coding and computer agents in my stack, under Agentic AI. Others in the same group: