Why isn't Redis pub/sub enough for AI agent streaming?

• Redis pub/sub delivers messages only to subscribers connected at the moment of publish, with no persistence. Redis Streams adds persistence and consumer groups, but consumer groups split messages across consumers rather than broadcasting the same message to all of them.

• A Redis buffer has no native concept of agent presence. Telling a stalled agent apart from a crashed one requires a heartbeat mechanism you build and maintain yourself.

• When more than one backend service needs to publish into the same conversation, Redis has no built-in way to order and aggregate those writes into one coherent view.

• A durable session layer treats presence, multi-publisher fan-in, and handoff continuity as properties of the session itself, not application code layered on top of a message buffer.

Redis shows up in most AI streaming stacks the same way: a backend process publishes tokens or events to a channel, and a relay forwards them to the browser over Server-Sent Events. It is a reasonable first architecture, and Redis's own documentation is direct about what each primitive guarantees.

Redis pub/sub delivers messages only to subscribers connected at the moment of publish. Redis's own pub/sub documentation describes this as at-most-once delivery: once the server sends a message, there is no second attempt, and a subscriber that is disconnected when a message is published never receives it. There is no storage layer behind the channel, so nothing is retained to replay later.

Redis Streams solves the persistence half of that problem. Messages are appended to a log and stay there until trimmed, and consumer groups let multiple readers track their own position in that log. But consumer groups were built for a different job. They split a workload across parallel workers so each message is processed once, not broadcast the same message to every interested party. A group with three consumers reading the same stream does not give all three the same messages; it divides the messages between them.

This division, between low-latency delivery and persistent replay, is why teams typically layer pub/sub and Streams together rather than picking one. Pub/sub handles delivery to a connected client, and Streams handles the replay case. Two existing pieces cover this resumption mechanism in detail, including the write amplification and cancellation-ambiguity costs of running it in production: Ably's comparison of the Redis-to-SSE relay pattern for Temporal workflows, and the Vercel AI SDK's resumable-stream implementation.

But neither buffer, on its own or combined, answers what comes next: whether the thing publishing to the session is still alive, whether more than one thing is publishing to it, or whether a human can pick up the conversation the agent started.

Five criteria matter once an AI product moves past what a single publisher and a single device can handle:

1. Stream resumption

2. Agent crash detection

3. Multi-service fan-in

4. Human handoff

5. Multi-device continuity

The first is something Redis handles reasonably well within limits, but AI products reach those limits quickly. The other four are gaps Redis was never built to close, since it has no session-layer primitive for presence, ordering, or persistent identity, only a channel that delivers whatever is published to it.

Redis handles stream resumption reasonably well within limits. A user who refreshes the page needs to reconnect and pick up whatever they missed, and Redis Streams' persistence covers that as long as the client stays on the same device and network path. Redis's real limits show up once reconnects cross devices or networks: write amplification, cancellation ambiguity, and tight coupling to whichever framework relay sits in front of it. The full mechanics are covered in AI chat stream resumption: when Redis is enough, and when you need durable sessions.

A Redis channel has no opinion on who is publishing to it or whether they are still there. It delivers whatever arrives and stays silent when nothing does. And silence is exactly the signal you cannot interpret.

When an agent stops sending tokens, that silence has three possible causes:

1. The agent is still generating a response, just slowly.

2. The agent finished and has nothing more to say.

3. The agent's process crashed mid-turn.

A Redis-backed relay cannot distinguish between these three scenarios.

The common workaround for that ambiguity is to build a heartbeat mechanism. To do this, the agent publishes a keepalive on an interval, and the client infers a crash when the interval is missed by a defined margin. That works, but setting the margin involves a lot of guesswork.

Set it too short, and a slow but healthy agent gets flagged as dead. Set it too long, and a user waits through a genuine crash before the UI tells them anything is wrong.

And the cost of getting that margin wrong is not hypothetical. A support agent that silently died mid-response leaves the user staring at a stalled UI with no path to escalation until a timeout finally fires, sometimes tens of seconds later.

Multiply that by every session running on the same infrastructure, and the aggregate wasted wait time is a UX cost that nobody had to design for. That cost exists only because the system has no way to signal whether the agent is still there.

Redis pub/sub was built around one publisher per channel: one backend process owns the channel, and there is exactly one place events come from. That assumption breaks down the moment a second service needs to write into the same conversation.

This is because Redis has no built-in mechanism to order or aggregate writes from multiple publishers into one coherent view. Each publisher writes independently, and if two services publish near-simultaneously, the relay and the client see whatever order the network happened to deliver them in.

Getting a stable, ordered view of a multi-publisher conversation means building your own sequencing layer on top: a shared counter, a coordinator service, or an application-level protocol for who publishes when. None of that comes from Redis itself.

This is a different problem from delivery reliability. A Redis channel can deliver every message from every publisher perfectly and still leave you with an inconsistent view if nothing establishes the order they should be read in.

Multi-service fan-in becomes necessary the moment your product grows past a single agent. Common examples include a triage bot handing off to a specialist, a primary agent coordinating with a background research task, or a moderation layer sitting alongside the main conversation.

Human handoff, an agent stepping aside so a support rep can take over, or a rep stepping in briefly and handing back, is a session-continuity problem, not a messaging problem. The question is not whether a message reaches the human. It is whether the human arrives with the same context the agent had.

A Redis pub/sub channel carries no history, so a human joining a channel after the fact sees nothing that was published before they connected. Reconstructing the conversation for them means querying whatever database stores the chat log separately and rendering it before the handoff completes, which introduces a gap between "the agent stopped" and "the human is fully briefed."

Redis Streams closes part of this gap since a new consumer group can replay the stream from the beginning. But a consumer group's default job is to split messages across workers, not hand a single reader a complete replay ordered exactly as it happened.

Getting that right requires deliberate consumer group configuration, and most teams don't set it up until they actually need it.

No, not on its own. Multi-device continuity is a fourth gap worth naming. A user who switches from a laptop to a phone mid-conversation needs the second device to pick up the same conversation state that the first device had. It shouldn't see a disconnected view that starts from whenever it joined. Redis pub/sub delivers only to subscribers connected at the moment of publish, so a second device joining mid-response misses everything that happened before it connected.

A common assumption is that moving to Redis Streams fixes this, since consumer groups add persistence and replay on top of plain pub/sub. They do not fix it. The same mechanism that makes consumer groups useful for splitting work across multiple workers is exactly what breaks multi-device delivery.

A consumer group's job is to split a stream's messages across the consumers reading from it, so that each message goes to exactly one consumer in the group. That is the correct behavior for a task queue, where you want ten workers processing ten messages once each. It is the wrong behavior for a user's second device joining an active conversation, where you want that device to see every message the first device already saw, not a disjoint subset.

Getting genuine fan-out from Streams means putting each device in its own consumer group, one group per device rather than one group per conversation, and managing that group's lifecycle (creation, cleanup, offset tracking per device) entirely at the application layer.

Each of these gaps traces back to the same root cause covered above. Ably AI Transport is a durable session layer that closes each one as a property of the session, rather than code your team builds and maintains, and every capability below is documented and available today.

An Ably AI Transport session persists independently of any single connection, so a client resumes against the session itself rather than a specific device or network path. Reconnecting from a different device or after a network change works the same way as reconnecting on the same device, without the write amplification or cancellation-ambiguity tradeoffs of building that behavior on Redis.

Ably AI Transport's agent presence feature uses Ably's Presence API rather than a custom heartbeat. The agent enters presence on the session and updates its status (thinking, streaming, idle) as it moves through a turn, and a client reads that status directly instead of inferring health from silence. When the agent's process dies without a clean disconnect, Ably's own connection-level presence detection fires the offline event automatically, so the crash surfaces as a presence change rather than a timeout you configured yourself.

Ably's session model aggregates and orders messages from any number of publishers on the same session by default. An orchestrator, a moderation layer, or a background task can all publish into the same session without a custom sequencing layer to keep the conversation coherent.

In Ably AI Transport, session history is the conversation record itself. A human operator joining the same session as an agent sees that history immediately, with no separate database query needed. A shared session, full history, and presence together support both a warm transfer, where the agent introduces the human and stays briefly, and a cold transfer, where the agent disconnects outright, since any participant who joins the session sees the same state.

An Ably AI Transport session, using multi-device sessions, treats every connected device as a subscriber to the same conversation state. A second device joining mid-response sees exactly what the first device sees, current turn included, without per-device consumer group management.

None of the five criteria above make Redis the wrong choice for every AI streaming stack. The decision of whether to move to a durable session layer, or stick with Redis, comes down to which of these conditions your product actually has to meet, and what you are willing to build and operate to get there. The table below helps you to evaluate what you need.

Ably AI Transport is a genuine new dependency, not a drop-in replacement that removes complexity for free. Adding it means integrating its session and auth model into your application. That integration work is real. But it replaces the workarounds covered above rather than adding to them: a heartbeat mechanism, a custom sequencing layer, per-device consumer group management, and a separate database query for handoff context.

What you get in exchange is presence, multi-publisher ordering, and cross-device continuity as properties of the session rather than code your team writes and maintains. Whether that trade is worth it depends on which row in the table above your product actually needs, not on whether Redis is capable in the abstract. It is.

For hands-on evaluation, the Ably AI Transport docs cover setup and configuration in detail. For the resumption case specifically, see the deep dive on the Vercel AI SDK's resumable-stream pattern. If Temporal orchestrates the underlying workflow, see how the same Redis limitations apply specifically to delivering that workflow's output to a frontend.

Not on its own. Redis pub/sub has no presence mechanism, so a crashed agent looks identical to a slow one: both stop publishing. Detecting the difference requires a heartbeat you build and tune yourself. Or it requires a session layer with a native presence API that reports a clean disconnect as an event rather than an inferred timeout.

Partially. Redis Streams can replay history to a newly connected consumer. But consumer groups are built to split messages across workers, not hand one reader a complete, ordered replay by default. Reconstructing full context for a human operator typically means querying a separate chat log rather than relying on the Redis channel alone.

Redis has no built-in mechanism to order or aggregate writes from multiple publishers. You need your own sequencing layer, whether that is a shared counter, a coordinator service, or an application-level protocol. Otherwise, two services publishing near-simultaneously will arrive in whatever order the network delivers them.

Not without extra work. A consumer group splits a stream's messages across its consumers by default, so a second consumer does not automatically see what the first one saw. Getting per-device broadcast from Streams means creating one consumer group per device and managing its lifecycle yourself.

Beyond resumption, Redis has three gaps. It has no native presence signal for agent health. It has no built-in ordering for multiple publishers writing into one session. And it has no session history model that gives a joining participant, a second device or a human operator, an automatic, complete view of the conversation so far.