Skip to main content
Run agents, teams, and workflows in the background by passing background=True to .arun(). Execution continues even if the client disconnects. The behavior depends on whether you also set stream=True.

Execution Modes

Background execution requires a database (db) on the agent, team, or workflow for persisting run state.

Fire-and-Forget

Start a background run and poll for the result. Works identically for agents, teams, and workflows.

Resumable Streaming (SSE)

Combine background=True with stream=True for resumable SSE streaming. The run executes in a detached asyncio.Task that survives client disconnects. Events are buffered with sequential event_index values so clients can reconnect and replay retained events. Each AgentOS process retains the latest 10,000 events per run. Reconnect before the events you need are trimmed. A client that falls behind the retained window receives the remaining buffered events, but cannot recover the trimmed events from that in-memory buffer.

How It Works

  1. The run persists RUNNING status in the database
  2. A detached asyncio.Task executes and publishes events to an in-memory buffer
  3. The client receives SSE events, each containing an event_index and run_id
  4. On disconnect, the client records last_event_index
  5. On reconnect, the client calls /resume with last_event_index to replay retained events after that index

Starting a Resumable Stream

Resumable streaming requires a running AgentOS server. Pass background=true and stream=true in the request. The pattern is the same for agents, teams, and workflows. Only the URL path differs.
Workflows also support WebSocket-based reconnection. See the WebSocket reconnect example.
Each SSE event includes:
  • event_index: Sequential integer for ordering and resumption
  • run_id: The run identifier for reconnection
  • session_id: The session identifier

Reconnecting via /resume

On disconnect (page refresh, network loss), reconnect to /resume with the last event_index:

Resume Endpoints

The resume endpoint follows the same pattern for agents, teams, and workflows:
Resume behavior depends on run state: If a run is absent from the buffer and session_id is missing, /resume returns an error. Completed, errored, and cancelled buffers become eligible for cleanup 30 minutes after finalization. An opportunistic cleanup check evicts eligible buffers when another run status is finalized, so eviction can occur later than 30 minutes.

Meta Events

The /resume stream can include these meta events:

Multi-Container Deployments

The detached task and event buffer live in-process on the instance that started the run. The default cancellation manager is also in-memory. In a multi-replica setup, a /resume request that lands on a different instance can replay persisted events for a local entity when session_id is provided, then closes. It cannot tail the live task on the originating instance. A /cancel request on the wrong instance does not stop the task on the origin. Configure session affinity on the initial run-start request, then route that client’s /resume and /cancel requests to the same instance. An explicit run_id-to-instance mapping can provide the same guarantee. Hashing only the generated run_id on reconnect is insufficient because the initial request was routed before that ID existed. A shared cancellation manager such as RedisRunCancellationManager removes the affinity requirement for /cancel, but live /resume still needs the originating instance.

Developer Resources