Your AI task stopped halfway through. What happens next?

A researcher returns to an assistant that was preparing a comparison for review. Two documents were collected and the comparison was calculated, but the task stopped while saving the packet. Should they retry, search for the saved result, or start again?

In this fictional example, the receiving service created the packet before the worker crashed. The worker never recorded the acknowledgment. When execution resumes, it knows the attempt was interrupted but cannot yet establish whether the packet exists.

A simple retry loop can now create duplicate work or misreport a completed action as a failure. The next step depends on the identity of the logical operation, the receiving service's contract, and the evidence available to reconcile the outcome.

The researcher needs a useful next step and a dependable account of what was retained. Delivering that experience requires durable state, bounded resources, recovery behavior, and a distinction between completing an operation and producing a well-supported answer. These are the engineering decisions behind a task someone can leave and resume.

Define the commitment before executing the plan

A research request should identify the question the system is trying to answer and the conditions under which an answer would be useful. Those conditions may include source coverage, freshness, relevant scope, and the intended next step for the user.

Execution needs its own boundaries: which providers can be called, which actions can change state, how much work may be spent, and when human review is required. The request can also identify what an acceptable incomplete result should contain.

These commitments make completion evaluable. A process can successfully fetch a document while the document fails to answer the question. It can complete every planned tool call and still lack a critical source. Conversely, it can produce a useful partial answer that clearly identifies the remaining uncertainty.

A single green status called completed collapses those distinctions. The system needs a vocabulary for both execution and evidence sufficiency.

Persist state that supports an actual next action

Useful states follow the operating workflow. A task may be queued, running, waiting for a source, waiting for a reviewer, finished with recorded operation outcomes, incomplete in its evidence, or failed in a way that requires intervention.

The names matter less than their meaning. Each state should identify who or what acts next, which evidence is retained, and which transitions are permitted.

A waiting state should not be indistinguishable from an abandoned process. If a source is unavailable, the task can retain the source request, the reason for waiting, and the next permitted action. If a reviewer is needed, it can retain the specific packet and decision being requested.

Recovery should use those records rather than infer progress from conversational memory. The operational owner needs to know what happened even when the original worker, model session, or person is unavailable.

Separate a logical operation from its attempts

A collection step can have several execution attempts while remaining one intended operation. A genuinely new request may look identical at the parameter level while expressing different intent.

That difference deserves a stable identifier. An attempt log can record timestamps, outcomes, and failure details without replacing the identity of the operation being retried.

Parameters matter too. Reusing an operation identifier with a materially different request can hide a changed intent. A compatible receiving contract should define how it handles that case.

Amazon's engineering account recommends caller-provided request identifiers and discusses parameter mismatch, late requests, and the lifetime of idempotency records. Making retries safe with idempotent APIs describes a service-side contract, rather than a guarantee created by the caller naming a key.

Recover the ambiguous outcome at the receiving boundary

Return to the packet-writing example. The worker submits operation K. The receiver records K and creates the packet. The acknowledgment is lost before the worker records completion.

If the receiver supports an appropriate idempotency contract, a repeated request with the same key and semantic parameters can recover a compatible result without creating another packet. The receiver must enforce the contract and define its retention and error behavior.

Some providers do not offer that contract. The integration may instead need a reliable status query, a unique external reference that can be searched, a narrowly defined reconciliation process, or a human investigation path. The correct choice depends on the action and the receiver.

The system should preserve unknown when it cannot establish the outcome. Treating a timeout as proof that nothing happened can be just as harmful as treating it as success.

Cancellation has a related boundary. A request to stop future work cannot undo an effect that already committed. The task should distinguish stopping additional attempts from reversing a completed action, which may require its own authorized operation.

Durable replay has constraints of its own

A durable workflow runtime can retain progress and recover after failures. Its replay semantics still need to be understood by the application using it.

Temporal documents that activity execution can be retried when completion was not recorded, including a worker crash after an external effect. Its guidance therefore calls for idempotent activities. Temporal activity semantics are a concrete example of why durable execution does not eliminate receiver-side recovery work.

Its workflow model also requires deterministic command behavior for replay. External calls and AI invocations belong in activities outside that deterministic replay path, with results recorded in history. Temporal workflow-definition guidance makes the distinction explicit.

For an AI research feature, that means preserving the result of a completed generation or tool action instead of expecting a new model invocation to reproduce the same reasoning. A new invocation can be useful work, but it is another operation with its own inputs, version context, and outcome.

Code changes also need a compatibility plan. A workflow that waits for a reviewer can outlive a deployment. The runtime and application must agree on how that in-flight work continues under changed code or configuration.

Bound work across the complete execution

A retry limit on one HTTP client does not necessarily bound a research job. The client may sit inside an activity that is retried by a runtime, which sits inside a planner that starts another attempt after receiving an incomplete answer.

Budgets need a scope. A task can track elapsed time, provider calls, bytes retained, model usage, or another meaningful resource. The relevant accounting should survive restarts and follow the logical request across nested work.

Timeout, deadline, attempt limit, and budget serve different purposes. A timeout bounds one wait. A deadline limits when work remains useful. An attempt limit constrains repeated execution under a particular policy. A budget constrains the total resource commitment.

Retries can also worsen an overloaded dependency. Backoff spaces attempts; jitter helps avoid synchronized bursts. Amazon's discussion of timeouts, retries, and jitter explains these distinct mechanisms and the risk of side effects despite a timeout.

Configuration should follow the workload and provider contract. A copied retry count or latency percentile from an unrelated system is a poor substitute for observing the dependency and defining the task's acceptable failure behavior.

Evaluate execution and research separately

Operational evaluation should ask whether work can be resumed, reconciled, stopped, and investigated. Research evaluation should ask whether the retained evidence supports a relevant answer under the stated scope.

The two can disagree. A technically healthy job can return stale evidence. A source-retrieval failure can leave a useful answer with a clearly described gap. A packet can be stored successfully while containing an unsupported interpretation.

A review interface can preserve both accounts. It can show which operations completed, which sources were unavailable, the evidence used by the answer, and what remains unresolved. The user can then choose whether more research is worth the additional cost.

This is also how the system learns useful operational lessons. A rising failure rate at one provider differs from a rising rate of unsupported answers. Combining them into one generic quality number makes the next engineering decision harder.

Operational measures should preserve that distinction. Queue age shows a different problem from attempts per logical operation. Time waiting for a reviewer differs from time spent retrying a provider. An unresolved external effect needs investigation even when the worker process itself is healthy. Source coverage and answer support belong alongside those measures, with their own definitions.

These measures are useful when they lead to an action an operator can take. A dashboard full of aggregate request counts may show activity while leaving a stalled question invisible. The task view should let someone move from an abnormal measure to the specific logical work, retained evidence, and next permitted step.

Demonstrate recovery before expanding autonomy

A first delivery slice can support one question family, a small provider set, and one review-packet destination. Retain the request's scope, logical operation identities, attempt history, source artifacts, and evaluation of answer sufficiency.

Then demonstrate the awkward paths: restart after partial collection, a delayed provider, a model call whose response was not retained, a lost acknowledgment after a write, a reviewer wait that spans a deployment, and cancellation after an effect has already committed.

For each path, inspect what the user and operational owner can determine. They should be able to tell what work happened, what remains uncertain, whether repeating an action is justified, and how to continue.

That is a meaningful foundation for a research agent. It lets the system carry useful work through interruptions while keeping its resource commitment and evidential limits understandable.