Cloudflare’s Dynamic Workflows is one of the more important AI infrastructure releases of early May 2026, even if it looks niche at first glance. The reason is simple: many modern agent platforms want users, tenants, or even the agents themselves to generate workflow logic on the fly. Traditional workflow systems are not built for that.
Cloudflare announced Dynamic Workflows on May 1, 2026 as a way to bridge durable execution and dynamic deployment. In practical terms, it lets a platform route workflow creation and execution back to tenant-specific code instead of forcing every workflow to live inside one static deployment.
That may sound like an implementation detail. It is not. It solves one of the hard infrastructure problems behind AI agents, low-code builders, CI platforms, and multi-tenant developer products.
What Cloudflare Dynamic Workflows actually is
Dynamic Workflows is a Cloudflare library built on top of Dynamic Workers and Cloudflare Workflows. Its job is to let a single host worker route workflow creation and later workflow execution back to the right tenant’s code.
That matters because ordinary durable workflow systems usually assume the workflow code is part of the application deployment. One deployment, one workflow class, one static binding. That works if your company owns all the logic.
It breaks down if:
- each customer can ship their own workflow logic
- an AI agent writes a new durable plan for a specific task
- a low-code platform generates different workflow code per tenant
- a CI or developer platform needs per-repo workflow behavior
Cloudflare’s answer is to make durable execution dynamic the same way it already made compute dynamic with Dynamic Workers.
The core problem it solves
Before Dynamic Workflows, a platform could let tenants generate code, but durable execution still had a static assumption baked into the system. The workflow engine needed to know in advance which class to run.
That is fine for classic apps. It is a poor fit for the new agentic stack, where the workflow might be different for every tenant, every repository, every agent session, or every request.
Cloudflare’s release solves that mismatch. A host worker can accept a workflow creation request, tag it for the right tenant, and then have the workflow engine dispatch execution back to that same tenant-specific code later—even if the run resumes seconds, hours, or days afterward.
That is the real breakthrough. It lets platforms support durable tenant-defined logic without pretending every customer is running the same workflow.
How it works in practice
Cloudflare describes Dynamic Workflows as a small library, but the idea underneath it is larger. A “Worker Loader” can load tenant-specific modules dynamically and wrap the workflow binding so that each workflow instance is tagged and routed correctly.
When the workflow later resumes, Cloudflare’s runtime can dispatch the execution back into the right tenant environment. That means the workflow keeps the benefits of Cloudflare Workflows—retries, waiting, sleeping, pause and resume behavior, durable state—without forcing the platform to statically own every workflow definition.
Cloudflare is explicit that the heavy lifting happens underneath through Dynamic Workers. The runtime handles sandboxing, routing, caching, isolate reuse, and hibernation between steps. Dynamic Workflows is the developer-facing layer that makes those primitives usable for workflow code.
The company is also clear about the economic angle: idle tenants cost approximately nothing, while active tenants share hardware through isolate-level multi-tenancy. That is why Cloudflare argues a platform that once topped out at thousands of paying customers can now realistically aim for tens of millions.
Why this matters for AI agents
This release is especially relevant to AI agent platforms because agents increasingly need durable plans, not just one-shot tool calls.
An agent that writes code, waits for approval, resumes later, triggers follow-up actions, and survives failures is effectively running a workflow. The problem is that the workflow may not be known ahead of time. It may be generated during the task itself.
That is where Dynamic Workflows becomes strategically useful. Cloudflare says the release lets agent-written plans become first-class Cloudflare Workflows. In other words, an agent can generate a run(event, step) plan, and the platform can execute it with proper durability behind it.
For agent builders, that means:
- long-running plans can survive crashes and hibernation
- workflow steps can be retried independently
- approval steps can wait indefinitely without awkward infrastructure hacks
- each tenant or user can have their own workflow logic without a separate deployment model
That is a much better fit for real agent systems than a fragile sequence of ad hoc tool calls.
Why it also matters for platforms beyond AI
Even though the AI angle is strong, Dynamic Workflows is not only for agent builders.
Cloudflare explicitly points to several adjacent use cases:
- workflow builders and low-code tools where users supply their own logic
- CI/CD platforms where every repository has its own pipeline behavior
- multi-tenant application platforms that want to let customers run their own background jobs
- SDKs and frameworks where user-defined durable execution is part of the product
This is why the release has broader commercial significance than the name suggests. It is an infrastructure primitive for any product that wants to combine shared platform control with tenant-specific execution.
How Dynamic Workflows fits Cloudflare’s bigger strategy
Dynamic Workflows is part of a larger Cloudflare push to become an agent infrastructure layer, not just an edge compute vendor. Dynamic Workers, Durable Object Facets, Artifacts, Workflows, Sandboxes, MCP tooling, and the Agents SDK all point in the same direction.
Cloudflare’s pitch is that the modern “agentic cloud” needs more than model access. It needs runtimes, durable state, sandboxed execution, source control primitives, waiting and retry behavior, and economics that work for huge multi-tenant systems.
Dynamic Workflows fits that stack neatly. It gives Cloudflare a stronger answer to a question more platforms are now asking: How do we let users or agents generate their own long-running logic without building a fragile orchestration system from scratch?
The practical takeaway
If you are building a product where your users bring the workflow logic, Cloudflare Dynamic Workflows is worth understanding right now. It removes a major mismatch between dynamic code generation and durable execution.
That makes it especially relevant for AI agent platforms, developer tools, CI systems, and low-code products. Instead of forcing everything through one static workflow deployment, you can let each tenant, repo, or agent own its own plan while the platform still owns routing, sandboxing, and durable execution.
That is why this release matters. It is not just a Cloudflare library announcement. It is part of a larger shift in infrastructure design: platforms increasingly need to host other people’s durable logic, not just their own.
Dynamic Workflows is Cloudflare’s answer to that problem, and for a growing class of AI-native products, it is a very timely one.