By ByteBot
Cloudflare shipped Workflows V2 and a new MIT-licensed Dynamic Workflows library on May 1. Most coverage led with the headline number: concurrent workflow capacity jumped from 4,500 to 50,000 — an 11x increase. That number matters, but it’s not the story. The story is that Cloudflare just made it structurally possible for each of your tenants to bring their own durable workflow code. For teams building AI agent platforms, that distinction changes the architecture entirely.
What Dynamic Workflows Actually Enables
Standard Cloudflare Workflows are static: you define one WorkflowEntrypoint class, and every instance of that workflow runs the same code. That works fine when you control all the logic. It breaks down the moment your users need to define their own automation steps.
Dynamic Workflows solves this with a Worker Loader pattern. A single Worker receives every create() call and routes it to the correct tenant’s code at runtime. The Workflows engine then dispatches run(event, step) back to that tenant-specific function — seconds, hours, or days later, depending on what the workflow requires. Workflow IDs, retries, sleep, and waitForEvent all work identically to standard Workflows. The only thing that changes is whose code runs.
The library is approximately 300 lines of TypeScript, MIT-licensed, and available on npm as @cloudflare/dynamic-workflows. Cloudflare ships it with an interactive browser playground: write a TenantWorkflow class, hit Run, and watch each step commit with live-streaming logs. That’s a deliberate choice — it shows developers exactly what dynamic execution looks like before they write a line of production code.
The use cases this unlocks are specific. SaaS platforms where each customer defines their own automation logic. CI/CD products where each user’s pipeline is a different workflow. And most significantly for 2026: AI agent frameworks where an agent generates its own durable execution plan as code, with every generated step independently retryable and human-approval gates via waitForEvent that pause indefinitely at no cost.
The V2 Architecture Changes That Matter
The scale numbers are real and worth understanding. Concurrent workflow instances went from 4,500 to 50,000. Starts per second per account went from 100 to 300. Queued instances per workflow doubled to 2 million. For multi-tenant platforms that were bumping against V1’s ceiling, these are meaningful unlocks, not incremental improvements.
More interesting than the raw capacity is the architectural shift to a deterministic step model. Each step in V2 is isolated, replayable, and idempotent. On failure, the engine resumes from the last committed step — it does not replay the entire workflow. Independent steps can run concurrently, enabling fan-out and fan-in patterns that are common in AI pipelines: send a prompt, trigger parallel tool calls, aggregate results, write the output. That pattern was possible in V1 but required careful handling; in V2 it is the intended execution model.
Pricing remains the same: CPU time, requests, and storage billed at Workers Standard rates. Idle workflows cost nothing because hibernation is free. That is a structural advantage over duration-based competitors that charge even when a workflow is waiting on a human to approve something.
Who Should Pay Attention
If you are building a SaaS platform on Cloudflare Workers where different customers need different automation, Dynamic Workflows is what you have been waiting for. The alternative was running separate Worker deployments per customer or writing a complex dispatch layer yourself. Now it is a 300-line library.
If you are building AI agents that generate and execute plans, this is the durable execution primitive that makes generated plans real. An agent can write a run(event, step) function as its plan, submit it via Dynamic Workflows, and get independent retries, hibernation, and human approval gates for free — all within the Workers runtime your agents are likely already using.
If you are on Temporal or Step Functions and have been watching Cloudflare’s developer platform mature, this is the release that closes the multi-tenant gap. Temporal has no native per-tenant dynamic code loading at the isolation level. Step Functions requires IaC and glue code that Workflows replaces with a simple binding. That does not mean you should migrate immediately — Temporal has years of production maturity and a larger ecosystem — but the architectural gap is narrowing faster than most expected.
What’s Coming Next
Cloudflare’s announcement post included a statement worth noting: every Workers binding is “heading for a dynamic counterpart.” That means dynamic Queues where each producer ships its own handler. Dynamic AI bindings where each tenant connects to their own model. Dynamic MCP servers where each tenant brings their own tools.
That is the multi-tenant agent platform architecture described in concrete infrastructure terms. Whether Cloudflare executes on that roadmap as stated is the question — but the direction is clear, and Dynamic Workflows is the first delivery on that promise.
Cloudflare Workflows V2 and Dynamic Workflows are available now. The library is on GitHub, the full announcement is on the Cloudflare blog, and the documentation is on the Cloudflare developer portal. For teams building multi-tenant agent platforms, the practical next step is running the playground example and evaluating whether the Worker Loader pattern fits your current dispatch logic.
