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)
Combinebackground=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
- The run persists
RUNNINGstatus in the database - A detached
asyncio.Taskexecutes and publishes events to an in-memory buffer - The client receives SSE events, each containing an
event_indexandrun_id - On disconnect, the client records
last_event_index - On reconnect, the client calls
/resumewithlast_event_indexto replay retained events after that index
Starting a Resumable Stream
Resumable streaming requires a running AgentOS server. Passbackground=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.
event_index: Sequential integer for ordering and resumptionrun_id: The run identifier for reconnectionsession_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:
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.