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 | stream | Behavior |
|---|
False | True | Default streaming. Runs inline. Client disconnect cancels the run. |
False | False | Non-streaming. Returns full response. |
True | False | Fire-and-forget. Returns PENDING immediately. Poll for results. |
True | True | Resumable streaming. Runs in a detached task. Events are buffered. Reconnect via /resume. |
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 without losing events.
How It Works
- The run persists
RUNNING status in the database
- A detached
asyncio.Task executes and publishes events to an in-memory buffer
- The client receives SSE events, each containing an
event_index and run_id
- On disconnect, the client records
last_event_index
- On reconnect, the client calls
/resume with last_event_index to catch up on missed events
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.
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:
| Scenario | Condition | Behavior |
|---|
| Catch up + live | Run still active in buffer | Replays missed events, then streams live events |
| Replay | Run completed, still in buffer | Replays all missed events |
| DB fallback | Buffer expired (30 min) | Falls back to database |
The /resume stream includes meta events before data events:
| Event | Meaning |
|---|
catch_up | Run still active. Missed events follow, then live events. |
replay | Run already completed. All missed events follow. |
subscribed | Catch-up complete. Now receiving live events. |
error | Run not found or other issue. |
Multi-Container Deployments
The detached task and event buffer live in-process on the instance that started the run. In a multi-replica setup, a /resume request that lands on a different instance misses the buffer and falls back to the database (no live tail until the run completes).
Route /resume requests by run_id from the URL path (sticky session / consistent hashing at the load balancer) so they reach the originating instance. Only /resume needs affinity. The initial run-start request can hit any instance.
Developer Resources