Run agents, teams, and workflows in the background by passingDocumentation Index
Fetch the complete documentation index at: https://docs.agno.com/llms.txt
Use this file to discover all available pages before exploring further.
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)
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 without losing events.
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 catch up on missed events
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:| 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 |
Meta Events
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.