An agent keeps working after its owner closes the laptop. By morning, it has read eleven files, updated a forecast, and paused on a missing approval. The impressive part is persistence. The product problem is the next five minutes.
Microsoft recently described Autopilot as a persistent, proactive agent that can continue while a user is offline. That shift turns an AI interaction into an operating process. A chat can end. A process accumulates state, cost, unfinished work, and consequences.
The useful design model is a shift handoff.
Persistence creates a second user
The person who starts a task is not always the person who returns to it. A manager might launch an analysis Friday afternoon. An analyst may inherit it Monday morning. Compliance could inspect it a month later.
Each person needs a different view of the same run. The starter wants progress. The next operator needs the current state and a clear decision. The reviewer needs evidence.
Many agent products still treat all three as transcript readers. That is lazy product design. A transcript records conversation, but it does not explain which actions completed, what changed outside the chat, or why the agent stopped.
Give every run a work card
An always-on agent needs an object that survives the conversation. Call it a run, case, job, or work card. The label matters less than the contract.
At minimum, the card should show the original goal, current status, actions already taken, artifacts changed, approvals requested, money consumed, and the next safe action. It should also name a human owner. Assigning responsibility to the agent is not ownership.
This is where product teams can borrow from operations instead of inventing another glowing chat pane. A good handoff compresses activity into facts that another person can verify. It does not ask them to reconstruct intent from 300 messages.
The same principle appears in operational metrics: a signal becomes useful when it has an owner and an action. Persistent AI extends that rule from a dashboard alert to an unfinished piece of work.
Design the pause before the run
Products often lavish attention on how an agent starts and barely design how it pauses. Yet long-running work will pause constantly. A credential expires. A source conflicts with another source. A spending limit arrives. An approval does not.
The pause state should be specific enough to route. A generic needs-attention notice is a notification, not a handoff. A request for the finance owner to approve a $420 data purchase by Tuesday can enter a queue, reach the right person, and expire cleanly.
Every pause also needs a safe shelf life. After that point, the system should recheck assumptions or close the run. Resuming stale work as though nothing changed is a quiet way to ship yesterday’s context into today’s decision.
Make cost part of the handoff
Microsoft places long-running agent work under usage-based billing and gives administrators tools to monitor spend. That makes cost an active product state, not a receipt delivered later.
A person taking over should see what the run has cost, what the next step is likely to cost, and which outcome justifies continuing. This is especially important when an agent can explore indefinitely. A budget without a stop condition is merely a slower surprise.
The morning test
There is a plain test for the feature: can someone who did not start the run open it the next morning and make a sound decision in two minutes?
If the answer depends on reading the full transcript, the agent is persistent but the product is not operational. Build the handoff, and persistence becomes dependable work instead of unattended activity.
Comments
Comments are powered by GitHub Discussions through Giscus.