Rearchitecting the Workflows control plane for the agentic era (opens in new tab)

Workflows was originally designed for human-paced events, but autonomous agents now create and manage workflow instances at machine speed. To support this shift, the platform increased its limits substantially and redesigned its control plane for horizontal scalability. The new architecture replaces V1’s account-level bottleneck with distributed components while preserving durable execution, retries, and human-in-the-loop pauses.

The Shift to Agent-Driven Workloads

• Workflows initially handled events such as sign-ups and purchases, typically requiring only one instance per person.
• Persistent agents can operate for hours or days and launch dozens of workflows from a single session.
• Concurrent agents can create thousands of workflow instances within seconds.
• Workflows also serve as durable execution harnesses for agent loops, maintaining progress across failures and supporting asynchronous work.

Higher Workflows Capacity

The platform now supports:

• 50,000 concurrent instances, up from 4,500.
• 300 instance creations per second per account, up from 100.
• 2 million queued instances per workflow, up from 1 million.

These increases were driven by observed usage patterns and a redesign of the control plane.

V1: A Single Account-Level Bottleneck

• Each workflow consists of durable, independently retryable steps that can run tasks, wait for events, or sleep until a scheduled time.
• SQLite-backed Durable Objects provide execution, coordination, and storage.
• An Engine Durable Object is created for each workflow instance and handles execution, retries, and sleeping.
• A single Account Durable Object manages account-wide workflow and instance metadata.
• All create, update, and list operations passed through the Account object.
• High-volume customers could generate thousands of requests per second as instances started and completed, overwhelming the singleton.
• The original rate limits were therefore hard architectural limits rather than adjustable product settings.

V2: Horizontal Scaling Principles

The redesigned control plane is based on several architectural changes:

• The instance’s Engine is now the sole source of truth for whether that instance exists.
• The system verifies that an Engine exists before queuing an instance, avoiding queued instances with no running execution object.
• Instance lifecycle and liveness operations are distributed across workflows and regions so they can scale horizontally.
• The Account singleton stores only essential metadata and has a bounded maximum number of concurrent requests.
• Limits are designed to be flexible and increaseable rather than constrained by one central bottleneck.

SousChef and Gatekeeper

• V2 introduces two central components: SousChef and Gatekeeper.
• SousChef acts as a “second in command” to the Account, taking over work that previously concentrated all workflow and instance management in one Durable Object.
• Together, these components are intended to distribute control-plane responsibilities and enable higher creation rates and concurrency.
• The migration was performed with live traffic, allowing customers to move to the new architecture without interruption.

The redesign aligns Workflows with agentic workloads by moving coordination away from a single account-level Durable Object. Developers running high-volume or highly concurrent agents should benefit from the new limits and a control plane that can continue scaling independently.