Skip to content

CLOUDFLARE 2026-05-19 Tier 1

Read original ↗

Cloudflare — Announcing Claude Managed Agents on Cloudflare

One-paragraph summary

Cloudflare launch post (2026-05-19) co-announced with Anthropic for Claude Managed Agents — a new Anthropic platform that runs the agent control loop on Anthropic's infrastructure but lets the execution sandbox (file reads, command exec, code execution, browsing) run on self-managed infrastructure like Cloudflare's Developer Platform. Anthropic frames this as "decoupling the brain from the hands" — the brain (the agent loop) stays on Anthropic, the hands (infrastructure that runs and executes code) move to wherever the operator chooses. Cloudflare ships a default deployment template that wires the integration end-to-end. The architecturally load-bearing primitives disclosed: (1) a Workers-based control plane that minted by the template; each Claude session phones home to the control plane, which provisions a sandbox per session and persists state across session sleeps. (2) Two interchangeable sandbox tiers — microVM-based Cloudflare Containers (Linux, full filesystem, suitable for "agents acting as developers, building full applications and running Linux-based tools") vs lightweight V8-isolate Dynamic Workers using Codemode (boots in milliseconds, "a few MB" of memory, runs arbitrary JS in a capability-bound isolate; a backend type the operator picks at agent setup). Anthropic's positioning: "running with isolates will allow you to scale in a way that no VM-based solution allows" for fleets where each user runs many agents and each employee runs tens of agents simultaneously — i.e. where microVM-per-agent burns "a ton of resources and money." (3) Outbound Workers as the egress proxy for every byte leaving the sandbox — fully customisable, lets the operator inject credentials server-side (the agent never sees them), apply allowlists, enforce egress policy per tenant / per agent / per metadata, and run custom proxy middleware. (4) Two new private-connectivity primitives — Cloudflare Mesh and Cloudflare Workers VPC — that let the egress proxy reach private internal services (on AWS, on-prem, or any VPC) using post-quantum-encrypted networking without a VPN or bastion host. The integration also bundles agent-ergonomic tool surfaces: Browser Run (browser_search, browser_execute, screenshot, browse, fetch_to_markdown, a Cloudflare-specific web_fetch), the Email Service (send_email, email_read, email_list; each agent gets its own email address; sessions can be kicked off via inbound email), call_service (Mesh / Workers VPC tunnels into private services), and image_generate (image generation served from Workers AI paired with Claude's text inference). Custom tools are added by writing a defineTool entry in custom-tools.js with a Zod schema for the inputs and a function body — illustrated in the post with a r2_host_file tool that uploads to R2 and returns a public URL. The whole integration is meant to be forked from the template repo and customised.

Key takeaways

  1. "Decoupling the brain from the hands" is the architectural thesis of the launch. Anthropic's framing, quoted directly: "The core agent loop runs in Anthropic (the 'brain'), but the infrastructure for running and executing code (the 'hands') can be run anywhere, including Cloudflare." This is the crystallisation of an architectural shape that has been latent on the wiki across several adjacent posts (e.g. agent harnesses that delegate execution to remote sandboxes); the term is now pinned at concepts/agent-brain-hands-decoupling. What it buys: independent choice of model platform vs execution substrate; agents can be moved between clouds, security regimes, and compliance boundaries without rewriting the agent loop. What it costs: a network round-trip per tool call between Anthropic's brain and the operator's hands, and an integration contract (the message Claude sends to the control plane on session start) that has to stay stable across versions.

  2. The big trade-off announcement: V8 isolate vs microVM as tiers, not as competitors. From the post directly: "What if your agent backend booted in a few milliseconds, and you didn't have to pay for the resources of a full VM when running the agent? The industry needs a lightweight primitive for sandboxing as we adopt agents at scale, and we're building just that." The wiki canonicalises this trade-off at concepts/isolate-vs-microvm-for-agent-sandbox:

Dimension microVM (Containers) V8 isolate (Dynamic Workers + Codemode)
Boot seconds milliseconds
Memory floor hundreds of MB a few MB
Filesystem full Linux virtual workspace via Sandbox SDK HTTP API
Suitable for dev-agent shape: building full apps + running Linux CLIs one-shot inference / tool-call agents at "tens of thousands of concurrent" scale
Pick via Containers backend "isolate" backend

The forced binary choice ("microVM or nothing") that characterised first-generation agent-sandbox products is replaced by a per-agent tier selector, picked at sandbox creation time based on workload shape.

  1. Egress proxy = single load-bearing security boundary for agents. The Cloudflare integration treats outbound network traffic as the canonical chokepoint for agent governance. Quoting the post: "sandboxed workloads on Cloudflare can use an outbound proxy for fully dynamic, customizable, and zero-trust authentication between sandboxes and external services. This lets you inject secrets into requests outside the sandbox, so the agent never has access to them. This protects against exfiltration attacks." The wiki canonicalises the server-side credential-injection half at concepts/outbound-proxy-credential-injection; the Cloudflare-specific deployment shape at patterns/outbound-worker-proxy-for-agent-egress. This is the same structural shape as the previously-canonicalised credentialed-proxy sandbox (Agent Lee, 2026-04-15) and gateway-only egress sandbox (Redpanda ADP, 2026-04-14) — Claude Managed Agents on Cloudflare is the third independent canonical instance of the egress-as-only-boundary thesis, generalised across vendor platforms. Per the post, the egress policy is programmable "per tenant, per agent, or based on whatever metadata is useful."

  2. Private-service connectivity gets two new primitives. The post is the first wiki disclosure of two new Cloudflare capabilities that compose with the egress proxy: Cloudflare Mesh and Cloudflare Workers VPC. Both let an outbound Worker reach private services that should never be exposed to the open Internet — typical examples are internal databases on AWS, internal APIs on-prem, or any VPC resource — using post-quantum-encrypted networking without a VPN or bastion host. This is significant because the common alternative architecture (push agents into the organisation's VPN; require bastion hosts; treat the agent as a privileged client) creates exactly the sandbox poisoning surface that the egress-only-boundary thesis is trying to eliminate. With Mesh / Workers VPC, the sandbox stays untrusted; the credentialed proxy retains its position as the only authoritative path; and the proxy can reach internal services transparently.

  3. State persists across session sleeps automatically. From the post: "each agent session a sandboxed environment for executing code, developing applications, running CLI tools, and more. State is automatically persisted across session sleeps." This crystallises the durable-vs-ephemeral decision in favour of durable for Claude-managed-agent sessions, but with the wrinkle that durability is provided by the Cloudflare control plane — not by the agent harness on Anthropic. The control plane is the substrate that gives the sandbox a stable identity across sleeps, persists workspace files, and reattaches the agent to the same sandbox when the session resumes. SSH into a running machine is one of the exposed observability primitives — "SSH into running machines" — for operators debugging agent behaviour.

  4. Tools are pluggable via Zod-typed function definitions. The integration shows a literal example for adding an r2_host_file tool:

defineTool({
  name: "r2_host_file",
  description: "Upload from sandbox to R2 and get a public URL.",
  inputSchema: z.object({
    key: z.string().describe("Object key"),
    content: z.string().describe("UTF-8 file body"),
    contentType: z.string().describe("MIME type"),
  }),
  run: async ({ key, content, contentType }, { env }) => {
    await env.PUBLIC_BUCKET.put(
      key, content, { httpMetadata: { contentType }}
    );
    return `${env.PUB_R2_URL.replace(/\/$/, "")}/${encodeURI(key)}`;
  }
}),

The pattern is canonicalised at patterns/pluggable-zod-tool-definition — agent capabilities extended via a tiny config block that pairs (a) schema contract (Zod input definition, descriptive prose for the model), (b) runtime body (a JS function), and (c) resource bindings (Cloudflare bindings via env) — without requiring additional infrastructure. Pre-built tools shipped in the integration include browser_search, browser_execute, screenshot, browse, fetch_to_markdown, web_fetch, send_email, email_read, email_list, call_service, and image_generate.

  1. Browser sessions are first-class observability artefacts. The Browser Run integration "makes it easy to audit every action your agent's browser is taking on the web, apply allowlists and denylist to browser sessions, and save recordings of browser sessions for future debugging" with support for human-in-the-loop flows. This is the same shape as Cloudflare's Browser Run / Browser Isolation (BISO) session-recording substrate — agent browser activity gets the same audit trail as a human user's browser activity in a Zero-Trust browsing session. Operationally this means the security team gets a single pane of glass covering both human-driven and agent-driven web actions.

  2. Email becomes a first-class agent-control-plane channel. "You can also kick off new sessions via email, or configure the agent to send emails using any domain and address configured with the Cloudflare Email Service." Each agent session gets its own email address; agents reply to forwarded email context; inbound email is a session-start trigger. This composes with the existing wiki canonicalisation of email-as-agent-interface primitives (concepts/email-as-agent-interface, concepts/address-based-agent-routing). The novel piece is that the email runs the same per-session sandbox — an email reply is the agent's tool output flowing through the same control plane and egress proxy as any other action.

  3. Sandbox observability is multi-channel. The post lists what ships in the default integration: "each sandbox can be observed in the Cloudflare dashboard, sandbox logs can be queried or shipped to external providers like Datadog or Splunk, and the control plane ships with a built-in UI, making it easy to track the state of sandboxes or SSH into specific machines." Three independent channels (dashboard / external SIEM / shell access) cover the canonical operator flows: (a) cohort-level health monitoring, (b) compliance logging, (c) per-sandbox debugging. This is the same "three-sided observability" shape as the Project Think disclosure for self-hosted agents.

Architectural diagram (textual)

┌────────────────────────────────────┐         ┌──────────────────────────────────────────┐
│ Anthropic Platform (the "brain")   │         │ Cloudflare Developer Platform (the "hands") │
│ ┌──────────────────────────────┐   │         │                                              │
│ │ Claude Managed Agent loop    │ ──tool────▶ │ ┌──────────────────────────────┐            │
│ │ (model inference, prompt     │    call    │ │ Workers control plane         │            │
│ │  cache, compaction, harness) │ ◀───tool─── │ │ • spins sandbox per session   │            │
│ └──────────────────────────────┘    result   │ │ • persists state on sleep     │            │
│                                              │ │ • exposes UI / SSH            │            │
│                                              │ └────────────┬─────────────────┘            │
│                                              │              │                              │
│                                              │  ┌───────────┴───────────┐                  │
│                                              │  │                       │                  │
│                                              │  ▼                       ▼                  │
│                                              │ ┌──────────────────┐ ┌────────────────────┐ │
│                                              │ │ microVM sandbox  │ │ V8-isolate sandbox │ │
│                                              │ │ Cloudflare       │ │ Dynamic Workers +  │ │
│                                              │ │ Containers       │ │ Codemode           │ │
│                                              │ │ (full Linux)     │ │ (~ms boot, MBs RAM)│ │
│                                              │ └────────┬─────────┘ └─────────┬──────────┘ │
│                                              │          │                     │            │
│                                              │          └─────────┬───────────┘            │
│                                              │                    │                        │
│                                              │       ┌────────────▼─────────────┐          │
│                                              │       │ Outbound Worker proxy    │          │
│                                              │       │ • allowlist endpoints    │          │
│                                              │       │ • inject credentials     │          │
│                                              │       │ • per-tenant policy      │          │
│                                              │       │ • custom middleware      │          │
│                                              │       └────┬────────┬────────┬──┘          │
└──────────────────────────────────────────────┴────────│────────│────────│─────────────────┘
                                                       ▼        ▼        ▼
                                                External    Cloudflare  Internal services
                                                Internet    Mesh /      via private VPC
                                                (allowed)   Workers VPC tunnels (post-quantum
                                                            tunnel      encrypted, no VPN /
                                                                        bastion required)

Operational numbers / claims

  • V8-isolate boot: "a few milliseconds" (vs "seconds" for microVM).
  • V8-isolate memory: "a few MB" (vs "hundreds of MB" for microVM).
  • Scale envelope: V8 isolates handle "bursts of tens of thousands of concurrent agents or more" — "no VM-based solution" matches this in the post's framing.
  • State persistence: "automatically persisted across session sleeps" (durability provided by Workers control plane).
  • Pre-bundled tools (8 named): browser_search, browser_execute, screenshot, browse, fetch_to_markdown, web_fetch, send_email, email_read, email_list, call_service, image_generate. (Post is non-exhaustive.)

Caveats

  • Launch post. The disclosure is at architecture-thesis altitude; quantitative latency / throughput / cost numbers are not given for the Anthropic-brain → Cloudflare-hands round trip. Future ingest opportunity: a follow-up post or external customer write-up disclosing real measurements on the end-to-end latency budget.
  • No published comparison vs Anthropic-only execution. The post claims operator benefits (security, compliance, performance) for self-hosting the hands, but does not put numbers on the trade vs running the entire stack on Anthropic.
  • Default deployment template is JavaScript-only at launch. The example defineTool is JS + Zod; the post does not name language alternatives, though Cloudflare Workers does support WASM-targeted compiled languages (workers-rs etc.) — extending the template to those languages is left implicit.
  • Brain-hands contract not formally specified in the post. The exact wire protocol Claude uses to phone home to the Cloudflare-based control plane is not documented in the launch post (the GitHub repo is the operational source of truth). Future ingest opportunity: an architecture.md or contract.md from the cloudflare/claude-managed-agents repo with the message-shape spec.
  • Cloudflare Mesh / Workers VPC are referenced as generally-available products in the post but the wiki has not previously tracked them. This ingest creates the first canonical wiki pages for both (systems/cloudflare-mesh and systems/cloudflare-workers-vpc); a later dedicated Cloudflare ingest of one of those products' own launch posts would deepen them.

Source

Last updated · 542 distilled / 1,571 read