What Happens When an Agent’s Work Outlives the Request?

An agent task that outlives its request needs saved state another worker can safely resume from, not just a job ID.

An agent starts preparing a production environment, then waits for approval. The user closes the browser. Later, a worker restarts while the infrastructure provider is still provisioning resources. The work needs to remain findable and recoverable through both interruptions.

A job ID helps the user ask for progress, but the ID alone cannot tell a replacement worker what to do. It needs the approved configuration, the current step, the provider’s job reference, and any pending approval. Otherwise it may restart work that the provider has already accepted.

Durable execution means saving enough task state to continue after a connection or process stops. Queues, databases, and workflow engines provide useful building blocks. The team must still define the task’s states and recovery behavior. Saving a record does not make a model’s earlier decision correct or an old permission current.

This is Post 18 in The Abstraction Shift: How Software Keeps Moving Up.

Why a background job needs more than an ID

The first agent integration often looks like a request handler:

receive request -> call model -> call tool -> return response

The pattern works while the work is short, the connection stays open, and every dependency responds before the timeout. It becomes fragile when the agent needs to do more:

wait for a deployment or data export;
ask a person to approve a consequential step;
continue after a network partition or worker restart;
poll an external job that has its own identifier;
coordinate several workers or tools;
retry a transient step without duplicating a side effect;
preserve the evidence needed to explain what happened; or
deliver a result after the user has closed the original interface.

The first workaround is usually a background job. The application writes a row, pushes a message to a queue, and returns a job ID. A worker updates a status column while another endpoint lets the client poll.

That is a useful beginning. It also leaves several questions open. What state is sufficient to resume? Which step may be retried? What happens when the worker dies after an external side effect but before recording the response? How does a human answer become part of the state machine? When is cancellation real? Which code version owns a task that started yesterday? What evidence distinguishes a completed request from a verified outcome?

A useful durable task answers those recovery questions explicitly, so the next worker acts on saved state instead of guessing from an ID.

How queues and workflows already handle waiting

Software already has several ways to represent work that outlives a request. Queues buffer messages, workers execute them, schedulers trigger them, workflow engines coordinate states, transactions protect bounded changes, sagas provide compensation, and databases store checkpoints. Each solves part of the lifecycle; none alone defines the complete meaning of a long-running task.

The familiar path looks like this:

command -> enqueue -> execute -> retry or compensate -> commit -> report

The agentic version adds an interpretation loop:

intent -> context -> model proposal -> validate -> execute -> observe -> next proposal

When that loop remains inside one request, the application can accidentally treat the call stack as the task state. When the loop crosses time, machines, people, or external systems, the state must move into an explicit task record and lifecycle.

Durability therefore predates agents. The new problem is that the control flow inside the durable task may be partly generated, the context may change while the task waits, and a retry may ask a model to interpret the same situation again under a different route or policy. The runtime has to preserve enough state to make those changes visible and governable.

What Is Durable Agent Execution?

Durable agent execution means the system can continue an agent task from saved state after a worker, process, or connection stops. For the environment-provisioning example, a new worker should be able to find the approved configuration and the provider’s job reference, then continue checking progress.

The saved task therefore needs more than a transcript or a status field. It needs enough information to determine the next permitted step and avoid repeating work that already happened. The following parts serve that recovery purpose; they can be stored as snapshots, history, or a combination appropriate to the runtime.

Part	Question it answers
Task identity	Which work is this, and how does another client or worker find it?
Intent and input snapshot	What request, parameters, and authorization context started it?
Current state	Is it working, waiting, retrying, paused, failed, cancelled, or complete?
Checkpoint or history	What steps, proposals, observations, and decisions have already occurred?
Pending work	Which timer, tool, worker, human, or external job must act next?
Retry and idempotency data	What may be retried, with which key, attempt limit, or compensation?
Version and environment	Which workflow, model route, schema, policy, and tool versions apply?
Outcome and evidence	What result was requested, what occurred, and what proves it?

This changes the abstraction from “run an agent” to “manage a task whose execution may include agent steps.”

Durable execution does not mean the model is deterministic. It means the surrounding system can recover the task’s lifecycle and make the next decision from recorded state. A model call may be replayed, reissued, or replaced by a recorded result depending on the runtime contract. A tool call may require idempotency or a reconciliation read. A human approval may arrive hours later. The task remains one governed object across those transitions.

Current task protocols make this boundary concrete through handles, progress, input requirements, result retrieval, cancellation, timers, persisted history, and worker recovery. The protocol names vary, but the design problem they address is stable.

The task abstraction adds a durable lifecycle around model-mediated work that can outlive a request or connection.

Giving the work an identity that survives the connection

The system now keeps a task that can continue while an agent proposes or revises its next steps. A proposed diagnostic or tool call can change the path, but it still needs to fit the saved task and its permissions.

A request usually asks for an immediate result. A task establishes a relationship that persists until a terminal condition or explicit abandonment. It may have intermediate states that are meaningful to the user and the runtime:

created -> working -> waiting for input -> working -> retrying -> completed

Other paths matter just as much:

working -> paused -> resumed
working -> cancellation requested -> cancelled or completed
working -> failed -> compensated or manually recovered

The task handle is the stable reference across those transitions. A user can reconnect, a worker can recover, an operator can inspect, and another component can deliver input without relying on the original HTTP request.

This boundary also changes the meaning of context. Article 17 treated structured output as a typed proposal. Article 18 adds time to that proposal. The task must know which context produced the proposal, which evidence was current then, which policy version applied, and what may be recomputed after the task waits.

Parts of the context can be replayed, others must be refreshed, and a few must be frozen for audit. A task that wakes up after a week cannot blindly treat a week-old account balance, deployment target, or permission decision as current, so durability means modeling how long each piece of context stays valid, not simply persisting a large prompt.

Where the familiar comparisons stop helping

Durable agent execution resembles a workflow engine, but several analogies stop helping if they hide the semantic differences.

A durable record is not durable meaning

Persisting a task row proves that the row survived. It does not prove that the task’s interpretation of the user’s intent remains valid. A proposal may be structurally complete and still refer to stale evidence, an obsolete resource, or a policy that has changed while the task waited.

Durability protects state. The runtime still needs semantic validation at each boundary where state becomes an action.

Retrying can repeat a side effect

Retrying a read is different from retrying a payment, sending an email, deploying a release, or submitting a job to an external provider. A worker can fail after the side effect succeeds but before the task records the response. Repeating the step may duplicate the effect.

Retries need idempotency keys, deduplication, reconciliation reads, or compensating actions. A model-generated instruction does not supply those properties.

Pausing the orchestrator may leave work running

A task can be paused in the orchestrator while a worker, external job, or already-issued request continues elsewhere. Cancellation may be cooperative, delayed, or impossible after a side effect has crossed a boundary.

The user-facing status must distinguish cancellation requested, cancellation acknowledged, work stopped, and outcome reconciled.

A terminal status is not a verified outcome

Completed can mean that a workflow reached its final state, that a tool returned a result, or that a source-of-truth system confirmed the intended change. These are different claims.

The lifecycle needs an outcome model that separates requested, accepted, committed, and verified. Otherwise, a durable task merely preserves a durable overstatement.

Persisted context goes stale

The task may resume under new model weights, a different route, an updated tool schema, changed permissions, or new external data. Replaying old context can preserve an outdated assumption. Refreshing everything can make the task’s meaning drift.

The task contract must say what is immutable, what is refreshed, and what requires re-approval.

Long-running tasks cross deployments

A new workflow version may change state names, retry behavior, tool arguments, or policy interpretation while old tasks are still open. The runtime needs version compatibility, migration, pinning, or a deliberate continue-as-new boundary, which makes code deployment part of task lifecycle design.

Saving enough state to recover the task

A durable agent task can be implemented with different technologies, but its responsibilities are recognizable:

Accept the task. Validate the structured proposal, establish the task identity, capture the input snapshot, and persist the task before returning its handle.
Record the contract. Store the schema, workflow, model route, policy, capability, and environment versions that govern the task.
Schedule the next step. Dispatch a worker, set a durable timer, wait for an external job, or expose a request for human input.
Record observations. Store tool responses, model proposals, state transitions, errors, timestamps, and provenance as separate evidence types.
Apply retry policy. Classify failures as transient, permanent, ambiguous, or requiring compensation. Retry only the step whose contract permits retry.
Handle interruption. Make worker loss, connection loss, process restart, and deployment visible as recoverable lifecycle events rather than silent disappearance.
Refresh or freeze context. At each meaningful boundary, decide which records are reread, which approvals expire, and which earlier assumptions remain part of the task history.
Accept input and cancellation. Treat human answers, clarifications, pause requests, and cancellation signals as state transitions with authorization and audit records.
Verify the outcome. Read the authoritative system, reconcile the intended result, and record whether the task completed, failed, was cancelled, or remains uncertain.
Expose a useful status. Give clients and operators a task handle, current state, next action, last update, retry information, and a path to the final result or error.

The model may interpret context, plan, classify, and propose the next action. It does not own the lifecycle merely because it selected the next step.

A durable task names the states between request and result, including pauses, retries, cancellation, and failure.

The state machine should be explicit enough to answer a simple question after a crash: what may happen next, and what must not happen twice?

Following the example through the system

Consider a customer asking an operations agent:

Prepare a new production environment from the approved configuration, ask me before provisioning, and tell me when the health checks pass.

The task may take minutes or hours. It may involve a configuration repository, policy checks, an infrastructure provider, a secrets service, a deployment job, and health checks. The browser session may disappear. The infrastructure provider may accept the request but finish later. The customer may approve from a different device.

A durable task contract might contain:

Field	Purpose	Lifecycle treatment
`task_id`	Stable reference for the work	Persist before returning the handle; never use a transient request ID as the only identity
`request_snapshot`	Original goal and approved configuration reference	Preserve for audit; do not silently rewrite the user’s request
`workflow_version`	Definition of the lifecycle	Pin, migrate, or make compatibility explicit
`state`	Current task state	Use named transitions such as `working`, `input_required`, `paused`, `failed`, and `completed`
`pending_action`	What the task is waiting for	Identify a worker, timer, external job, human, or reconciliation read
`attempts` and `idempotency_key`	Retry and deduplication data	Scope by side effect and external system
`approval_request`	Human input needed to proceed	Record who answered, what was shown, when it expires, and which step it authorizes
`external_refs`	Provider job or deployment identifiers	Use them to poll and reconcile rather than resubmit blindly
`outcome`	What actually happened	Separate provider acknowledgement from verified environment health

The runtime path is:

Validate the structured proposal from Article 17 and create the task record.
Snapshot the approved configuration reference and record the workflow, tool, policy, and model-route versions.
Run deterministic checks for required resources, environment scope, and change policy.
Move to input_required with a review that names the target, scope, expected cost, and irreversible steps.
Resume only after the approval response is authenticated, unexpired, and bound to this task and configuration.
Submit the provisioning request with an idempotency key and persist the provider’s job identifier before the worker reports success.
Poll or receive updates for the provider job. If the worker crashes, another worker resumes from the provider reference.
Run health checks and distinguish healthy, unhealthy, incomplete, and unknown outcomes.
If a check fails transiently, retry the check. If the environment is partially provisioned, follow a compensation or repair path rather than replaying the entire task.
Mark the task complete only after the source of truth confirms the requested environment state, then record the evidence and notify the customer.

The model can help interpret the request, summarize the configuration, choose a diagnostic step, or explain a failed health check. The durable runtime owns task identity, state transitions, approval binding, retry behavior, external references, and final verification.

If the browser closes after step 4, the task remains waiting. If the worker dies after step 6, the provider job reference prevents a second provisioning request. If the customer changes the configuration while the task is waiting, the runtime can require a new review rather than quietly applying the new version.

What the team needs to design and operate

Architecture

The system gains a task service or workflow boundary with durable state, not merely a queue consumer. The task record becomes the handoff point between clients, workers, tools, humans, and operators.

Separate task state from domain state. A task saying “provision requested” is not the same as an environment saying “provisioned.” Store proposals, attempts, provider references, approvals, and outcomes with enough linkage to reconcile them without treating every intermediate status as business truth.

Engineering

Every side-effecting step needs a retry and recovery contract. Document whether it is safe to retry, how the idempotency key is formed, how an ambiguous result is reconciled, and which compensation is available.

Test process death at each boundary: before dispatch, after dispatch, after the provider accepts work, before the response is recorded, during human input, and during outcome verification. Test deployment of a new workflow version while old tasks remain open.

Treat model calls as external, versioned, failure-prone work. Record enough input and output context to explain a decision, but make the replay policy explicit. A replay that calls a live model again is not the same as a replay that uses a recorded response.

Product and UX

The interface needs a task view, not only a spinner. It should show what is happening, what the system is waiting for, what the user can do, what can be cancelled, and when the result is verified.

Useful states include “waiting for approval,” “checking provider status,” “retrying a temporary failure,” “needs clarification,” and “outcome uncertain.” These are better than either a frozen loading indicator or a confident success message.

The user should be able to return from another device or session. A task handle preserves continuity without preserving every live connection.

Operations and governance

Operators need to find tasks by state, age, owner, workflow version, external reference, and last meaningful transition. They need to distinguish slow work from stuck work, repeated retries from progress, and cancellation requests from actual cessation.

Retention and privacy become lifecycle decisions. A task may need enough history to explain an action, but not every prompt or tool payload should be retained forever. Define what is authoritative, what is derived, what expires, and what must remain available for reconciliation.

Failure Modes

A job row mistaken for a task contract

The system stores status = running and a timestamp but cannot explain what the worker was doing, what input it used, or how to resume. Record explicit pending work, checkpoint state, versions, and external references.

Retrying a model-mediated side effect

A worker times out after sending a request and asks the model to produce the action again. The second proposal may duplicate the first side effect. Make execution idempotent and reconcile ambiguous outcomes before generating another action.

Stale approval after a long pause

A user approved one configuration, target, or amount, and the task later applies another. Bind approval to the exact task state, input version, scope, and expiration policy.

Cancellation reported as completion

The client sends a cancellation request and the interface immediately says the work stopped. Cancellation may be cooperative and may arrive after an external operation has started. Report requested, acknowledged, stopped, and reconciled states separately.

Worker recovery loses semantic context

The replacement worker has the task ID but not the relevant evidence, model route, policy version, or prior tool result. A durable handle without a durable context contract is only a pointer to missing information.

Workflow version drift

A task starts under one state machine and resumes under another whose states, tools, or retry behavior changed. Pin or migrate deliberately, and test open tasks during deployment.

Terminal state without verified outcome

The orchestrator reaches its final node because every step returned, while the external system remains pending or unhealthy. Require a source-of-truth check before declaring the business outcome complete.

A useful task contract records enough state for another worker, operator, or client to resume the work safely.

Reviewing the task before it runs in the background

Before a model-mediated task crosses its first asynchronous boundary, complete this task card:

Question	Record
What work does this task represent?	Intent, scope, owner, and stable task identity
What input and evidence started it?	Immutable request snapshot and provenance references
Which states can it enter?	State machine, terminal states, and legal transitions
What is the next pending action?	Worker, timer, external job, human, or reconciliation read
What can be retried safely?	Error classes, attempt limits, backoff, and idempotency keys
What happens after an ambiguous side effect?	Reconciliation query, deduplication, or compensation
Which context is frozen or refreshed?	Freshness, expiration, and re-approval rules
How does a person provide input?	Authenticated request, displayed scope, expiration, and audit record
What does cancellation mean?	Requested, acknowledged, stopped, and reconciled states
Which version governs open tasks?	Workflow, schema, model route, tool, and policy versions
What proves completion?	Source-of-truth checks and outcome evidence
How long is the task retained?	History, privacy, recovery, and deletion policy

The card turns “run it in the background” into a lifecycle another worker or operator can pick up. The label may change from agent task to job, run, or operation as protocols settle, and the storage underneath will change too. The provisioning task will still need to explain what was approved, what has been submitted, what is waiting, and how the next worker can verify the result without starting the work twice.

Sources

MCP Tasks Extension overview: describes durable task handles, polling, input-required states, cancellation, task storage, and recovery across interrupted connections.
MCP Tasks specification: defines task statuses, durable creation, polling, updates, cancellation semantics, and terminal results.
A2A Protocol specification: defines asynchronous task operations, task identifiers, status updates, artifacts, idempotency, versioning, and authentication boundaries for agent-to-agent work.
Temporal Platform Documentation: documents durable workflow execution, persisted state, timers, signals, retries, worker recovery, and long-running workflows.
Temporal Workflow Execution overview: explains durable workflow execution, open and closed states, workflow history, retries, and continuation boundaries.
AWS Step Functions error handling: documents explicit retry and catch policies and the distinction between runtime errors, timeouts, and fallback states.