How we stream task status over WebSockets

Parallel runs emit dozens of state changes per second. Polling the REST API would lag, load the server, and still miss micro-states. We stream structured events over a single WebSocket per active session instead.

Event model

• Task graph snapshots when planning finishes or the graph changes.
• Per-agent status: queued, running, waiting, complete, failed.
• Partial output chunks for long merges so the UI can render incrementally.
• Terminal events with merge metadata and citation attachments.

Isolation and recovery

Channels are scoped to tenant and conversation. Reconnecting clients receive a fresh graph snapshot plus any in-flight branch state so the panel catches up without replaying the entire run log.

Client expectations

Treat the socket as best-effort ordering within a branch; merge ordering is explicit in the payload. UI layers should debounce rapid agent ticks but never coalesce terminal failure states — users need to see errors immediately.