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

[upbeat music] Okay, um.

Whoo. [clapping] I think time to start. Yeah. Come on. Uh, can we start with a quick show of hands? So who here has built some kind of AI chat app, right, some kind of AI chat experience?

Okay, but that was quick, right? Almost everybody in this room, right? So this is the case where you've got some kind of chat app. You've got an agent on the backend, the user sends a message to the agent, and the agent streams a response back live to the user as it's being generated, right?

And this is fundamental building block of AI user experiences we see in every AI chat app today. And first, I wanna have a quick look at how this is implemented today, right?

So the default pattern is to use direct HTTP streaming. So the most popular frameworks, Vercel's AI SDK, TanStack AI, use SSE by default, server-sent events. And so concretely, what this means is the client makes a request to the agent, and it establishes a persistent point-to-point connection with the agent, and the agent then invokes the LLM, and it

obtains the stream of events, and it pipes those events back to the client over the connection as server-sent events, right? And this is great, right? It's really easy to get something working.

But this paradigm is kind of fundamentally oriented on the idea of a single client establishing a single connection to a single agent. And today, I'm gonna make the case that that fundamentally limits the quality and the richness of the experiences that we can build in our AI products.

So my name is Mike Christensen. I'm a staff engineer at Ably. Ably is a real-time messaging platform, and we build SDKs and APIs for any kind of live or interactive experience, and that includes AI experiences.

And we operate our platform at real scale, so every month we handle traffic for more than two billion devices. We handle more than thirty billion monthly connections. We process more than two trillion API operations.

And over the past year, we've been speaking to engineering teams at more than forty companies across ten industries, and these are companies that are shipping AI agents, AI copilots, AI assistants in their products to millions of users.

And these companies are really pushing the boundaries of what AI products can feel like, right? Because when you add AI capabilities to your product, it fundamentally changes the user experience.

So these companies are exploring these new interaction models, and they're working through the engineering challenges to deliver these experiences reliably in production. And so today I'm gonna share what we've learnt by talking to these companies.

I'm gonna show you where the sort of direct HTTP streaming model starts to break down and why. And I'm gonna share with you the emerging patterns that we're seeing many engineering teams adopt to tackle these problems.

So we found that companies shipping the best AI experiences really invest in three foundational capabilities, and we think that these capabilities really separate a fragile demo from a great AI product experience.

So the first of these capabilities is resilient delivery. This is about building streams that survive disconnections, right? Think about mobile. You know, you walk out of the house, your phone drops off the Wi-Fi, connects to 5G.

That severs the connection, right? Or maybe the user refreshes the page, or they navigate away from the app and they come back. And what you want is that when the connection drops, clients are able to reconnect and pick up exactly from where they left off.

The second core capability is about providing continuity across surfaces, right? So users move between surfaces all the time. You know, you open the experience in a new tab, or you open it on your phone.

And really, the conversation session should follow you around, right? That no matter which device you're using, the session should be fully in sync, including any live activity. And the third core capability is about live control, right?

So the best AI products do better than a simple sequential request-response interaction pattern, right? They let you communicate with the agent while it's working. So think about how you use Claude Code, right?

You know, you can see Claude's doing something. You might send a message, steer it. You send a follow-up, you ask it to do something else. And this requires visibility into what the agent is doing, and it allows clients-- it requires clients to be able to communicate with the agent while it's working.

So why is this hard with a direct HTTP streaming approach? The root cause is because everything is coupled to a single request, right? So if you think about that live response stream that you've got from an agent, the health of that stream is essentially tied to the health of that end client's connection, right?

So if that connection drops, the stream's gone.

Another problem is with direct HTTP streaming, that connection is now a private pipe between the client and the agent. So if you open the experience on another tab or on your phone, you have no visibility of that in-progress response.

And a third problem is because this stream, right, isn't a shared resource, other clients and other tabs, other devices can't communicate with the agent, can't reach the agent to interact with it, steer it, interrupt it.

So a pattern we're seeing many companies adopt is to decouple the agent layer from the client layer. And many teams are doing this with a concept called durable sessions.

And so what this is is a shared resource that sits between the agent layer and the client layer, and it's a persistent and stateful medium through which agents and clients can interact.

And as we'll see, this makes it much easier to build, uh, resilient streaming experiences, streaming, uh, experiences that work across multiple tabs or devices, and it allows any client to interact with agents as they work.

So let's have a quick look at some examples now of where the sort of direct HTTP streaming model breaks down, and we'll see how this durable sessions idea can help us.

So let's look at how you might support resumable HTTP, uh, resumable streams with a direct HTTP streaming approach. So in this scenario, the client sends a request to the agent, and the agent starts streaming the response, and then the client's connection drops halfway through, right?

And what we want is the client can reestablish the connection and can resume the stream from where it left off. So when the client's connection drops, the LLM is still working, right, it's still generating events, and these events have nowhere to go, right?

So how do you build resumes? Well, you need to store these events. You, maybe you write them to an in-memory store like Redis. You need to store them with sequence numbers, so you know the order of these events.

And then you need some kind of explicit resume handler on your backend so that when a client tries to reconnect and resume, the resume handler is able to work out the exact set of events that the client missed and replay those back to the client in the correct order.

And so the problem here is that the stream is being explicitly managed by the agent. And so the agent has to do this for every reconnecting client because, you know, their connections drop at different times, and so each client has a different set of events that need to be replayed.

So you need to build all of this complex plum- plumbing from scratch, you know, instead of focusing on building great agents. So how does durable sessions help? So by decoupling the agent from the client, uh, you allow the agent to write events directly to the session without thinking about the health of the end client's connection, right?

And simultaneously, you let clients connect directly to the session and replay events or resume the stream from the session without the agent having to worry about implementing that logic.

And there's an interesting problem here if you're using, um, SSE, server-sent events, um, in particular, because there's a conflict between supporting resumability and offering live control over agents to clients.

And the reason for this is that SSE is one way, right? It's a strictly one-way pipe from the server to the client. So this comes up if you think about you wanna add a Stop button, right, into your, into your experience.

And the agent's streaming a response, you hit stop, and it cancels that in-progress generation. And so the client has no upstream channel through which it can signal to the agent to cancel the generation, right?

So the only thing it can do is close the connection, and that now creates ambiguity because what does the agent do, right? Does it allow the LLM to keep generating events and buffer these events, assuming the client's gonna try and reconnect and resume later?

Or does it treat it as a cancellation, cancel the LLM, um, LLM, and stop burning through these expensive tokens?

And so, you know, resume and cancel are mutually exclusive when you're using, uh, SSE in particular, and there's some evidence for this. So Vercel's AI SDK, for example, uses SSE by default, and their docs state that abort is incompatible with resume functionality, and it's for this reason.

So what do we need? We need bidirectional control, right? So maybe we can replace SSE. We can use something like WebSockets, and that then opens up the possibility for much richer interactions where clients can interact with agents.

Okay, so we've swapped out our SSE, uh, transport for WebSockets. But as we'll see, a bidirectional transport doesn't solve all of our problems automatically, and these problems arise when you try to interact, uh, from multiple devices.

So in this scenario, uh, you send a message to the agent, the agent is streaming a response, and then you open that same session in another tab, right? And so the problem is, in this second tab, you have no visibility over that live response stream, right?

Because the second tab isn't the one that sent the request that invoked the agent and established the connection. So the second tab doesn't see anything, right? While that response is being streamed, there's no visibility.

And then this presents a problem when we think about steering or controlling or guiding the agent, um, from multiple tabs or devices. So you send an, uh, uh, a message to the agent.

In this case, you ask it, uh, "Book me a flight for next Tuesday." Agent's working on this in the background. You swap to your phone, uh, and you have the same problem here.

The phone doesn't have visibility of the ongoing work of the agent, but also the phone has no upstream channel to the agent in order to send your follow-up request, which is, "Tuesday doesn't work for me.

I need, I need the flight on Wednesday." There's no way to reach the agent.

So a durable sessions layer, again, makes this easier, um, for us to support these multi-client experiences with live control. And we can do this because all clients can hold a persistent connection to the durable session that is always active, right?

So the connection's not just there when you invoke and initiate a request with an agent. You have constant visibility over the activity in the session through a continuously maintained connection.

And clients can continue to resume, right, through the session. But because the session is also a shared resource, right, and the agent has full visibility of the activity in the session as well, it means that any client can route to and interact with the agent.

So you can do this from any tab or any device.

And so the final example I want to talk about is about concurrent activity, right? So this is about multi-agent architectures. We've got multiple agents that are participating in this session.

And so the pattern we've got here is the, uh, uh, user is establishing, making a request to, uh, an orchestrator agent, and this orchestrator agent is then delegating subtasks to these specialized agents, right?

And what we'd like to provide is full visibility of all the granular progress that these sub-agents are, are working on. Um, now, the problem here is the orchestrator is handling the user's request, right?

So we're kind of forcing the orchestrator to do two things. There's a dual purpose role of both orchestrating the task and delegating tasks, and also proxying back these sort of granular updates from these sub-agents, right?

So this is adding a lot of complexity to your architecture when really the orchestrator, uh, only cares about the final results from these sub-agents. Shouldn't need to worry about relaying granular progress.

So again, a durable sessions model makes this easier. Um, so in this model, all agents can write independently to the durable session layer, right? So now we don't have to flow all these granular updates through some centralized agent to pro- provide full visibility of all the activity in the session.

And clients only need to subscribe to a single entity as well, right? Um, they only subscribe to the session, and they have full visibility of activity from all these agents, however many there are working on the task, but also activity from other clients.

And this, uh, pattern can drastically simplify your architecture.

So what we've described here sounds an awful like Pub/Sub, right? Um, and we can build durable sessions on top of, uh, Pub/Sub. So, um, at Ably, we have this concept called channels, and Ably channels let you communicate.

Um, so publishers of messages and subscribers of messages can communicate with each other, but not directly. They do this through a shared resource, which we call a channel. Um, and this inherently decouples, uh, publishers and subscribers, so it decouples clients and agents.

And Ably channels have the kind of key properties that we would need to build a durable session layer. So they are independently addressable, so this means that any client or any agent can connect to this session just by specifying the right channel name.

They are persistent, which means the messages on the channel outlive the life cycle of any individual connection, any individual device, um, any individual agent. And they're fully resumable, right?

So if you're a client that drops a connection, you can automatically reconnect to the channel, and all the events are, um, delivered exactly from where you left off.

So this is how, um, we've found many of our customers have built these kind of resilient multi, uh, surface experiences.

Um, to make building durable sessions even easier, we've, um, been working on, uh, something we call Ably AI Transport. So this is a, a drop-in layer for building this durable session pattern.

Um, and it's a new SDK which automatically plugs into any event stream format, so whatever model provider or agent framework you're using. Um, and under the hood, it's using Ably channels to provide this sort of durable session layer, but with all the complexity of building a durable session, uh, handled for you out of the box.

So, um, the channel does some cool things as well, right? So it, like, materializes events in the channel, so you can stream in text chunks that are being generated from the LLM, and the channel automatically materializes that into the complete response.

They, uh, provide automatic resumability. They handle multiplexing, so you can have concurrent activity over the channel, and it's all fully multiplexed and handled, and it supports multi-client and multi-device fan-out with full bi-directional control.

Uh, it also includes a suite of additional tools for building great AI user experiences. So some of these are really important, right? Things like push notifications. If you've got an agent doing some background asynchronous work, you want to be notified when it's completed.

There's also things like APIs for shared or subscribable data objects. So if you've got agents and users kind of collaborating over some shared data in real time, this is possible.

So to try and make some of this a little bit more concrete, um, I have a quick demo, um, to show you kind of what this looks like in practice.

So this is a, a classic kind of AI chat interface for a AI support chat for, uh, like, an electronics shop, right? Um, so let's see if we can get the video.

Cool. So, you know, the usual kind of features exist in this kind of conversational interface. So here, you know, the agent's making a client-side call, tool call to get the user's location.

It's making a server-side tool call to show the user a list of stores in its location. And we can see that this works across multiple tabs, um, out of the box.

This is because it's powered by this durable session layer underneath, and it gives all clients a shared view of the session. Now, here we've got a streamed response, and we can refresh the page, and you can see it's all remains absolutely automatically in sync.

There is no additional le- agent logic to make this work, right? This just works from the client, um, consuming and subscribing from the channel. We can even kill the, uh, the network here, so we're forcing the client to disconnect and reconnect, and everything just carries on automatically, um, without any additional complexity.

We can also sort of interact for multiple tabs. So here in the second tab, we've kicked off a, a specialized sub-agent that's gonna do some product research, and we've got some granular visibility.

We're gonna cancel that from the first tab, so you can, from whichever client or device, you can cancel that, um, that work. Um, here we've kicked off a, a product research task from one tab.

Um, this specialized agent is writing these events directly. There's no centralized orchestrator that's managing this. Um, here the user decided, okay, they're gonna purchase a pair of headphones, but at the same time they're going to cancel their existing order.

So now you've got concurrent activity in the session, two agents working in the session simultaneously. It's fully synchronized without all this, uh, uh, additional coordination.

And now this is quite cool, right? So the, the user here isn't happy with the re- the return pri- uh, the refund price, so they want to speak to a human.

So we can now add another participant into this session and transfer them over to a human agent. So we're gonna open up a, a support agent view over here, and we can see that this, uh, human support agent can, has full visibility of all of the activity in that session.

So they can see the full interaction history that the customer had with the AI agent, and they can then send a message to follow on as a human participant in that session to now communicate directly with that customer.

That's everything for today. Thank you very much. Please check out- [applause] [upbeat music]