Durable Execution Solves Half the Problem

Durable execution is having its moment. Temporal raised $300M at a $5B valuation in February. AWS shipped Lambda durable functions, Cloudflare took Workflows to GA, Vercel launched its Workflow DevKit, and Inngest is building a first-party agent framework on top of event-driven step functions. LangGraph, Pydantic AI, and the OpenAI Agents SDK have all adopted durable execution as a first-class feature.

The pitch is compelling: journal every step of your agent’s work, so when something crashes (and with LLM calls, tool invocations, and human approvals in the loop, something always crashes), the workflow resumes exactly where it stopped. No repeated tool calls, no double-charged payments, no lost progress.

It works. And it solves exactly half the problem.

Durable execution keeps the compute alive. Durable transport keeps the result alive. A production agent stack needs both layers, and only one of them gets talked about.

Durability Ends at the Workflow Boundary

Durable execution makes your compute durable. Every step is journaled, every retry is automatic, every crash is recoverable. Inside the workflow, nothing is ever lost.

Then the workflow produces a result, and that result has to reach someone: a user’s browser, a mobile app, another agent. And at that boundary, all the durability guarantees evaporate.

Consider what actually happens when your durably-executed agent finishes a step:

1. The workflow emits output. Maybe to an SSE stream, maybe to Redis pub/sub, maybe to a webhook.
2. The user’s laptop lid is closed. Or their train went into a tunnel. Or their phone backgrounded the tab.
3. The message is gone. Not delayed. Gone.

Redis pub/sub is fire-and-forget: events published while a client is disconnected are lost permanently. SSE streams die with the connection and cannot replay what was missed. Webhooks fire once at whatever endpoint happened to be reachable. Your workflow engine will happily journal that it delivered the output. The journal is telling the truth about the send and nothing about the receive.

Here is the uncomfortable part: the user never experiences your execution. They experience your delivery. A workflow that survived three worker crashes and resumed flawlessly looks identical to a total failure if the answer never reaches the screen. From the user’s point of view, durability is a delivery property, not an execution property.

The Workarounds Prove the Point

The durable execution vendors know this. Temporal’s answer is Workflow Streams: a durable event channel hosted inside a workflow that clients consume by long-polling through the Update primitive. It is a genuinely clever design. It is also, as of mid-2026, in public preview, batches events on a 2-second default interval (tuned down to 100ms for AI streaming), and requires you to run the full apparatus to use it: the Temporal server or cloud, worker fleets, and an SSE bridge you write and operate yourself to actually reach a browser.

Step back and look at what got built there: a message broker, implemented inside a workflow engine, consumed by polling.

The realtime platforms have noticed the same gap from the other side. Ably now markets a durable sessions layer specifically for Temporal workflows. The diagnosis is correct. But bolting a proprietary realtime API with fan-out billing and 64 KiB message limits onto your workflow engine means adopting a second vendor-specific protocol to patch the first system’s blind spot.

There is a protocol that was designed for exactly this problem, and it has been running industrial infrastructure for twenty-five years.

Delivery Guarantees Belong in the Transport

MQTT was built for clients that disconnect constantly, on networks that fail routinely, where losing a message is not acceptable. Its primitives map one-to-one onto the durability gaps that workflow engines leave open:

The gap	The MQTT primitive
Client disconnects mid-stream	Persistent sessions: the broker queues messages while the subscriber is offline and delivers on reconnect
Client reconnects and needs current state	Retained messages: the last message on a topic is delivered instantly to any new subscriber
Message must arrive, exactly once if needed	QoS 1 and 2: broker-level acknowledgment and deduplication, per message
Output must reach many devices	Pub/sub fan-out: any number of clients subscribe to the same topic
Agent A must not read Agent B’s traffic	Broker-enforced ACLs: authorization on every publish and subscribe, below your application code

None of this is application logic you write. None of it requires a worker fleet. The broker is the durability layer for everything in flight.

What This Looks Like: Durable AI Responses Without a Workflow Cluster

@cloudsignal/ai-transport is a drop-in transport for the Vercel AI SDK that moves the response path from HTTP streaming to MQTT (here is how and why we built it). The client code does not change:

import { useChat } from '@ai-sdk/react';
import { CloudSignalChatTransport } from '@cloudsignal/ai-transport';

const { messages, sendMessage } = useChat({
  transport: new CloudSignalChatTransport({
    api: '/api/chat',
    authEndpoint: '/api/auth/mqtt',
    wssUrl: 'wss://connect.cloudsignal.app:18885/',
  }),
});

On the server, the HTTP POST only triggers generation and returns 202 immediately. The response itself travels over MQTT:

import { streamText } from 'ai';
import { publishStreamToMqtt } from '@cloudsignal/ai-transport/server';

export async function POST(request: Request) {
  const { chatId, messages, requestId } = await request.json();
  const mqttClient = await getServerMqttClient();

  const result = streamText({ model: anthropic('claude-sonnet-4-20250514'), messages });
  publishStreamToMqtt(mqttClient, chatId, result, { requestId }).catch(console.error);

  return Response.json({ status: 'streaming', chatId }, { status: 202 });
}

Tokens stream to chat/{chatId}/stream at QoS 0. The complete response is published to chat/{chatId}/complete as a retained message at QoS 1. That one line of architecture buys you the durability the user actually feels:

• Close the laptop mid-response? Reopen it, the broker delivers the retained complete message. Nothing to re-request, nothing to re-generate, no tokens re-billed.
• Same conversation on phone and desktop? Both subscribe to the same topic. Multi-device sync is free; it is just pub/sub.
• Server crashes mid-stream? The client’s stream timeout closes cleanly instead of hanging forever.
• Multi-tenant? Organization isolation and per-topic ACLs are enforced by the broker, so a bug in your application code cannot leak one tenant’s stream to another.

Notice what is not in this architecture: no workflow server, no worker fleet, no journal, no long-polling bridge. For a large class of agent workloads (streaming a response to a user, handing a task from one agent to another, pushing status to a dashboard), the fragile part was never the compute. It was the delivery. Make the delivery durable and the elaborate resume-and-replay machinery has nothing left to compensate for.

When You Do Need Both

To be clear about the boundary: if your agent runs multi-hour workflows with human approval steps, compensating transactions, and side effects that must never repeat, durable execution is the right tool for that half. Use it.

But pair it with a transport that carries its guarantees the rest of the way:

• The workflow publishes progress and results to MQTT topics instead of an in-workflow stream. Clients get them with QoS guarantees, offline queuing, and retained state, with no polling and no custom SSE bridge.
• Agent-to-agent handoffs go through the broker with QoS 1, so a downstream agent that is busy, redeploying, or rate-limited receives the task when it comes back, instead of the upstream agent needing retry choreography.
• Every hop is authorized by broker-level ACLs, which matters when autonomous agents are doing the publishing.

The stack that is emerging for production agents has two durable layers, not one: durable execution for state inside the workflow, durable transport for everything in flight. The industry has spent two years perfecting the first layer. The second one is standard MQTT, and it is already here.

---

CloudSignal is managed MQTT infrastructure for AI agents and real-time applications: QoS delivery guarantees, persistent sessions, retained messages, and broker-enforced access control, with zero ops. Start free and stream your first durable AI response in minutes.