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

backgroundstreamBehavior
FalseTrueDefault streaming. Runs inline. Client disconnect cancels the run.
FalseFalseNon-streaming. Returns full response.
TrueFalseFire-and-forget. Returns PENDING immediately. Poll for results.
TrueTrueResumable 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

  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 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.
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:
ScenarioConditionBehavior
Catch up + liveRun still active in bufferReplays missed events, then streams live events
ReplayRun completed, still in bufferReplays all missed events
DB fallbackBuffer expired (30 min)Falls back to database

Meta Events

The /resume stream includes meta events before data events:
EventMeaning
catch_upRun still active. Missed events follow, then live events.
replayRun already completed. All missed events follow.
subscribedCatch-up complete. Now receiving live events.
errorRun 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