On May 1, Cloudflare shipped Dynamic Workflows, an MIT-licensed library that lets a single Workers deployment run a different workflow definition for every tenant. One account can drive 50,000 concurrent workflow instances, each executing user-supplied TypeScript loaded at request time. Five years of durable-execution orthodoxy assumed the opposite - that workflow code was something you compiled, bundled, and deployed once. That assumption is what makes Temporal feel heavy when you try to apply it to AI agents.

The release is small - the library itself is about 300 lines of TypeScript - but it sits on top of Dynamic Workers, which went into open beta in March and is the actually interesting primitive. Dynamic Workers gives you a V8 isolate you can boot in single-digit milliseconds, hand a string of JavaScript, run, and throw away. Dynamic Workflows is the durable-execution wrapper around that primitive. Together they target a workload that none of the existing durable engines handle cleanly: the multi-tenant AI agent platform.

The static-code assumption

Durable execution engines - Temporal, Inngest, DBOS, the original Cloudflare Workflows - all share an architectural choice: the workflow function is part of the worker image. You write a run(event, step) function, deploy it, and the engine schedules replays of that function against persisted history. If a step fails, the engine retries it; if the machine dies, another worker picks up the history and resumes. The contract works because every worker has the same code.

That assumption is fine when you own the workflows. It breaks the moment you let your users write them. Cloudflare's own framing is direct:

Say you're building an app platform where the AI writes TypeScript for every tenant... In every one of these cases, the workflow is different for every tenant, every agent, every request.

You can paper over this with Temporal namespaces and a thousand task queues, but you end up running one worker pool per tenant - or smuggling tenant code through a sandboxed eval inside a shared worker, which is exactly the security hole Dynamic Workers is built to close.

How dispatch actually works

The mechanic is worth understanding because it explains both the power and the lock-in. A platform registers a single DynamicWorkflow class in wrangler.jsonc. When a tenant kicks off a workflow, the platform calls dispatchWorkflow() with a pointer to the tenant's code bundle. The engine stores the pointer with the workflow's history. Every time the engine needs to replay a step - immediately, an hour later, three days later after hibernation - it loads the tenant's code into a fresh isolate via the Worker Loader and dispatches run(event, step) against it.

The Worker Loader call underneath looks like this:

let worker = env.LOADER.load({
  compatibilityDate: "2026-03-01",
  mainModule: "agent.js",
  modules: { "agent.js": tenantCode },
  env: { CHAT_ROOM: chatRoomRpcStub },
  globalOutbound: null,
});
await worker.getEntrypoint().myAgent(param);

Boot is measured in milliseconds and the isolate uses a few megabytes. Compare that to a container cold start - hundreds of milliseconds and tens to hundreds of megabytes - and the math for a platform with millions of tenants changes shape. Cloudflare's pitch puts it bluntly:

The unit economics of running a platform like this are, frankly, absurd.

Hyperbole, but the numbers behind it are not. The fact that the library is envelope-and-unwrap glue around Dynamic Workers - InfoQ's phrase, not mine - is the real product story. Workflow durability was already a solved problem inside Cloudflare. The hard part was making per-tenant code execution cheap enough that you could offer durable execution as a primitive in a SaaS platform without putting the price into the four-figure range.

What this competes with

Temporal is the obvious comparison, and Cloudflare's engineers are careful with the wording: Temporal doesn't offer the dynamic per-tenant code loading at the isolation level that Dynamic Workflows enables. That is true and narrow. What Temporal does offer - and Dynamic Workflows does not, today - is a mature self-hostable history store, namespaces with independent retention and rate limiting, cross-region replication, and a track record of running real businesses for the better part of a decade. If you are building a single workflow engine for a known set of internal workflows, Temporal is still the calmer choice.

Inngest is the closer functional analogue - a hosted durable-execution platform pitched at application developers - but it shares the static-code assumption. Each Inngest function is part of your deploy. You can fan out by tenant ID inside a function, but you cannot ship a different function body per tenant without doing your own sandbox dance.

AWS Step Functions allows dynamic state-machine definitions but routes each task to a pre-deployed Lambda - the dynamism is in the wiring, not in the code. DBOS, the Postgres-native durable execution engine, leans on Postgres schemas or separate clusters for tenancy, which is plenty for SaaS with hundreds of customers and uncomfortable past that.

The honest read is that Cloudflare is not so much beating these systems as opening a workload they were not built for. AI coding platforms - the v0s, the Lovables, the Bolts - are the obvious first wave. CI runners that need to checkpoint long-running graphs across user-provided steps are another. Anything where the workflow itself is the product, not the substrate.

The cost of buying in

Dynamic Workflows is MIT-licensed, which sounds reassuring until you trace what it actually depends on. The library is portable only in the trivial sense. The substrate - Worker Loader, V8-isolate sandboxing, the Workflows runtime, Durable Objects backing the history store, MPK and Spectre mitigations at the hardware level - is Cloudflare-only. There is no other vendor running this stack today and no obvious path to a self-hosted workerd build that reproduces the security guarantees.

The security work is worth dwelling on because it is the part everyone underestimates. Running tenant-supplied JavaScript in a shared process is one of the canonical don't do this patterns. Cloudflare's mitigation stack is layered: a second-layer sandbox on top of V8, hardware-enforced Memory Protection Keys for memory isolation, in-house Spectre defenses, and a deployment story that patches V8 CVEs within hours of disclosure. None of that is trivial to replicate. The flip side is that you are trusting Cloudflare's runtime team to keep the seal tight forever. For some workloads that trade is fine; for regulated workloads it is the whole conversation.

Pricing during the open beta is $0.002 per unique Worker loaded per day, currently waived. That is the dial to watch. If a heavy tenant runs hundreds of distinct code bundles through the day - exactly what happens when an AI agent platform regenerates code on every prompt - the per-day-per-bundle pricing starts to look interesting in both directions.

What's missing

Three things, all openly acknowledged or visible from the docs.

  • Cross-tenant observability is still a work in progress. The workflow viewer shows you instances, but per-tenant aggregate views and structured cross-tenant tracing are not there. Most platform teams will want OpenTelemetry exporters before going to production.
  • There is no story for migrating in-flight workflows when the tenant's code changes. The engine pins each instance to the bundle it was created with, which is the right default for correctness, but it means a long-running tenant workflow can outlive several rounds of code revisions. Schemas drift; the engine does not help you.
  • The 50,000 concurrent and 300 new-instances-per-second-per-account caps are generous for now but will bite the first serious platform. These are quotas, not architectural limits, and Cloudflare will negotiate. Plan accordingly.

Why this is the more interesting half of 2026

The Temporal-style durable-execution model won the argument three years ago. The question for the next few years is what gets built on top of it. Static workflow code was a fine assumption when the workflows were process payments or sync data to a warehouse - things a platform team writes once and runs forever. It is the wrong assumption when the workflow itself is the dynamic content the platform exists to host.

Dynamic Workflows is the first credible engine that treats per-tenant code as a first-class input rather than an integration burden. Whether the abstraction holds up under real production load is the next thing to find out. The piece that matters - that durable execution can be a primitive you offer to your users, not just a primitive you use yourself - is no longer hypothetical.

How to try it

Install @cloudflare/dynamic-workflows on a Workers Paid account. Read the Worker Loader docs first - the durable layer is a thin wrapper, and you will understand the failure modes much faster if you have built something on Dynamic Workers directly. Start with a toy: a workflow that loads a tenant-supplied function, runs it as the first step, then waits for a webhook before continuing. The waitForEvent API added at Workflows GA pairs naturally with this pattern and will tell you quickly whether the model fits your platform.

The thing worth deciding now: are the workflows your users will run your code or their code? Until last week, the answer determined whether you could use durable execution at all. It still does. The answers just changed places.