Delivering Temporal workflow output to multiple devices

Temporal workflows execute on workers. The workflow knows its inputs, its current state, and the activities it has executed. It has no concept of which browsers, devices, or sessions are watching it.

This is correct by design. Execution durability is independent of client connections. A workflow runs to completion regardless of whether anyone is watching. The execution model doesn't change based on the audience.

The implication for multi-device delivery is that fan-out - sending the same output to multiple connected clients - is entirely outside Temporal's scope. The workflow produces output once. Distributing it is a separate problem.

The default multi-device pattern is independent polling: each device polls the workflow's query handler every few seconds and renders whatever state it receives.

Two devices watching the same workflow means two independent polling loops. At two-second intervals, a five-minute workflow generates 150 query calls per device, or 300 total for two devices. At three devices it's 450. Each query runs on a worker.

The poll-per-device model scales linearly with the number of watching clients. For workflows where the number of observers is small and predictable, this may be acceptable. For workflows that are shared across teams e.g. a document processing job, a bulk operation or a background agent, the device count is not predictable, and polling cost grows proportionally.

Teams that move beyond polling often reach for a Redis pub/sub relay. An activity publishes to a Redis channel and a relay forwards events to SSE endpoints the browser holds open.

Redis pub/sub is a broadcast to whoever is currently subscribed. A second device connecting to the SSE endpoint starts receiving events from that moment. It has no access to events that arrived before it connected.

A user switching from laptop to phone mid-run gets a partial view on the phone. Everything the workflow produced before the phone connected is not available. The phone sees the workflow from wherever it happened to join.

This is a structural constraint of pub/sub. Messages are not stored. There is no concept of a per-subscriber offset or catch-up position. Redis Streams provides persistence and consumer groups, but it changes the relay architecture significantly: the relay must now poll or block-read from the stream, and offset management per device adds complexity that the pub/sub pattern avoids.

For a second device to see the complete output of a running workflow, it needs two things: the history of what the workflow has produced so far, and all new output from that point forward.

A state query gives the current accumulated state. Useful for a snapshot but not a stream, as it doesn't provide the sequence of events that led to the current state, just where things stand now. For streaming output like LLM tokens or step-by-step progress, the current state is a collapsed view that loses the ordering information.

Position-based replay gives the device everything from a specific point in the event stream. The delivery layer buffers events and serves them by offset. The connecting device requests events from position zero and receives the full run history, then stays subscribed for new events.

Temporal's Workflow Streams improves on Redis pub/sub for a single connected device: subscribers track their own offset client-side, so a reconnecting client can resume from where it left off. However, a second device joining mid-run has no offset to start from. It receives events from the moment it connects and has no way to retrieve what came before. Two devices, or tabs, watching the same workflow see different, incomplete views.

Workflow Streams is also Python-only. Per-roundtrip latency is around 100ms, which suits step-level progress updates better than token-by-token streaming.

A delivery layer handles fan-out and per-device session tracking alongside Temporal. When a workflow activity publishes a single event, the delivery layer distributes it to every subscribed client simultaneously. Adding a second or third device doesn't change anything on the workflow side.

When a new device connects mid-run, it requests replay from position zero. The delivery layer serves the buffered event history and transitions seamlessly to the live stream. The device sees everything the workflow has produced, in order, from the beginning.

Each device maintains its own position independently. A phone that was offline during part of the run reconnects, requests events from its last received position, and catches up without a full workflow query. The workflow execution is unaffected throughout.

Temporal handles execution. The delivery layer handles every client, wherever they are, and whatever they missed - in a durable session.

Ably AI Transport provides a delivery layer for Temporal with fan-out to multiple devices, per-device session tracking, and catch-up replay for devices that connect mid-run. Visit the Ably AI Transport overview, read the documentation, or sign up free to start building. For a broader overview of why Temporal workflows need a frontend delivery layer, see ably.com/topic/temporal-realtime-transport.