cloudflareMay 19, 2026

Announcing Claude Managed Agents on Cloudflare (opens in new tab)

Cloudflare and Anthropic have integrated Claude Managed Agents with Cloudflare Sandboxes, separating Claude’s agent reasoning from the infrastructure that executes code. The integration adds customizable security controls, sandbox observability, private-service access, browser auditing, email, and custom tools. It supports both full microVMs for complex workloads and lightweight isolates for fast, large-scale execution. ## Claude Managed Agents and the “Brain vs. Hands” Model - Claude Managed Agents run on Anthropic’s platform and can: - Read and write files - Run commands and code - Browse the web - Use prompt caching, compaction, and agent-focused optimizations - The integration decouples: - **The brain:** Claude’s agent loop on Anthropic’s infrastructure - **The hands:** Code execution, tools, sandboxes, and connected services on Cloudflare - Self-managed execution gives organizations more control over security, compliance, infrastructure, and performance. ## Cloudflare-Based Agent Environments - A Workers-based control plane creates a sandbox for each Claude Agent session. - Sandboxes support: - Code execution and file operations - Application development and CLI tools - Persistent state across session sleeps - Developers can customize: - Sandbox instance sizes - Container images for VM-based sandboxes - Cloudflare provides detailed metrics and logs, dashboard monitoring, external log shipping to services such as Datadog or Splunk, and SSH access to running sandboxes. - A built-in UI helps track sandbox state and open interactive shell sessions. ## Scaling with Isolates and MicroVMs - Full microVMs are appropriate for agents that need Linux environments, developer tooling, or complete application stacks. - Cloudflare also offers lightweight V8 isolate sandboxes using Agents SDK, Dynamic Workers, and Codemode. - Isolates provide: - Millisecond-level startup - Lower infrastructure costs - File-system support and arbitrary code execution - Much higher concurrency than VM-based systems - Developers can select an “isolate” backend when configuring an agent. - Isolates are intended for workloads reaching tens of thousands of concurrent agents, while Cloudflare Containers provide microVM-based execution when stronger environment fidelity is required. ## Security and Agent Connectivity - The default deployment routes agent traffic through customizable outbound proxies. - Proxies can help: - Inject credentials outside the sandbox - Prevent agents from accessing raw secrets - Reduce data exfiltration risk - Monitor interactions with external services - Agents can connect to private internal services without exposing those services directly to the public Internet. - The integration also includes browser session controls, recordings, audit trails, and human-in-the-loop workflows. ## Built-In Agent Capabilities The deployment template includes several capabilities without requiring additional infrastructure: - Detailed sandbox metrics, logs, and SSH access - Custom sandbox images and resource sizing - Browser automation with observability - Individual email addresses and outbound email for agents - Custom tools implemented as functions and deployed directly - Flexible execution through either isolates or microVM-backed sandboxes Cloudflare’s recommendation is to use isolates for inexpensive, highly concurrent workloads and microVMs when agents require full Linux environments or complex development workflows. The integration is designed to let teams keep Claude’s reasoning on Anthropic while retaining control over execution, connectivity, security, and observability on Cloudflare.

agent-sdkcloudflare-workerszero-trust-securitycloudflare-sandboxes+3

cloudflareApr 15, 2026

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.

agent-sdkdatabase-designdurable-objectssqlite+3