An AI assignment is not ready for routine use if a person has to reconstruct it every time the system stops. Before expanding an agent’s responsibilities, test the restart: can it find the current work, distinguish completed steps from proposed ones, and continue without repeating an action? That is part of delivering the job, not maintenance to deal with later.
A research paper submitted October 26, Work Agents: Systems, Capabilities, and Optimization, offers a useful frame. It treats agents as systems working in persistent workspaces toward verifiable outcomes. One of its two dimensions for describing working conditions is “work persistence.” For a business leader, the immediate question is ordinary: what happens to the assignment between working sessions?
In brief
Evaluate the handover as well as the finished output. Interrupt a safe trial, restart it, and inspect what the agent knows about the unfinished job. It should recover from an accessible work record, not from a colleague’s recollection of yesterday’s conversation. Keep permission for consequential actions separate from permission to resume preparation.
The work lasts longer than the conversation
Consider a hypothetical supplier review. An operations manager asks an agent to compare renewal terms across a set of contracts and prepare a recommendation. Some documents are available immediately. Others arrive later. A supplier corrects a price, and finance needs time to confirm an invoice.
The assignment now spans several days, regardless of how quickly the assistant can read a document.
If the first session produces a polished summary but leaves no reliable account of what was checked, the next session starts with a problem. Was that price confirmed or merely quoted? Did someone review the amendment? Was the supplier contacted, or did the agent only prepare a message?
A conversation history may contain all those details. That does not make it a usable work record. Someone still has to separate an early assumption from a later correction and decide which version to trust.
An agent’s ability to continue working depends on the state it can recover, not the confidence of its last update.
The new paper’s framework combines the AI, the software that manages its work, a workspace that retains state, and outcomes people can verify. It classifies digital work into five forms. This is a research framework, not evidence that a particular product can manage your supplier renewals. Its usefulness is in changing what you ask to see.
A progress summary needs evidence behind it
There is an earlier, concrete example of this problem in Anthropic’s November 2025 engineering account of long-running agents.
The team describes coding agents leaving work half-finished and undocumented, forcing later sessions to guess what had happened. Other sessions saw some completed work and declared the entire project done. Their response included a progress file, a history of changes, and explicit requirements that subsequent sessions could inspect.
In one application-building example, the initial requirements covered more than 200 features. Those features started as failing rather than being assumed complete. That number describes the scope of a coding experiment, not a success rate or a business productivity gain.
The relevant lesson for the supplier review is narrower. “Reviewed contracts” is too vague to support a restart. A useful record identifies the contracts examined, the versions used, the unresolved conflicts, and where the draft comparison lives. It distinguishes a recommendation from an approved decision.
Anthropic’s account concerns software development. Applying the pattern to supplier work is an operating proposal, not a result established by that experiment. But it is a proposal you can test without giving an agent authority to negotiate or spend.
Try a restart before adding responsibility
Use sanitized contracts in a test environment. Give the agent a bounded comparison assignment and a designated place to retain its working record. Keep external messages and purchasing changes out of scope.
After it completes part of the comparison, stop at a normal session boundary. Start a fresh session through the product’s supported restart process. Ask it to identify what is complete, show the evidence, and propose its next step.
Do not rescue it immediately by pasting yesterday’s explanation back in. That would test your ability to brief the system, not its ability to recover the assignment.
Watch for a specific mistake: treating a proposed action as something already done. Then check the opposite. Can it recognize an action that really was completed, so it does not repeat it? A duplicated comparison wastes time. A duplicated order creates a different kind of problem.
Have the manager inspect the recovered record against the test materials. Count the rebriefing time, repeated work, and incorrect status claims. Record any uncertainty the agent correctly surfaces. A pause to ask whether a price was approved is preferable to an invented approval.
There is no universal passing score here. Set the standard around the job’s consequences before running the trial. Preparation that remains under human review can tolerate different failures from a system permitted to change purchasing records.
Put recovery in the assignment
The operating instruction should say where unfinished work belongs and what a later session must verify before proceeding. Give someone responsibility for correcting that record when the business changes its mind. Otherwise, an agent may faithfully resume a decision that is no longer current.
This belongs in the move from AI pilot to production. A successful first run shows that the system can attempt the task. A successful restart shows that the organization has somewhere to keep the work.
Do not expand an assignment while its continuity still depends on one person remembering what happened last night.
Research and draft: Mai. Editorial direction: John Lipe.