An AI agent has reviewed half a product catalog, identified several inconsistencies and prepared a set of proposed corrections. Then its session ends.
When it returns, what exactly does “carry on” mean?
For a short conversation, the answer may be sitting a few messages above. For work spanning many sessions, a business needs a more dependable record of what has happened, what remains and which decisions were approved. Otherwise, resuming the task becomes a small archaeological expedition, conducted by someone who may be very confident about the wrong century.
Anthropic’s November 2025 work on long-running agents examines this problem in software development. Its experiments show why a surrounding harness, including explicit progress records and checks, matters alongside the model. The wider business lesson is useful: continuing work requires a reliable place to continue from.
When a fixed workflow is the better starting point
Some tasks already have a clear sequence. Receive a file, validate its format, extract specified information and place uncertain records into a review queue.
A conventional workflow can manage those steps, with an AI component handling a bounded judgment where needed. Its progress can live in ordinary application records. That makes the process easier to inspect and resume.
This is a sensible choice when the route through the task is mostly known. Giving an agent freedom to invent the route may add uncertainty without adding much value.
In the catalog example, checking whether every product has a required identifier is a defined validation task. Asking an agent to improvise that check each session would be a curious use of everyone’s attention.
When the work needs exploration
Other tasks involve discovering what to do next. An agent might investigate inconsistent product specifications across several source documents and propose which information needs clarification.
That activity can benefit from flexible tool use. It also needs stronger boundaries around progress.
We build AI agents with clear jobs and sensible limits. See how.
Give the task a record outside the chat
A useful task record identifies the product, source material reviewed, proposed change, supporting evidence and current approval state. It distinguishes “investigated” from “approved” and “applied.”
Those distinctions affect the next action. A proposal waiting for a person should not quietly become an instruction when the session restarts.
Keep the record accessible to the surrounding application and its human operators. A readable summary helps the agent orient itself, while structured status fields let the application enforce important rules.
Resume by checking what is true now
An interruption can happen after a change reaches an external system but before the agent records success. Blindly repeating the last action could then create a duplicate or overwrite a newer correction.
The next session should inspect the relevant system and reconcile it with the task record. Stable identifiers and operations designed to tolerate retries help make that practical.
For the catalog review, the agent should check whether an approved change has already been applied and whether the product has changed since approval. If the current information conflicts with the recorded plan, that item needs a fresh decision.
It is the same courtesy you would appreciate from a colleague returning to shared work: have a look before moving the furniture again.
Check out this blog: Does this workflow need an AI agent, or a decent set of rules?
Define completion before the agent gets enthusiastic
A broad instruction such as “clean up the catalog” leaves too much room for interpretation. Agree which records are in scope, what counts as a valid correction and how unresolved items should be reported.
Completion then becomes an assessment against those conditions. A finished summary should connect to inspected records and verified changes, with outstanding questions visible. A confident paragraph is pleasant company, but it cannot establish whether the final hundred products were reviewed.
Zulu Shack recommends trying recovery deliberately before assigning important long-running work. Pause a representative task partway through, restart with a fresh session and observe what the agent checks. Include a case where an action succeeded immediately before the interruption.
That exercise reveals whether the system can continue responsibly or merely continue talking.
A long-running agent should be able to leave work in an understandable state. When the next session begins, both the software and the person supervising it should know where things stand. That is a rather better starting point than “I think we were nearly done.”