Ask what survives when an agent worker stops

An agent that remembers the conversation still needs a way to recover unfinished work. A saved transcript can explain what the agent intended. Recovery needs to establish which actions happened and what remains safe to do.

That distinction matters when choosing infrastructure for tasks that outlive a browser tab or worker process. A useful product demonstration includes an interruption in the middle of a task and an inspection of the recovered state.

Conversation history answers only part of the question

Consider a weekly report workflow. It reads a dataset, creates a document, and waits for someone to authorize distribution. The worker stops after document creation but before recording the returned identifier.

A replacement worker can see the plan in the transcript. It still needs to locate the document, determine whether its contents are complete, and retain the requirement to wait before distribution. Starting the plan again could leave duplicate documents. Assuming the previous attempt finished could hide an incomplete one.

For this example, the recovery design should identify the operation, the existing artifact, the last verified stage, and the next permitted action. These are proposed application requirements, not features every agent platform supplies.

Durable execution has a specific meaning

Temporal documents workflow recovery through replay against recorded event history. That offers a concrete example of execution state that survives a worker interruption. It is different from asking a model to reconstruct progress from a conversation.

This requires an implementation designed for replay. Temporal's workflow definition guidance requires deterministic workflow code; external operations such as API or model calls belong in Activities. Saving an arbitrary agent loop does not give it those recovery semantics. Retried Activities still need an appropriate strategy for external side effects.

A durable workflow engine is still only part of the application. You need to understand how the implementation handles external actions, retries, and an uncertain result. A system that resumes reliably can still resume the wrong business procedure if the procedure is poorly specified.

Ask the product team to explain its recovery boundary. Which state lives in the worker? Which state is persisted elsewhere? How does the application find an external artifact when its response was lost? What happens to a pending approval?

Interrupt a disposable job

Design a trial with a sandbox destination and no real distribution step. Stop the worker at three points: before document creation, after creation but before acknowledgement, and while waiting for approval.

For each interruption, inspect the destination independently of the agent's final message. Count the documents. Compare their contents. Check the recovered job status and its next action.

Write down what would constitute a failure before the trial. In this example, duplicate creation, missing content, or distribution without the required approval would each fail acceptance. A clear blocker that preserves the artifact can be a useful outcome when automatic recovery is not possible.

The exact stopping mechanism depends on the product. Request a supported test method rather than terminating unrelated services in a shared environment.

Buy recovery behavior you can explain

A short interactive task may not justify a durable workflow system. A process that waits for people, spans services, or produces expensive external effects deserves closer scrutiny.

Compare products by the work required after an interruption: manual reconstruction, duplicate cleanup, lost context, and uncertainty about external actions. Ask for evidence from your trial, and keep vendor claims separate from what you observed.

Use Agent framework vs agent library to identify who owns the execution loop. Then ask that owner to demonstrate recovery.