Why Your AI UX Is Broken (and It's Not the Model's Fault)

A user sends a message to an agent and watches its response appear as it is generated. The familiar implementation is direct HTTP streaming: the browser opens a persistent connection to the agent, the agent invokes an LLM, and the resulting events flow back to the browser. Christensen identifies server-sent events, or SSE, as the default used by Vercel’s AI SDK and TanStack AI. It is a straightforward way to get a working conversational interface.

That simplicity comes with an architectural assumption: one client establishes one connection to one agent. As long as the user stays on that connection, the response has an obvious destination. Richer experiences require the conversation and its ongoing work to exist independently of that private connection.

Mike Christensen introduces himself as a staff engineer at Ably, a platform for real-time messaging. He reports monthly platform traffic involving more than two billion devices, more than thirty billion connections, and more than two trillion API operations. These are his reported platform-scale figures, not measurements of AI performance.

Christensen says that, over the preceding year, Ably spoke with engineering teams at more than forty companies across ten industries, shipping agents, copilots, and assistants to millions of users. Those conversations provide the practical context: teams are changing how users interact with their products while working out how to deliver those interactions reliably.

Three capabilities distinguish the experience Christensen wants from a fragile streaming demo:

• Resilient delivery. Walking out of the house can move a phone from Wi-Fi to 5G and sever its connection. Refreshing a page or navigating away creates similar interruptions. On return, the client should pick up where it left off.
• Continuity across surfaces. Opening another tab or switching to a phone should expose the same session, including activity still in progress.
• Live control. Users should be able to communicate with an agent while it works. Claude Code provides the example: watch the work, send a follow-up, and steer the next action. That requires both visibility into the work and a path back to the agent.

A request-bound stream makes each requirement harder. Delivery depends on the original connection remaining healthy. A second tab cannot automatically observe the in-progress response because that response travels through a private pipe. Other devices also lack a shared route for reaching the working agent to steer or interrupt it.

A durable session moves the interaction into a persistent, stateful resource between clients and agents. The agent publishes its activity to the session; clients connect to that session to observe and participate. The lifetime of the work no longer has to match the lifetime of the client connection. This separation supplies the foundation for recovery, multiple simultaneous clients, and control during generation.

Suppose the client disconnects halfway through a response while the LLM continues generating. Those new events cannot reach the disconnected browser. Supporting resumption requires more than opening another connection:

1. Retain the events, for example in Redis, rather than discarding them when delivery fails.
2. Assign sequence numbers so their order is known.
3. Handle a resume request by identifying which events that client missed.
4. Replay the missing events in order so the client can continue from its previous position.

The bookkeeping is per client. Two clients can disconnect at different points, so they need different replay ranges. When the agent explicitly manages delivery, it must also manage these recovery responsibilities for every reconnecting client.

The durable-session model changes who owns that work. The agent writes events to the session without checking whether a particular browser is connected. Each browser reconnects to the session and obtains its missing events there. Retention and replay still have to exist, but they become responsibilities of the shared delivery layer rather than additional agent logic.

Now add a Stop button. SSE carries events from server to client; it does not itself provide an upstream channel for a cancellation message. If closing the response connection is the only cancellation signal in the design, the server receives an ambiguous event.

The same connection closure cannot reliably express both intentions. A resumable experience needs to distinguish loss of connectivity from a deliberate instruction to stop.

Christensen illustrates this with the AI SDK’s abort/resume warning. The documented limitation concerns the SDK’s resumable-stream behavior and its abort handling; it is not a universal prohibition on combining SSE delivery with cancellation. An architecture can retain SSE downstream and provide a separate upstream control path.

WebSockets are the alternative Christensen proposes because they provide bidirectional communication over the connection. That makes explicit control messages possible while output continues to arrive. It opens the door to steering and interruption, but changing the transport alone does not create a shared session.

Replace SSE with WebSockets and open the conversation in a second tab. The first tab still owns the connection that initiated the agent’s work. Unless something else distributes that activity, the second tab has no visibility into the response currently streaming to the first. Bidirectionality solves the direction of communication, not its scope.

The flight-booking example makes the distinction concrete. A user asks for a flight next Tuesday, then switches to a phone while the agent works. Tuesday no longer works; the user needs Wednesday. The phone must first see the ongoing work and then send the correction to the agent handling it. A private connection belonging to the original device supplies neither capability automatically.

With a durable session, all clients maintain connections to the same resource beyond individual agent invocations. They continuously observe session activity, and they can resume through that resource after interruptions. The agent also observes the session, giving the phone a route for the Wednesday correction. This establishes a communication path; it does not imply that a flight has already been booked or changed.

Multiple agents introduce another kind of concurrency. A user sends a request to an orchestrator, which delegates subtasks to specialized agents. To show detailed progress through the original response connection, the orchestrator must also collect and relay those agents’ intermediate updates.

That relay role is separate from deciding what work to delegate and collecting final results. In Christensen’s example, the orchestrator needs the sub-agents’ results, but it should not have to process every granular progress update merely so the user can see it.

With the session as the shared destination, each agent writes its own updates directly. The client subscribes to one session and sees activity from all participating agents, as well as other clients. Adding another specialist no longer requires routing its progress through a central agent just to reach the interface.

This architecture resembles publish/subscribe messaging because publishers and subscribers communicate through a shared resource rather than directly with one another. Ably calls that resource a channel. Clients and agents can therefore be decoupled while still participating in the same interaction.

Christensen identifies three channel properties that support a durable session:

• Independent addressing. A channel name identifies the session that clients and agents connect to.
• Persistence. Messages outlive individual connections, devices, and agent instances.
• Resumption. A reconnecting client can receive events from its previous position.

The recovery guarantee needs a boundary: the talk does not specify retention periods or recovery limits. Current Ably recovery documentation distinguishes short connection recovery from longer interruptions requiring history retrieval, and recovery after a page refresh has its own handling. Persistence should not be read as unlimited automatic replay.

Christensen then introduces Ably AI Transport, presented as a drop-in SDK that packages the durable-session pattern on top of channels. Its stated design accepts event streams across model providers and agent frameworks. That is an integration goal, not a claim that every framework needs no adapter: current documentation describes framework codecs, including custom codecs for unsupported frameworks. Those current APIs should not be assumed to be the exact SDK used in the recording.

The transport layer does more than forward individual chunks:

• Response materialization. Streamed text chunks accumulate into a complete response.
• Automatic resumption. Clients can recover delivery through the session.
• Multiplexing. Concurrent activity shares the channel while remaining distinct.
• Fan-out and control. Multiple clients and devices receive activity and can communicate back.

These capabilities package the delivery responsibilities that would otherwise spread through agent and client code.

The supporting UX extends beyond an open chat window. Push notifications can tell a user when background agent work finishes. Shared or subscribable data objects let users and agents collaborate on data in real time, giving the session useful forms of interaction beyond streamed text.

The demonstration starts with a familiar electronics-shop support chat. The agent makes a client-side tool call to obtain the user’s location, then a server-side tool call to return nearby stores. The conversation appears in multiple tabs, each displaying a shared view of the session.

While a response streams, the page is refreshed and the views remain synchronized. The demonstration then forces a network disconnection and reconnection, after which delivery continues. Christensen attributes that behavior to the client consuming and subscribing to the channel, without additional recovery logic in the agent. The selected frame shows two Acme Electronics Support windows with populated headphone reviews and browser network controls open; the recovery behavior is demonstrated over time, rather than established by the still alone.

Next, the second tab starts a specialized product-research agent and displays its granular progress. The first tab cancels that work. Control belongs to participants in the session, rather than exclusively to the browser that initiated the task.

A subsequent product-research task illustrates direct publication: the specialist writes its own events without a centralized orchestrator relaying them. The customer then chooses to purchase headphones while also canceling an existing order. Two agents work simultaneously, and the session keeps their activity synchronized across the clients.

The final interaction begins when the customer is unhappy with the refund amount and asks to speak to a human. A support-agent view opens onto the same session, adding another participant with visibility into its activity. The human can read the customer’s full interaction history with the AI and send a follow-on message directly to the customer. The handoff preserves the conversation already underway instead of requiring the customer to reconstruct it for a new participant.