- Home
- AI agents
- Orchestration and multi-agent systems
- Long-running agents
Build · Orchestration and multi-agent systems
How do you build AI agents that run for hours or days?
A long-running agent works on one task for hours or days, across many model sessions, process restarts and waits for people or events. It keeps its progress outside the model in a durable log, a session store and files, so it can resume where it stopped instead of starting over, within limits on time, tokens and actions.
In this guide: 83 pages
Key takeaways
- Three things break first in a long run: the context window fills, the process dies, and a wait for a person holds compute. Each has its own fix, and a long-running agent needs all of them.
- Measured horizons are shorter than the marketing. METR put the frontier’s 50% time horizon at about 12 hours and its 80% horizon at about 1.5 hours in Feb to Mar 2026; runs of a day or more are vendor claims.
- Managed runtimes now host long sessions: AgentCore Runtime runs up to 8 hours on microVMs or 14 days on Instances, and Claude Managed Agents and the OpenAI Agents API save progress outside the harness.
- Give every long run a budget, a progress record a person can read, idempotent writes and a stop button outside the agent.
What breaks when an agent runs for hours?
Three separate limits come into play. The context window fills with history and tool output, the process that runs the loop restarts or crashes, and the agent has to wait for a person or another system for longer than any process should stay up.
Anthropic states the first problem directly: “The core challenge of long-running agents is that they must work in discrete sessions, and each new session begins with no memory of what came before.” Its fix for coding work is an initializer agent that sets up the environment and a progress record, then a coding agent that takes one feature per session from a JSON feature list and leaves notes for the next session.
Behaviour degrades as well. Anthropic lists the failures it saw: trying to do everything at once and running out of context, declaring victory early, and marking features done without testing them end to end. METR’s report of 19 May 2026 adds a warning about measurement: on tasks over eight hours, at least 16% of the successful runs it reviewed were illegitimate, because the agent had cheated its way to a pass.
Plan around measured horizons. METR estimated the public frontier’s 50% time horizon, the task length in human time that an agent completes half the time, at about 12 hours (range 5 to 61 hours) in Feb to Mar 2026, with the 80% horizon at about 1.5 hours. Anthropic quotes a tester saying Claude Opus 5.5 stayed on task for over 18 hours, and Google says Gemini 4 Carbon has been seen to run for days; both are vendor claims. These measure task length, not runtime limits: scope each unit of work well inside the 80% figure, and set checkpoint intervals by how much work you can afford to redo.
Where does a long-running agent keep its state?
In three layers, each covering a different failure: a durable execution log for crashes and redeploys, a session runtime for the sandbox and its files, and the context itself, trimmed by compaction and backed by progress notes the next session reads.
Three layers of state for a long run, with products as documented on 2 Nov 2026.
| Layer | Protects against | How it works | Products |
|---|---|---|---|
| Durable execution | Crashes, redeploys and long waits | Each finished model, tool or agent call is written to a log; after a restart the run replays it and skips finished steps | Temporal; LangGraph checkpointers; Agent Framework checkpoints and Durable Extension (preview at 1.0); AWS Lambda durable functions; Step Functions |
| Session runtime | A lost sandbox, files or processes | Each run gets an isolated environment that persists for the session | AgentCore Runtime, up to 8 hours on microVMs or 14 days on Instances; Claude Managed Agents with a session log outside the harness; OpenAI Agents API |
| Context | A full window and lost detail | Older turns are summarised or cleared; progress goes to files or memory the next session reads | OpenAI server-side compaction (Feb and Mar 2026); Anthropic compaction and context editing (beta); progress files and git history |
Claude Managed Agents makes the split visible: the session log is append-only and lives outside the harness, so a crashed harness calls wake(sessionId) and resumes from the log (Anthropic, 8 Apr 2026). Treat the log as the source of truth and the running process as replaceable. Orchestration code must be deterministic for replay to work, which is why Agent Framework asks for agents to be obtained through its context so each call is tracked and checkpointed.
How should a long-running agent wait for people and other systems?
By suspending, never by holding a process open. Durable engines park the run at a callback or a timer and charge little or nothing while it waits, and agent-to-agent protocols give the remote side a way to say it needs input.
On AWS, Lambda durable functions suspend for up to one year, context.wait() incurs no idle compute charge, and create_callback() pauses for a human decision; Step Functions Standard workflows run up to one year with exactly-once semantics and use the .waitForTaskToken callback for approvals, while Express workflows stop at five minutes. On Azure, the Agent Framework Durable Extension lets orchestrations wait for days or even weeks, and on the Flex Consumption plan a 24-hour approval wait costs seconds of execution.
Between agents, A2A 1.0 models the wait as task state: a remote agent moves a task to INPUT_REQUIRED or AUTH_REQUIRED when it needs information or credentials, and the caller follows progress by streaming or through push notifications to a webhook. Foundry keeps A2A tasks and contexts for 60 days when it is the remote agent. MCP moved long-running tasks out of its core into the io.modelcontextprotocol/tasks extension, in beta, where a client polls tasks/get.
A suspended run still needs a deadline. Put a timeout on every wait, an escalation when it expires, and a rule for what the agent does with stale work when the answer finally arrives.
What controls does a long-running agent need?
Limits it cannot exceed, records a person can read, writes that are safe to replay, and a way to stop it from outside. The longer the run, the more each of these matters, because nobody watches every step.
- Budgets per run. Cap wall-clock time, tokens, tool calls and spend, and end the run cleanly when one is reached. Anthropic found its multi-agent research system used about 15 times the tokens of a chat, so a long run with subagents spends quickly.
- Progress a person can read. Keep a plain progress file or task list next to the trace, so a reviewer sees what is done, what is next and why without replaying the run.
- Idempotent side effects. Replay re-runs steps that were not recorded as finished, so a payment or email tool needs an idempotency key. Asynchronous Express workflows in Step Functions are at-least-once, which makes this mandatory there.
- Versioned deployments. Anthropic ships agent changes as rainbow deployments so in-flight runs keep the version they started on; a run that switches prompts or tools halfway through is hard to debug.
- Verification before done. Require an end-to-end check, a test suite or a reviewer, before the agent may mark a task complete.
- Credentials that outlast the run. Use identities that renew themselves, as Google’s agent identities do with certificates valid for 24 hours, or fetch a token per step from a vault.
- A stop button outside the agent. An operator must be able to pause or cancel the run in the orchestrator and revoke the agent’s identity without the agent’s cooperation.
How do Microsoft, AWS and Google implement it?
Long-run building blocks on each cloud, with statuses as the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Long sessions | Foundry hosted agents, suspended between turns so you pay only for active execution | AgentCore Runtime, up to 8 hours on microVMs or 14 days on Instances | Agent Runtime, described as supporting long-running agents; Gemini Enterprise long-running agents announced 22 Apr 2026 |
| Durable orchestration | Agent Framework checkpoints; Durable Extension on the Durable Task Scheduler (preview at 1.0) | Lambda durable functions; Step Functions Standard workflows | ADK 2.0 Workflow Runtime with sessions on Agent Runtime |
| Waiting for a person | Durable Extension waits of days or weeks; seconds billed on Flex Consumption | The .waitForTaskToken callback; durable callbacks with no idle charge | Human input nodes in ADK 2.0 graph workflows |
Outside the clouds, Claude Managed Agents (beta since 8 Apr 2026) and the OpenAI Agents API (public beta since 10 Sep 2026) host long runs and save progress for you, and Temporal’s integration with the OpenAI Agents SDK is generally available (23 Mar 2026).
Frequently asked questions
How long can an AI agent run today?
Platforms allow long sessions, up to 14 days on AgentCore Instances, but reliable task length is shorter. METR measured a 50% time horizon of about 12 hours and an 80% horizon of about 1.5 hours for the public frontier in Feb to Mar 2026, so scope each unit of work well inside those task lengths and verify it before the next one starts.
What is the difference between durable execution and agent memory?
Durable execution records the steps of one run so it can resume after a crash; memory keeps facts across runs so a later task can use them. A long run usually needs both: the log to recover, and memory or progress files to carry knowledge from one session to the next.
Do we need Temporal or Step Functions for a long-running agent?
You need some durable engine once a run outlives a process or waits for a person. It can be a general engine such as Temporal or Step Functions, a framework feature such as LangGraph checkpointers, or a managed agent runtime that saves progress for you; pick the one your platform team already operates.
How do we stop a long-running agent that has gone wrong?
From outside the agent: cancel the run in the orchestrator, disable the agent’s identity, and withdraw its tools at the gateway. Test the stop path before launch, because a run that is waiting on a callback or working in a sandbox may never read a message sent into its conversation.
More in Orchestration and multi-agent systems
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Effective harnesses for long-running agents
- Frontier Risk Report (Feb to Mar 2026)
- Claude Opus 5.5
- Introducing Gemini 4 Carbon
- How we built our multi-agent research system
- Scaling Managed Agents: decoupling the brain from the hands
- AgentCore Runtime
- Agents guide
- OpenAI API changelog
- Announcing the OpenAI Agents SDK integration
- LangGraph durable execution
- Durable Extension (Microsoft Agent Framework)
- Microsoft Agent Framework version 1.0
- Foundry hosted agents now generally available (Azure update AZ563596)
- Build multi-step applications and AI workflows with AWS Lambda durable functions
- Choosing workflow type in Step Functions
- A2A protocol specification, version 1.0.0
- Agent-to-agent tool in Foundry Agent Service
- Model Context Protocol specification changelog, 2026-07-28
- Agent identity for Agent Runtime
- Gemini Enterprise Agent Platform overview
- Welcome to Google Cloud Next ’26
- adk-python v2.0.0 release
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner