I spent the week before last at AI Engineer Europe. Three different hallway conversations, three different parts of the stack, one word kept coming up: durable. Durable execution. Durable agents. Durable sessions.

You know the Ballmer clip. Pacing a stage, sweating, chanting “developers, developers, developers” until his voice gave out. AI infrastructure is having its durable, durable, durable version of that moment.

I came home and tried to map what I’d heard. Here’s what I got wrong the first time, and what I think it tells us about how categories actually form in 2026.

My first attempt looked tidy. Concentric rings. Durable Execution at the base, Durable Workflows on top, Durable Agents on top of that. Each a superset of the last. Clean story, good diagram.

Then I checked.

Temporal doesn’t describe durable agents as a superset of durable execution. They describe it as an application of execution. Convex uses Durable Workflows as their central term and doesn’t sit “above” execution, they sit alongside it with a different worldview. Vercel ships a DurableAgent class and a Workflow Development Kit as separate products, and frames them as complementary, not layered.

The tidy story was wrong. The messier truth is that execution, workflows, and agents are three names different vendors use for the same problem: how do you make the backend reliable enough that AI can run in production. Not a hierarchy. A cluster.

I redid the map.

Three clusters. Inside the agent, there’s memory (Mem0, Zep, Letta lead here). Behind the agent, there’s the backend durability cluster I just described (Temporal, AWS Lambda Durable Functions, Restate, Inngest Durable Functions, Vercel Workflow Development Kit, Convex, Cloudflare Durable Objects). In front of the agent, there’s a layered session stack: Durable Streams at the protocol level, Durable Transports as the adapter into agent frameworks, Durable Sessions as the whole thing the user experiences.

The full map, with every vendor placed and the three problem areas walked through properly, is on the Ably blog. Go read that if you want the complete picture. This post is about the making of the map, not the map itself.

The thing I almost got wrong about ElectricSQL is that I was going to treat them as competition.

They’re not. They’re a small team putting serious effort into naming this category. James Arthur’s January post on Durable Sessions landed with 75K views on X. Kyle Mathews, their CPO, built Gatsby and has the kind of reach that moves developer conversations. They open-sourced the Durable Streams protocol. Others are adopting it.

The smart move when someone else is doing the naming work well is to credit them and build alongside. ElectricSQL is coming from the database angle (state sync, Postgres replication, structured state over resumable HTTP). Ably and our new AI Transport product is coming from the realtime angle (WebSockets, presence, bidirectional stateful connections). Same destination, different histories. When that happens, the thing both companies have arrived at is probably real.

Ably has been building this layer for a decade. We called it channels. We never called it durable streams, because “durable” wasn’t doing any work as a marketing word yet. Now it is, and the industry is catching up to vocabulary we’ve been quietly operating under.

There’s a temptation, when that happens, to say “we invented this” and try to own the name. It’s almost always a mistake. Categories get defined in public, through a combination of products shipped, protocols open-sourced, and arguments had at conferences. The companies that win are the ones that did the work and were generous about the framing. Temporal did that with Durable Execution. AWS Lambda Durable Functions validated it. That’s the playbook.

I’d rather be on a map than own one.

A durable session reflects the conversation, not the log of what happened.

The stream-layer companies are building the log. The session is bigger than that. It covers reliable streaming (tokens that survive disconnects, mutable messages, compacted history), session continuity (multi-device, human handover, push notifications for cold sessions), and agent visibility (presence, bidirectional control, routing to live agents).

The full breakdown with diagrams is on the Ably blog. The reason I’m flagging it here is that most of the public conversation so far has focused on the stream layer, because streams are the easiest to reason about. The session is where the actual developer problem lives, and it’s why we think this category needs the broader definition.

Mapping an industry while it’s forming is embarrassing work. You get the structure wrong. You mis-categorise companies you respect. You have to double back and rewrite. But the alternative is to wait until someone else has done it, and that’s worse. The map is always provisional. What matters is that the map exists at all.

The full version, with the vendor breakdown, the diagrams, and the three-problem-area walkthrough, is on the Ably blog. The living version, which I’ll keep updating, goes up at durablesessions.ai.

If you think I’ve got your company in the wrong cluster, tell me. I’ll redraw it.