Durability and compute

AgentRun keeps execution state separate from the machine running an agent's tools. You choose an available compute provider; the platform manages run history, workspace access, and recovery through the same API.

What survives an interruption

AgentRun persists the agent revision, conversation or workflow state, recorded results, and run files in its data directory. When the server restarts, it checks unfinished runs: it reconnects to a surviving run process or resumes from the saved store when the process has gone.

This avoids rebuilding recovery independently around each harness. It depends on keeping the server's data directory on persistent storage.

Event	Behavior
Browser closed or page reloaded	The server continues the run; reopen it in the console.
Server process restarts with its data intact	It recovers unfinished runs from their saved state.
Agent waits for a person	It remains waiting until an answer arrives.
Turn stopped by the user	A follow-up starts a new turn on the existing conversation.
Run cancelled	It is finished; start a new run to continue the task.
Data directory deleted	There is no saved state to recover.

Recovery does not guarantee exactly-once actions in an external system. For payments, messages, or other writes, use the destination's idempotency mechanism: a call interrupted before its result is recorded may need retrying.

Select where tools run

The harness's reasoning loop runs under AgentRun. A place on the agent definition selects where its shell and file tools work.

{
  "definition": {
    "id": "file-worker",
    "name": "File worker",
    "instructions": "Inspect the provided files and write a concise report.",
    "harness": "pi",
    "place": { "mode": "sandbox", "box": "docker" },
    "tools": ["bash", "read", "write", "edit"]
  }
}

A runner place has no shell. A sandbox place uses a configured box. The place belongs to the agent revision; the run API and result format stay the same when you change providers.

Configure a provider once

Current repository source integrates run execution with Docker, Daytona, and Modal:

Provider	Server setup	Operational detail
Docker	Docker CLI and an accessible running daemon. Enabled by default when available.	The first default image build can take a few minutes.
Daytona	DAYTONA_API_KEY and daytona in AGENTRUN_BOXES.	AgentRun creates the box and synchronizes the workspace.
Modal	MODAL_TOKEN_ID, MODAL_TOKEN_SECRET, the Modal SDK, and modal in AGENTRUN_BOXES.	Current source blocks the box's network because it cannot verify the provider's domain allowlist.

For example, AGENTRUN_BOXES=docker,daytona enables those providers when starting the server. Save credentials through your deployment's secret mechanism and restart after changing provider configuration. AgentRun probes configured providers at startup; GET /v2/capabilities reports availability and the reason a box cannot run.

The abstraction covers lifecycle and tool access; provider limits, networking, persistence, and billing still differ. A provider that the lower-level computer library supports is not necessarily an executable box in AgentRun Server. Follow the server's Boxes and provider-specific sections.

Published launcher and source-only changes

For a first installation, run the published local launcher on the host. Docker can provide its agents' compute without putting the server itself in a container.

The current repository also adds container-to-Docker wiring and a newer on-disk layout. Those changes are newer than the server bundled with launcher 0.4. Do not combine a newer Compose configuration with an older published image and assume their compute behavior matches. Check the image's release and the server's capabilities first.

See A run's life for recovery details and Back up and move your server before upgrading or moving persistent data.