An agent is repairing a project: downloading dependencies, starting a service, opening a browser, and running checks. When you close the chat window, the download may still be running, the service still holds its port, and the browser contains a half-completed form. The conversation has disappeared, but the work has not. Let a model act, and we inherit responsibility for what its actions leave in the world.
Set the model’s intelligence aside for a moment. We have a task with an uncertain duration. It waits for external results, holds files, processes, and network connections, and decides its next action along the way. Many paths through an ordinary program are written into its code beforehand; an agent combines tools during execution. These properties alone explain why it needs substantial runtime support.
A task outlives a request
A chat request can end while its task needs an identity and lifecycle of its own. The system accepts the work and gives it an identifier that can be queried later. Execution continues after the interface disconnects, and progress remains available when the user returns. While a download is running, the model need not keep guessing whether it has finished. Recording what the task is waiting for and resuming it when the result arrives puts waiting in the scheduler.
Other events arrive during the wait: the user adds a requirement, another tool returns, or the plan is cancelled. These events need a shared task record and suitable boundaries for reaching the model, so two workers do not edit the same file under different versions of the goal. Cancellation must also reach resources: stop dispatching actions, terminate processes where possible, and release temporary environments. A “stopped” label on a page does not shut down a background service.
The longer a task runs, the less resource cleanup can depend on voluntary completion. A repair loop may repeatedly start services; a stuck command may hold a machine indefinitely. Each task therefore needs time, concurrency, and resource budgets, with temporary resources traceable to their owner. Cleanup after a timeout and retention after success belong to the same lifecycle. The model judges whether the next step is useful; the system keeps the attempt affordable and stoppable.
Freedom to combine actions needs a bounded world
A shell can run programs, read paths, and contact websites in too many combinations to list exhaustively. A more workable approach is to decide which resources a task may reach, then keep its combinations within that scope. The sandbox becomes its workplace: filesystem boundaries constrain what it can change, network boundaries constrain where it can connect, and permissions identify actions requiring additional authorization. Anthropic’s sandbox design applies both filesystem and network controls to enforce such boundaries during execution.
The same repair task below encounters three disruptions. As you switch, compare what the system knows with what has already happened in the outside world. The gap determines whether to resume, clean up, or investigate first. Runtime facilities arise from these gaps.
The interface has disconnected; the task is waiting for a check.
The service and remote check can still be running.
A durable task identifier, background execution, and a way to reconnect to its status.
The user has withdrawn the task; new actions must stop.
Started processes still hold ports and resources until they stop.
Cancellation propagation, process ownership, and cleanup of temporary resources.
The request was sent, but no result arrived. Its outcome is unknown.
The remote job may already exist. Sending again could create another one.
A queryable request record or an idempotency identifier recognized by the remote service.
Recovery restores work, including its environment
A summary saying “configuration edited; run checks next” is insufficient on its own. The configuration must exist, dependency versions must match, and the system must determine whether the earlier service is still running. A useful checkpoint connects the model’s continuation context with file versions, tool execution records, and environment state. The environment may be retained or reconstructed from records. On resumption, the world the model encounters needs to agree with those records.
A missing result is harder still: it does not mean the action never happened. Suppose the model submits a remote test job. The job is created, but the response is lost. Retrying blindly may create a second job. The system needs a way to query the earlier request or attach a stable identifier that the recipient recognizes on resubmission. Idempotent APIs establish that contract: repeating a request does not perform the same operation twice. The model can learn when to retry; the party executing the action must still implement the contract.
This also explains the need to record tool inputs, results, timing, and actual artifacts. A final message saying “the check failed” reveals little about whether the code was wrong, a dependency was missing, or the check never started. Connecting the context at the time with environmental evidence locates the failure. These records support recovery and debugging, and help later training distinguish a poor model decision from a failure in its working conditions.
As a model becomes more independent on long tasks, the responsibilities around execution become more concrete. It decides how to work; the system ensures that work can continue, stop, and be investigated. Treating an agent as an ongoing task that acts, holds resources, and may be interrupted gives these engineering requirements a clear origin.