Temporal Workflow Streams vs Ably AI Transport

• Temporal Workflow Streams and Ably AI Transport solve different problems: one streams a single Workflow's output, the other is the session layer built around it.

• Workflow Streams alone is enough for a single connected client watching step-level progress. Getting multiple participants, retry reconciliation, or reach to an offline user all requires Ably AI Transport running alongside it.

• The two aren't mutually exclusive, and for most production use-cases, you will likely need to use Temporal and Ably.

For the broader picture of why a Temporal Workflow needs a delivery layer at all, see Reaching browsers reliably with Temporal and durable sessions.

Workflow Streams is in Public Preview for Python and TypeScript, with Go and Java still on the roadmap. It delivers a durable, append-only event log hosted in a single Temporal Workflow, reached by long-polling. It gives one external subscriber exactly-once, ordered delivery of that Workflow's output. And it solves one problem well: getting a single Workflow's output to a client that already knows which Workflow to ask for.

Ably AI Transport is a durable session layer that runs alongside a Temporal deployment. Each Activity publishes its output to a shared session, where it becomes a Step, the unit of published output. The stepIdFor helper keys that Step to the Activity's own Temporal activity ID. Because the session is shared, any number of participants, not just one external client, can subscribe and publish to it. Retried Activity output reconciles automatically through that same mechanism.

Beyond the live session, Ably AI Transport notifies users who've closed the app entirely that a long-running agent has finished, using Ably's native Push API alongside the session. It also lets a user edit or regenerate any message, so the conversation forks into a branch rather than overwriting what came before.

Here's the difference at a glance. Long-polling versus push delivery, one-way versus two-way channels, and retry handling are each explained next.

A Workflow Stream subscriber calls Temporal's Update mechanism, gets a batch of events if any are waiting, and calls again if there aren't. That's a request-response pattern repeated on an interval. Not a connection the server pushes into. Ably AI Transport delivers over a persistent connection: an Activity publishes a Step once, and every subscribed client receives it as it happens.

For step-level progress, the gap between polling on an interval and pushing over a persistent connection barely registers. For token-by-token streaming meant to feel live, that same gap becomes noticeable, which is exactly why Workflow Streams' own tuning guidance recommends 100-200ms batch intervals instead of the 2-second default.

A Workflow Stream carries output in one direction only, with no path for the subscriber to send anything back in. An Ably AI Transport session has no such asymmetry: the user, the agent, another agent working the same task, or a human operator joining mid-conversation all publish and subscribe on the same session. That's what makes cancel signals, tool approvals, and human takeover possible without a second communication path bolted on beside the stream.

This is the sharpest, least-discussed difference between the two. Temporal's own documentation states plainly that when an Activity publishing to a stream fails and Temporal retries it, events from both the failed attempt and the successful retry land in the stream side by side. Consumers must reconcile the two themselves, typically via a retry-sentinel event the client watches for.

Ably AI Transport resolves this at the infrastructure level. Because a retried Activity publishes under the same stepId as its failed predecessor, the retry's output supersedes the failed attempt's output on the session automatically, with no client-side reconciliation code required. That only works because AI Transport owns the full session; Workflow Streams' narrower, single-purpose scope is exactly why reconciling retries wasn't part of its design.

A retry, a cancel, and a human handoff rarely arrive one at a time in production. They compound within a single turn, , so it's worth seeing what happens when they occur together, rather than as three separate instances.

Picture a support agent workflow handling a billing dispute. The agent calls a billing-lookup Activity, which times out once, and Temporal retries it under the same activity ID. Partway through the retry's response, the customer decides they'd rather speak to a person and hits cancel. A human agent then joins to review what happened before taking over.

On Workflow Streams alone, the timed-out attempt's partial output and the retry's output both land in the stream. Reconciling the two isn't automatic, so the client rendering the chat window has to notice that a retry happened and discard the failed attempt's output itself. If the client misses that step, the user briefly sees two conflicting answers. The cancel has no session to travel on beyond whatever mechanism the team built for it. And the human agent joining mid-conversation has no built-in way to read what already happened.

With Ably AI Transport running alongside the same Workflow, the retry's output supersedes the timed-out attempt's automatically, so the chat window only ever shows one answer. The cancel publishes to the session and reaches the in-flight Activity as an abort signal directly. The human agent joins the same session as the customer and the agent are already on, and reads the full history immediately. None of this replaces the Workflow; it's the same Temporal execution, with everything Workflow Streams doesn't cover handled by the session underneath it.

Which one a given Workflow needs comes down to two things: how many participants are actually involved, and what has to happen when something goes wrong mid-turn. The conditions below cover most production decisions, though not every edge case.

• The production environment involves a single external client that stays connected for the whole run, with no second device or tab expected to join mid-stream.

• Step-level progress updates are sufficient, rather than token-by-token output, where 100ms roundtrip latency doesn't register as lag.

• A Python or TypeScript stack is already in place, with no near-term need for Go or Java support.

• No requirement for the client to send anything back into the Workflow beyond what Temporal's existing Signal and Update mechanisms already cover.

• More than one device, tab, or participant needs to see the same session, including a second device joining after the run has already started.

• Users, agents, or human operators need to publish into the same channel the agent's output arrives on, not only watch it.

• Retried Activity output needs to reconcile automatically rather than through client-side sentinel-handling logic.

• A user who goes offline mid-task still needs to be reached, or a human needs to take over a live conversation with full context intact.

• Conversations run long enough to hit Temporal's Continue-As-New boundary, and the delivered experience shouldn't visibly reset when that happens.

Temporal Workflow Streams and Ably AI Transport answer different questions, not competing versions of the same one. Workflow Streams gives a single Workflow durable, ordered output to one external subscriber over long-polling, with no channel for that subscriber to publish back. Ably AI Transport is the session layer around it: realtime push to any number of participants, automatic reconciliation of retried Activity output through stepId, and continuity through Temporal's own Continue-As-New boundary. Whether Workflow Streams needs a session layer alongside it depends on whether a second participant, a retry, or an offline user is ever part of the picture, not on which product is more capable in the abstract.

For the broader architecture this page sits inside, see Reaching browsers reliably with Temporal and durable sessions. For the full mechanics of multi-device fan-out, see Delivering Temporal workflow output to multiple devices.

Read the Ably AI Transport Temporal integration guide for the full API.

Framing this as a choice between the two is usually the wrong starting question. Workflow Streams is a Temporal-native way to stream one Workflow's output to a client that already knows which Workflow to ask for. Ably AI Transport is a session layer that runs alongside Temporal for everything beyond that: multiple participants, retry reconciliation, and offline reach. Most production Temporal-based AI stacks that need more than a single connected client end up running both.

No. Language support and scope are separate questions. TypeScript reaching Public Preview means more developers can use Workflow Streams for what it already does well, streaming one Workflow's output to one external subscriber. But it doesn't add fan-out to multiple devices, a return channel for input, or automatic retry reconciliation.

It means wrapping Temporal Activity calls with the stepIdFor helper so each Activity's output publishes to an AI Transport session under a stepId derived from its Temporal activity ID, then subscribing the frontend to that session instead of, or alongside, the Workflow Stream. Temporal and Ably AI Transport stay two separate products working together: nothing about how Workflows or Activities are written needs to change.

Ably AI Transport is designed to replace what a team would otherwise build and operate themselves, cursor tracking, a retention buffer, and fan-out logic, rather than sit as an additional layer on top of an already-complete stack. The overhead comparison depends on what a given team's Workflow Streams setup already handles versus what it doesn't, so the honest answer is case by case rather than a fixed number. Talk to the Ably team directly if you want this mapped against your specific setup.

Unlikely to change the comparison itself. Broader language support would let more teams adopt Workflow Streams for single-client, single-direction delivery, but the boundaries covered on this page, one-way delivery, single-Workflow scope, and manual retry reconciliation, are structural to what Workflow Streams is built to do, not limitations tied to a specific language.

Ably AI Transport ships with SOC 2 Type II and HIPAA compliance today, with its ISMS being aligned to ISO 27001. Adding a session layer alongside Temporal doesn't change what Temporal itself is responsible for; it adds a system to the data path that needs its own compliance posture, which is why AI Transport's certifications matter independently of Temporal's.