{"slug": "why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough", "title": "Why AI agents need a durable session layer - and why HTTP isn't enough", "summary": "Ably CEO Matt O'Riordan argues that HTTP's request-response model is insufficient for AI agents that run for minutes, citing connection drops, lack of bidirectional communication, and state synchronization issues. Ably's AI Transport SDK provides a durable session layer to address these problems, enabling session recovery and user steering mid-task.", "body_md": "HTTP works fine for a chatbot that responds in seconds. Add token streaming, and it mostly still works. But once an agent starts doing things that take real time, reasoning across multiple tool calls, spawning sub-agents, running for minutes instead of milliseconds, the UX starts to falter.\n\nThe connection drops while the agent is mid-thought. The user switches tabs, comes back five minutes later, and the session is gone. The agent finishes its work, but the client has already moved on. The user wants to interrupt or redirect it, and HTTP can't support any of that, because it's a one-way street.\n\nThis is the transport problem sitting underneath every AI UX complaint you've heard. It's the problem Matt O'Riordan, co-founder and CEO of Ably, explored in a [ New Stack Makers interview](https://youtu.be/SDzbyVvho78?si=X4iVvPJ-FBGB1TE9). It's also the problem that led Ably to build AI Transport, a durable session layer purpose-built for agent-to-human communication.\n\n**Key takeaways**\n\n- HTTP's request-response model breaks when agents run for minutes, not milliseconds: connections drop, sessions don't survive device switches, and users can't steer agents mid-task.\n- A durable session layer sits between the agent and the user, handling connection recovery, bidirectional communication, and state continuity, independently of what the agent does on the backend.\n- Decoupling the agent from the client via pub/sub means either party can disconnect and reconnect without losing the session, with no custom Redis buffer required.\n- The\n[AI Transport SDK](https://ably.com/docs/ai-transport/getting-started/core-sdk)adds durability in a few lines of code, with no changes to the underlying application architecture.\n\n## From request-response to sessions that run for minutes\n\nEarly AI interactions were simple: send a prompt, get a completion, move on. HTTP handles that fine. The statefulness lives in a database somewhere; the transport layer stays stateless by design.\n\nModern agents are different in kind, not just in scale. They reason, plan, execute multi-step tool calls, and coordinate with other agents. A research agent might run for several minutes. A customer support agent might hand off to a human supervisor, then hand back. An agent completing a background task might finish while the user is on a different device entirely.\n\nThat shift in duration and complexity creates three problems HTTP was never designed to handle.\n\n**Connection reliability.** The longer an agent runs, the higher the probability that the connection drops, on the client side, the server side, or anywhere in between. Inference providers add another point of failure here too: outages and latency spikes on the model side are outside your control, on top of whatever happens to the connection itself. When your agent crashes mid-reasoning, you need infrastructure that handles the failure without losing session state. HTTP provides no recovery mechanism once the connection is gone.\n\n**Bidirectional communication.** Users want to interrupt, redirect, and send new instructions while an agent is still processing the previous ones, what practitioners call \"double texting.\" HTTP is unidirectional: you send a request and wait for a response. There's no way to inject a signal mid-stream, steer what the agent is doing, or tell it to stop. One team disabled user input entirely during agent responses because there was no reliable way to handle it.\n\n**State synchronization.** In the traditional model, the user sends their current state to the agent with the request. When agents run for minutes, that state snapshot is already stale before the agent finishes reasoning. The agent ends up operating on a view of the world that no longer exists.\n\n**What \"durable sessions\" actually means**\n\nThe word \"durability\" has become common in AI infrastructure, and it covers distinct problems at different layers of the stack.\n\nDurable memory ensures agents remember past conversations. Durable execution, the category [Temporal has built around](https://ably.com/blog/temporal-durable-execution-durable-sessions), ensures multi-step backend workflows survive crashes through event sourcing and idempotent retries. Both are well-understood categories with strong existing solutions.\n\nDurable sessions is the third category, and it's been the underserved one. It sits between the agent and the user: not inside the agent's memory, not in the backend orchestration, but in the transport layer where the session actually takes place.\n\nA [durable session](https://ably.com/blog/durable-ai-infrastructure-sessions-streams-transports-ecosystem) is a persistent, addressable session between agents and users that outlives any single connection, device, or participant. Connections break. Devices switch. Agents crash. Humans take over from AI. A durable session isn't just one of these things surviving in isolation. It's the layer that handles all of them together: a stateful medium through which agents and humans interact, staying in sync automatically through network drops, tab switches, device changes, and handoffs.\n\nIt's worth being precise about what durable sessions isn't, since the terminology overlaps with adjacent concepts. Matt draws a clear distinction between durable sessions and durable streams. Durable streams handle one layer: making sure token streams, messages, and tool calls are reliably delivered. A full durable session covers more ground:\n\n**Presence**: knowing which devices are online and which agents are active or crashed** Collaborative state**: shared objects between client and agent that stay in sync (this piece of AI Transport is still maturing)** Push notifications:**reaching the user when they've gone offline** Cold reconnection:**resuming a conversation from scratch after hours or days\n\nThe analogy Matt uses maps the categories clearly: durable execution makes the backend crash-proof, durable sessions makes the user experience crash-proof. They sit on opposite sides of the agent and complement each other.\n\n**The architectural pattern: decoupled pub/sub**\n\nThe core technical insight behind AI Transport is decoupling. In the standard pattern, client and agent are tightly bound over HTTP: the client sends a request, the agent processes it, and replies directly back over the same connection. If either party drops, the connection is gone, and so is the session.\n\nAI Transport introduces a pub/sub session layer between them. The client still sends its initial request to the agent over HTTP, so there's no architecture change required for the agent or the existing application logic. Instead of replying directly over HTTP, the agent publishes its responses to a durable channel, and the client subscribes to that channel to receive updates asynchronously.\n\nThat decoupling changes the failure characteristics fundamentally:\n\n- Agents can crash and republish with the same message identifier, since immutable message stores handle deduplication automatically.\n- Clients can disconnect and reconnect at any point, rehydrating their state from the channel's durable storage.\n- Multiple agents can publish to the same session independently, enabling multi-agent coordination without extra orchestration at the application layer.\n- Guaranteed ordering means tokens, tool calls, and messages arrive in the right sequence, regardless of what happens at either end.\n\nThe design constraint Matt describes for AI Transport was that it had to be addable in under an hour, with no fundamental architecture changes. The [Vercel AI SDK integration](https://ably.com/docs/ai-transport/getting-started/vercel-ai-sdk) gets there with a few lines of code: the existing framework keeps working as-is, while the transport layer underneath becomes durable.\n\nOne tradeoff to understand: AI Transport is scoped to the agent-to-user session, not to backend agent-to-agent orchestration. If the problem you're solving is coordinating a fleet of backend agents rather than keeping a human's session alive, this isn't the layer for that (more on that below).\n\n**Where agent frameworks are heading**\n\nAgent frameworks are beginning to build transport plug-in points explicitly. Vercel designed a pluggable ChatTransport interface specifically for external transport providers. TanStack AI shipped a ConnectionAdapter for the same reason. Both teams recognized that reliable, stateful transport is a hard infrastructure problem, not one they want to solve inside the framework layer.\n\nThis suggests the durable session layer is on its way to becoming a standard component of the AI agent stack, alongside durable memory and durable execution. Frameworks handle orchestration and model interaction; the transport layer handles reliable, bidirectional, stateful communication between agents and humans. The separation of concerns is getting cleaner as the ecosystem matures.\n\nOn agent-to-agent communication, Ably draws a deliberate boundary. [AI Transport](https://ably.com/ai-transport) focuses on interactions that involve a human. Backend agent coordination, one agent spawning another, orchestrating workflows, is handled by protocols like A2A and tools like Temporal. A durable session layer matters once agents need to reach outside that boundary: to humans, to agents in other systems, or through any channel where a human is a participant.\n\n**Getting started with AI Transport**\n\nAI Transport is designed as a drop-in layer. The client keeps talking to the agent over HTTP. The agent keeps doing what it does. The only change is where the agent sends its responses: to a durable session, rather than directly back over the HTTP connection.\n\nThe result: multi-device session continuity, proper session resumption after disconnects, durable message storage, and bidirectional communication including interrupts and double texting today, with steering and full collaborative state support landing as those patterns mature, all without changing the application's fundamental architecture.\n\nAs Matt puts it: \"People should not have to think about pub/sub. They should work in the idioms they're working in in AI: I have a turn, I have a session, and I push stuff to the client.\"\n\n**Watch the****original conversation****on The New Stack Makers.****Explore the AI Transport****docs****.****See how the**__Vercel AI SDK integration__** works**.", "url": "https://wpnews.pro/news/why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough", "canonical_source": "https://ably.com/blog/why-ai-agents-need-a-durable-session-layer", "published_at": "2026-07-09 10:07:28+00:00", "updated_at": "2026-07-09 10:15:19.719298+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "ai-tools"], "entities": ["Ably", "Matt O'Riordan", "AI Transport SDK"], "alternates": {"html": "https://wpnews.pro/news/why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough", "markdown": "https://wpnews.pro/news/why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough.md", "text": "https://wpnews.pro/news/why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough.txt", "jsonld": "https://wpnews.pro/news/why-ai-agents-need-a-durable-session-layer-and-why-http-isn-t-enough.jsonld"}}