Generated by Codex with GPT-5

What happened

Cloudflare’s official engineering blog published Introducing Dynamic Workflows: durable execution that follows the tenant, a post about making durable workflow execution work when the workflow code is not known at deploy time.

The problem is a real platform boundary. Cloudflare Workflows already gives developers a durable execution engine: a workflow can survive process eviction, sleep for long periods, wait for external events, retry individual steps, and resume after failures. That model works cleanly when the workflow class is part of the platform owner’s deployment. It breaks down for modern multi-tenant products where every customer, repository, agent, or session may bring different code.

Dynamic Workflows closes that gap by combining Cloudflare’s durable workflow runtime with Dynamic Workers. The platform still owns a stable Worker Loader, but the code that actually implements run(event, step) can be loaded dynamically for each tenant. A tenant can call what looks like a normal WORKFLOWS.create() binding, while the loader wraps that binding, adds routing metadata, and sends the real workflow creation request to Cloudflare’s Workflows engine.

The key design is an envelope-and-dispatch pattern. On the way in, the wrapper records metadata such as the tenant ID alongside the workflow parameters. The Workflows engine persists that payload as usual. Later, when the engine wakes the workflow and calls into the registered workflow class, the Dynamic Workflows entrypoint unwraps the metadata and asks the platform’s loader callback to fetch the right tenant code. The execution then lands in the tenant’s own WorkflowEntrypoint, even if that code was never part of the original deployment.

That mechanism is intentionally small. The library does not replace Workflows, build a new scheduler, or invent a separate durability model. It adds a routing layer at the two places where static bindings would otherwise force a single workflow class: outbound creation and inbound execution. Everything else, including workflow IDs, status checks, pause and resume behavior, retries, sleeps, and event waits, remains handled by the existing engine.

This matters because tenant-provided code has to cross isolation boundaries cleanly. The post calls out that a raw workflow binding cannot simply be passed into a Dynamic Worker as a serializable object. Dynamic Workflows exposes an RPC-style binding class that the runtime can specialize with per-tenant metadata. That keeps the tenant API familiar while giving the platform a controlled place to attach routing, policy, logging, and loading behavior.

Why it matters

The interesting engineering move is that Cloudflare separates durable control flow from static deployment. Traditional workflow systems usually assume a fixed catalog of workflow definitions. Dynamic Workflows treats the workflow definition as something that can be supplied at runtime by a tenant and still run under the same durability guarantees as first-party code.

That changes the shape of several platform designs. A SaaS product can let customers write their own long-running automation without deploying one worker per customer. An agent platform can let a model generate a durable plan as code, then hand that code to the platform to execute step by step, with retries, hibernation, and human approvals represented as normal workflow mechanics. A CI/CD platform can treat each repository’s pipeline file as the workflow definition, dispatching it dynamically when a pull request arrives.

The CI example is the clearest systems story. A conventional CI run spends a lot of time on orchestration overhead: allocate a machine, pull an image, clone a repository, install dependencies, then finally run the useful work. Cloudflare’s proposed stack makes the repo a distributed artifact, forks it cheaply per run, starts lightweight steps in isolates where that is enough, uses heavier sandboxes only where needed, and lets the workflow hibernate while waiting for approval. The compute moves to the data and the durable workflow holds the run together.

The implementation choices matter because they preserve both isolation and economics. The platform can load code lazily, cache it while active, evict it when idle, and reload it on the next durable step. That lets a service support a large number of distinct tenants without keeping one process, container, scheduler, or deployment active for each. The tenant experiences a normal workflow API, but the platform retains control over where the code comes from, how it is authorized, which region it runs in, and how it is observed.

There is also a useful caution in the metadata design. The routing metadata survives in workflow state because the engine must know where to resume later, but that metadata is not a security boundary. It should identify where to dispatch, not prove who is allowed to run. That distinction is important for any platform adopting this pattern: dynamic execution needs a routing layer, an authorization layer, and an isolation layer, and those concerns should not be collapsed into one convenient envelope.

The broader AI infrastructure angle is strong. Many agent systems are moving from prompt-only orchestration toward code-shaped plans: the agent writes a procedure, the platform runs it, and durable state lets it continue across failures or long waits. Dynamic Workflows gives that direction a concrete cloud primitive. Instead of asking an agent runtime to remember every pending step itself, the agent can produce workflow code and rely on the platform’s durability machinery to handle retries, waiting, recovery, and state.

Takeaway

Cloudflare’s post is less about a single library than about a platform abstraction: make tenant-specific code dynamic, but keep durability, scheduling, and execution boundaries platform-owned. The new glue is useful because it routes workflow creation and resumption back to the right code without making every tenant a separate deployment.

For engineering teams building extensible platforms, the lesson is to isolate the stable control plane from the user-defined execution plane. The platform should own loading, persistence, routing, policy, observability, and recovery. The tenant should own the business logic. When that boundary is clean, a system can offer customization that feels like each user has their own runtime while preserving the operational efficiency of shared infrastructure.