An agent that works for hours needs more than a place to run. It needs a durable record of progress, bounded access to tools, and a way to stop without leaving the business uncertain about what happened.
The work outlives the conversation
Consider a fictional manufacturing company facing a delayed delivery. A purchasing manager asks an AI agent to investigate alternative suppliers, compare delivery dates, and prepare a recommendation for the following morning. The manager closes the laptop. The assignment continues.
That small change in the user experience creates a much larger operational obligation. Somewhere, a system must retain the assignment, run the investigation, wait for information, and explain the result when the manager returns. If a worker crashes overnight, the company still expects the task to have a clear status.
Google’s October 8 Gemini at Work announcement describes persistent cloud execution and coordination between agents over hours or days. It presents a useful direction for enterprise software, but an announcement is not evidence that a particular workload will meet its reliability or cost requirements.
The practical question is what the organization needs beneath that experience. Article 1 examined the boundary between an agent’s recommendation and permission to act. Here, the focus is what keeps the assignment manageable as it moves between machines, waits for approvals, and consumes resources.
The lifetime of the business task should not depend on the lifetime of the process currently working on it.
A running process is not a durable task
The supplier investigation begins by gathering delivery estimates. After an hour, the worker running it fails. Starting a replacement worker restores computing capacity. It does not, by itself, tell that worker which suppliers were checked, which results were saved, or which action was already requested.
For this scenario, the application should maintain a durable task record outside the worker. That record needs a stable identity, the original objective, the current phase, references to saved results, and an explicit status. The worker becomes one participant in the task rather than the only place where the task exists.
This distinction also separates continuing after a browser disconnects from recovering after a process failure. Microsoft’s long-running hosted-agent documentation distinguishes background execution from resilience. Its documented recovery mechanism can reenter a handler after process loss, while the application remains responsible for preserving meaningful progress. The described hosted-agent capabilities are in preview, which matters when assessing their suitability for production.
Suppose the investigation has completed its approved-supplier search and is waiting for a manager to permit a wider search. A useful checkpoint would preserve that boundary and the evidence behind it. Saving only the conversation transcript would leave the recovering application to infer whether the approval was requested, received, or still pending.
Durable workflow systems offer another mechanism. Temporal’s workflow documentation describes recovery using recorded event history and replay. That is a specific execution model, with constraints on workflow code. It should not be assumed to describe every agent runtime or to make arbitrary model calls reproducible.
The design decision is therefore concrete: determine which component owns progress, how it records completed steps, and how a replacement worker finds the next safe boundary. Buying a service described as persistent does not answer those questions for the entire application.
Separate waiting from working
The agent finds two possible suppliers, but one requires an engineering review. The task may now wait until morning. Keeping a worker actively running throughout that wait would make the waiting period part of its computing cost without necessarily advancing the investigation.
A sensible design for this assignment separates the stored task from the resources used to advance it. A durable event or scheduled check can make the task eligible to resume when the review arrives. A worker then loads the relevant state and continues. The interface should show that the task is waiting for engineering, rather than presenting a vague indication that it is still thinking.
There are exceptions. A browser session, a loaded local model, or a specialist tool may be expensive to recreate. Retaining that environment can be worthwhile. The decision should follow measured setup cost and workload needs rather than an assumption that every agent requires a permanently running machine.
The same discipline applies to parallel work. Checking several independent suppliers at once may reduce elapsed time, but additional workers also create more simultaneous requests to downstream systems. If the supplier API is already the bottleneck, increasing worker count can simply increase contention.
For the purchasing task, I would set concurrency limits at both the task and shared-service levels. A supplier investigation should not be able to consume all available capacity merely because it discovers more branches to explore. Urgent work needs a place in the queue, and lower-priority work needs a clear policy for delay.
This is an infrastructure choice with a business consequence. More capacity can improve responsiveness, but capacity without admission rules makes it harder to predict whose work will finish on time.
Give the task a budget and a stopping rule
The agent has compared the suppliers, but the evidence is imperfect. It decides to search again, asks another agent to review the alternatives, and repeats a document analysis. Each step may sound defensible in isolation. Together, they can become an investigation that never reaches a decision.
For this workload, a budget should cover more than model tokens. The task may use tool calls, temporary computing environments, storage, and human review. Teams should measure those costs together before claiming that a cheaper model makes the overall process cheaper.
Google’s announcement describes model routing and project spend caps that pause agent work when a cap is reached. Those are vendor-described controls, not an independent measurement of savings for this purchasing workflow. A project cap also leaves an application-level question: what should happen to this particular assignment when it cannot continue?
I would give the task limits for elapsed time, repeated attempts, delegated work, and spending, with an explicit escalation path. When the remaining budget cannot support another useful search, the agent should return the evidence it has, identify what remains unresolved, and request a decision.
A pause also needs a durable status. If an external request is still underway, the interface should say so. Cancellation should prevent further eligible work while the application determines the outcome of operations already in flight. It should not erase the record needed to explain them.
The uncomfortable trade-off is that a bounded agent may stop before producing the desired answer. That can be the correct outcome. An organization needs to know when automation has reached the limit of its evidence or resources, rather than paying for continued activity that looks like progress.
Operate the assignment, not just the machines
The next morning, every server dashboard might be green while the supplier task is still stuck. Infrastructure availability tells the operations team that components are reachable. It does not tell the purchasing manager whether the assignment is progressing, waiting for approval, or unable to continue.
For this scenario, I would track the task’s last meaningful progress, waiting reason, attempts, spending, and external-operation references. Technical logs should connect to the same task identity so an operator can move from the manager’s question to the relevant evidence. Access to those records should reflect the sensitivity of supplier and contract information.
Before relying on the system, test interruptions at meaningful boundaries. Disconnect the client. Stop a worker after a result is saved. Delay an approval. Exhaust a task budget. Cancel while a tool request is outstanding. Each test should produce an understandable task state and a defined recovery or escalation path.
That does not mean every application needs a dedicated agent platform. A short, repeatable document search may be adequately served by a conventional job queue and database. A purchasing investigation spanning approvals and external operations may justify richer orchestration. The extra machinery carries its own maintenance cost, so complexity should follow the consequences of failure.
The opportunity is to let work continue beyond a conversation without making its progress invisible or its resource use open-ended. Reliable agent infrastructure lets an organization account for an assignment even when the worker running it has disappeared.
Go deeper
Each source was opened and checked on 9 October 2026. Product behavior and availability can change, so recheck them before relying on them.
- Google Cloud: Gemini at Work 2026. Published October 8, 2026. Vendor announcement describing persistent execution, delegation, and cost controls. It is not an independent reliability evaluation.
- Microsoft: Resilience for Long-Running Hosted Agents. Explains the boundary between runtime recovery and application-owned progress. The documented capabilities are preview.
- Temporal: Workflow Execution Overview. Explains event history and replay in Temporal’s durable execution model.