Pi Durable, Cloudflare Workflows, or Vercel Workflow?

An agent researches a support request, drafts a reply, and waits for someone to approve sending it. The process needs to survive a restart during any of those stages.

You can build that with Pi Durable, Cloudflare Workflows, or Vercel’s Workflow SDK. The choice affects where state lives and who restarts the work. It also affects how much of the agent loop you need to build.

These tools cover different layers. An agent harness runs model turns and tools. A workflow runtime records durable steps and arranges for unfinished work to continue. An application can use both.

I haven’t run a performance comparison between these platforms. This guide compares their documented recovery models, checked in October 2026, using the same proposed support-reply task.

Start by separating the agent from its job

Our task has an ordinary business process around the model:

1. Load the support request and its account information.
2. Ask a model to investigate and draft a reply.
3. Store the exact draft for approval.
4. Wait for an authorized decision.
5. Send the approved reply and record the provider’s receipt.

Inside the investigation, the model might make several tool calls. It could read an order, retrieve a policy, and ask for another lookup before producing the draft.

The business process and the agent loop need different checkpoints. Saving only the final draft loses the unfinished investigation. Saving only the conversation leaves you to build the approval and delivery process around it.

Pi Durable gives you an agent harness

Pi Durable’s README describes a library that persists conversation and execution state, including model requests and tool calls. You supply the model configuration and tools.

The storage choices include local SQLite and JSONL, plus a Cloudflare Durable Object SQLite adapter. Pi Durable can therefore be part of a hosted application as well as a local Node program.

For the support task, it can recover the agent’s unfinished investigation from its saved state. Your application still decides how new requests arrive, how a worker gets restarted, and who can read the draft.

The Pi Durable tutorial builds a local SQLite example. That is a useful starting point when you want to control the harness and its storage directly.

If you choose local storage, keep the database on persistent storage and arrange backups. A new process needs access to the previous database. Replacing an ephemeral container with an empty filesystem gives it nothing to resume.

The shipped Node SQLite adapter documents a distinction between process-crash recovery and the newest commits surviving host power loss. The library also expects one process to own a storage at a time. Account for those conditions before running multiple replicas against one file.

Cloudflare Workflows manages durable steps

Cloudflare Workflows runs a business process as persistent steps. Your code uses step.do for work whose result needs to survive a retry or restart. The platform manages execution and step state.

For our task, the request lookup and draft generation can be separate steps. An approval can use step.waitForEvent, while an authenticated route sends the corresponding event to that instance.

That gives the application a durable waiting point. You still validate that the decision belongs to the right draft and came from someone allowed to approve it.

Cloudflare also publishes a durable AI agent guide. This matters because you don’t have to put an entire opaque investigation inside one step. You can choose finer boundaries around model and tool work, following the supported integration.

Those boundaries determine what repeats. If a step includes a model call, several lookups, and an unprotected email send, retrying that step can repeat more than you intended.

Cloudflare’s rules of Workflows explicitly advise making API and binding calls idempotent. A recorded successful step and a remote request that completed just before a crash are different situations.

Workflow SDK separates workflow code and step code

Vercel’s Workflow SDK uses "use workflow" and "use step" directives. Workflow code coordinates the process; step functions perform work such as fetching data or calling a model.

Its persistence and execution backend is called a World. The Vercel World supplies the managed deployment path. The project also documents self-hosting with a Postgres backend and implementing a custom World.

For our support reply, a workflow can coordinate draft generation and the eventual send. A hook can suspend work until an external decision arrives.

The hook documentation makes the authorization boundary explicit: authenticate and authorize the caller before resuming a hook. Possession of a hook token alone doesn’t prove the person can approve that operation.

Running on a managed backend moves infrastructure work to the provider. Self-hosting moves it back to you, including storage availability and the components that deliver queued work. Choose that trade-off deliberately, rather than assuming a TypeScript package comes with production infrastructure.

Compare the operational responsibilities

This table describes responsibilities, rather than identical features with different names. A Pi harness can live inside a larger application process, and a workflow can coordinate an agent implemented with a separate library.

Choose using the failure you need to recover

For a local agent that reads repositories and runs tools, I would start by asking whether the harness can recover the exact unfinished turn. Pi Durable is directly concerned with that problem. The surrounding application may only need a supervisor and persistent storage.

For an application already using Cloudflare bindings, I would evaluate Workflows around a concrete job. A request that needs several waits and an approval maps naturally to durable steps and events. Confirm the runtime restrictions and how your model library fits before choosing the step boundaries.

For an application already on Vercel, I would evaluate Workflow SDK with its managed World. If self-hosting is a requirement, test the supported backend before committing the whole process to it.

The email boundary needs a separate test on every option. Let the provider accept a fake message, stop the worker before its receipt is saved, then resume the same logical operation. Check whether the provider sees one send or two.

Also stop while approval is pending. Change the draft afterward and verify that the old approval cannot authorize the new content. Cancel the request and try delivering the old approval event again.

Those tests answer more about your application than a generic claim that its workflow is durable. Start with the smallest support request that exercises each boundary, and keep its saved state available when you replace the worker.

Want me to talk about your product? You can sponsor this site.