Systems | Development | Analytics | API | Testing

Live polls are a staple of conferences, streams, and all-hands: a question goes up on the big screen, everyone votes from their phone, and the bars race each other in realtime. There's a lot of different ways you could implement this.

AI adoption programs tend to end in the same place. Tools are accessible, usage is up, and there's a dedicated Slack channel for wins. Six months later, nothing about how the team works has fundamentally changed. People are doing the same things – just slightly faster. And it’s easy for programs to stall when you’re measuring the wrong thing. Adoption (whether people have access and whether they're using the tools) is visible and easy to report.

You add a stop button to your AI chat app: a customer support agent, a coding assistant, a research tool the user can steer mid-task. A user clicks it mid-response. The frontend stops rendering. Then you check your backend logs and realize the underlying generation is still running, and you’re still paying for every token. This is not a bug.

If you have built an AI chat feature with the Vercel AI SDK, you have used its useChat hook. You give it your messages, and it streams the reply into your UI. You may have seen our post on the custom transport we built for the Vercel AI SDK. It swaps useChat's default transport for Ably AI Transport, adding resumable streams, cross-device and multi-user sync, conversation branching, history compaction, and stop-and-approve controls.

You are planning a trip with an AI assistant on your laptop. You are chatting with the agent, and as you progress it is dropping pins on a map, building a day-by-day itinerary, adding up a budget, and streaming its reasoning as it goes. The state of your interactive session is a combination of the chat history, the synthetic UI constructed by the agent during that process, and structured state, the itinerary, arising from the decisions you each make.

Last week we introduced AI Transport v0.2.0 and made one idea the centre of the design: the session is the channel. Every input, output, and lifecycle event for an AI conversation is just a message published to an Ably channel, which is what makes a session durable, multi-party, and resumable. In v0.3.0, we added first-class support for presence and LiveObjects to AI sessions, allowing you and your agent to see who's online and update shared state in real time.

We audited our skills library a few months ago and found twelve dashboards hiding in it. Not dashboards. Skills that built dashboards. Someone needed a view of some data, asked Claude to put it together, got a long HTML page out of it, and then wrapped the whole thing in a skill so others could run it again. Twelve times over, by different people, for different questions.

You've built an AI chat app on the Vercel AI SDK. It works in development. The model responds, the stream comes through, and the UI updates cleanly. Then you ship to production, and the transport layer starts showing its edges. Most of these failures are quiet: things that work in demos and break in ways that are hard to pin down until you know where to look. They share a common cause: DefaultChatTransport is built for HTTP, and HTTP has structural properties that some production requirements exceed.

I ran a webinar on this recently and had more to say than the time allowed, so this is the written version: the argument I was making, some context on the demo, and the questions that came up from people watching. The recording is below if you'd rather watch than read. The thesis: AI products are being let down by the user experience, not the model.

Version v0.2.0 of @ably/ai-transport reorganises the SDK to better support a wide range of interaction patterns. Everything in an AI session – input, output, agent lifecycle, control signals – is captured durably, allowing you to easily build the sophisticated interaction patterns that support modern AI user experiences. When we first built @ably/ai-transport, we modelled an AI conversation the way most people first picture it: as a request and a response.

Your AI agent is mid-task, waiting on the result of a search tool call it made 30 seconds ago. The user is watching a spinner. Then a network blip drops the connection. The application reconnects in under a second, fast enough that most monitoring wouldn't flag it. But the tool call result that came back during the gap is gone, and so are the 200 tokens the agent generated before the silence began. The reconnect succeeded - but the session didn't.

When Temporal launched, a lot of people had the same reaction: "We have queues and retries. We don't need this." (Temporal's own blog addressed this directly.) That reaction made sense. Queues solve queue problems and they do it well. What Temporal gave you was something different: a named execution context that survives a server restart and picks up from its last checkpoint. Not a better queue. A different abstraction entirely. If you built with it, you couldn't imagine going back.

At Ably we've been able to make a transformational change in how we build SDKs as a result of what's now possible with LLMs. In this post, I explain how.