You wrap the tool call in a retry. Then you add a table, because retrying the first step after the ninth one failed is worse than failing. Then a scheduler, because the job has to start on its own at seven in the morning. Then somewhere to write down what happened overnight, because somebody asked why Tuesday’s report was wrong and nobody could say. Six weeks in, almost none of the code you maintain has anything to do with the agent. You set out to build the most novel thing in the building and ended up hand-rolling the most ordinary.

Nobody writes the control panel from scratch

Think of a pumping station. A grey cabinet on the wall runs the pumps to a timetable, and when one of them fails it starts that pump again rather than the whole night. An operator can send an instruction into it without stopping what is already running, and read the level in the reservoir without interrupting anything. Everything it did is written down with times against it. The cabinet is dull, and it is finished: nobody specifies a new one from first principles, because running machinery unattended has been solved to the point of tedium.

A durable workflow runtime is that cabinet, for software. It persists the history of what has already happened, so a job that dies is resumed instead of replayed. It retries the piece that failed instead of the whole run. It gives every long-lived process a stable identity, so you can find it again tomorrow.

Put an agent inside it and the agentic patterns stay yours to compose, while persistence, retry and recovery belong to the runtime. Connections to MCP servers become part of the application lifecycle rather than something you reopen by hand. A map-reduce job that dies on a transient error picks up from its checkpoint instead of replaying every call it already paid for. The interface the agent sees does not change at all: suspend, resume and recover happen underneath it.

Recovery you cannot see is not recovery

Borrowing the engine buys a second thing, and that is the one deciding whether you can operate the system at all. The runtime keeps the execution history; a tracing layer turns the request, the workflow, each activity and each model call into nested spans. Recovery stops being a claim and becomes something with a shape you can look at.

A deep-research job completes twenty web searches and fails on the synthesis. The runtime keeps the earlier results and retries only the synthesis, and the trace shows inputs, tokens, latency, retries, and which version of the prompt was actually applied. Load prompts by version from a registry, with a local fallback, and you can compare two versions against real traffic without redeploying the worker.

There is a bill attached to getting this wrong. If the model client retries on its own while the runtime is also retrying, you multiply calls and cost for nothing, so the client’s retries get switched off and the runtime holds the only authority. The two halves need each other as well: durability without traces cannot explain a recovery, and traces without an execution history cannot tell you the effects were right.

What you borrow, and what stays yours

The same engine covers the case where nobody is watching. Give each role a workflow with a stable identity, and schedules deliver the periodic nudge that would otherwise be a cron entry and a sleeping thread. Signals deliver a command or a piece of human feedback reliably. Queries read state without interrupting the run. Actions exposed as MCP tools can be implemented as workflows or activities, which means they inherit timeouts, retries and an auditable history without anybody writing that code twice.

What you borrow stops short of correctness. A composable workflow is not automatically an idempotent one, and restarting a piece that already sent something outward sends it twice; that guarantee is still yours to build. Reasoning that never repeats itself belongs inside an activity, not in the workflow body that has to replay identically. A signal that changes behaviour still needs a verifiable trail behind it.

That is the trade, and it is the same one as buying the platform instead of building it: you take somebody else’s shape in exchange for the parts you would otherwise write badly. Here the shape is generous, because durability is not where your system is interesting.

The most reliable part of your agent should be the part you did not write.