Building Keystone with Cloudflare Agents

This is a historical account of an April 2026 prototype, with product descriptions and sources clarified in September. Keystone was a personal experiment. The screenshots and observations below describe that prototype; they do not represent a client deployment or a production security assessment. Preview and beta labels refer to the original announcements.

Cloudflare’s April 2026 Agents Week included announcements across compute, agent tooling, and developer workflows. As someone who had used Cloudflare for personal projects, I wanted to try the pieces together. Cloudflare’s April announcement roundup provides the product context.

I built a prototype I called Keystone: a property management system combining voice, browser automation, multi-agent coordination, durable workflows, persistent storage, and inbound email. I wanted to see how much integration work the platform handled and where I still needed to make application decisions.

I liked the direction and wanted to build more with it. These were my observations from that experiment.

The stuff that actually matters

1. Dynamic Workers: isolate generated code

The problem: An agent that writes code needs an execution environment. Developers can use containers, virtual machines, or isolates, depending on the required tools and isolation model. Running untrusted code with the same privileges as the main application creates avoidable risk.

What changed: Cloudflare opened the Dynamic Worker Loader beta on March 24, ahead of Agents Week. Developers can load code into a Worker isolate at runtime and choose the bindings it receives. Cloudflare describes the execution model and its controls in the Dynamic Workers announcement.

Why it matters: You can give generated code a narrower set of capabilities. You still need to restrict network access, protect credentials, validate results, and decide which actions require approval. An isolate does not make an agent’s decisions trustworthy or remove application security responsibilities.

My take: This was one of the most useful pieces to evaluate. I would start with the permissions a task needs, then compare the runtime and cost against a container-based approach.

2. Sandboxes: a workspace with operating-system tools

The problem: Some agents need a shell, build tools, and background processes. A short code-execution call cannot cover that entire workflow. You also need to decide which files and process state should survive interruptions.

What changed: Cloudflare announced Sandboxes general availability on April 13. The release included terminal support, background processes, persistent code interpreters, and snapshots for recovering a workspace. The original Sandboxes announcement describes those capabilities.

Why it matters: You can choose a full workspace when the task needs one. Plan the sandbox lifecycle, persistence, and recovery behavior; a running process is not a substitute for a tested recovery plan.

My take: A first-party workspace option can simplify a Cloudflare-based project. I would still test the required tools, resource limits, and recovery paths before using it for production work.

3. The Agents SDK: Project Think and Fibers

The problem: A dispatch workflow might acknowledge a request, find a contractor, dispatch them, and notify the people involved. A crash between those actions can leave the application unsure what happened. Developers need durable state and a recovery strategy, whether they use an agent SDK, a workflow engine, or a queue.

What changed: Cloudflare previewed Project Think on April 15. Its Fibers primitive lets developers register durable work, save explicit checkpoints with stash(), and handle recovery with onFiberRecovered. The SDK does not automatically save every application step or guarantee that an interrupted external action runs exactly once. The Project Think announcement includes the checkpoint and recovery model.

The preview also included a Think base class, sub-agents, and persistent sessions. These provide building blocks for coordinating work and preserving context.

Why it mattered in the prototype: I killed the server mid-flow and observed the flow resume. That was one prototype test. Before using this for dispatching a contractor or sending a message, I would test repeated interruptions, checkpoint recovery, and duplicate-action prevention. Durable execution helps preserve progress, but developers still need to design retries and external side effects.

My take: Underhyped. This deserves more attention than the flashier voice and browser stuff. If you're building anything multi-step, this is where you should look first.

4. Voice Agents: a shared voice and text interface

The problem: A voice interface needs speech recognition, response generation, and speech output. Phone access can also require a telephony integration. Developers need to connect those stages and handle interruptions and delays.

What changed: Cloudflare released @cloudflare/voice as an experimental package. It connects speech recognition, an agent’s turn handler, and speech generation, with built-in Workers AI providers. Voice and text can share the same agent state. See the April voice pipeline announcement for its interfaces and provider options.

Why it matters: Voice used to be a separate product. Now it's just another way to interact with your agent. A user can start by typing, switch to voice mid-conversation, and switch back. The agent doesn't know or care. For anyone building consumer-facing agents (customer service, scheduling, smart-home), this reduces the complexity significantly. It took me less than five minutes to get a voice agent running in Keystone.

My take: Adding voice used to feel like a whole separate project. Now it's a feature you bolt onto an existing agent in an afternoon. It's still early. Latency could be better, and the non-default speech providers take some extra work to plug in. But for the first time it's actually practical for a solo builder to ship a voice-enabled agent without it being the whole app.

5. Browser Run: inspect and assist browser sessions

The problem: An automated browser can get stuck on a login screen or an unexpected page. Developers need visibility into the session and a way for a person to assist within the site’s access rules.

What changed: Cloudflare renamed Browser Rendering to Browser Run. Its April announcement included higher concurrency limits, Live View, session recordings, and human intervention in browser sessions. A person can inspect a session and assist when needed. The Browser Run announcement documents the release; current account limits may differ.

Why it matters: Browser automation can support research and work in applications that lack an API. Human intervention helps handle exceptions, but it does not replace permission checks, site access rules, or approval before consequential actions.

My take: In Keystone I had the contractor agent search Google for local plumbers, visit their websites, and check the Texas licensing portal. It worked. Screenshots came back, data got extracted, nothing fell over. The rebrand from "Browser Rendering" to "Browser Run" is mostly marketing, but the capability upgrades are real.

6. Agent Memory: retrieve context across sessions

The problem: A long conversation can contain more material than the next task needs. Developers have to choose what to retain and retrieve, while accounting for accuracy, permissions, and deletion requests.

What changed: Cloudflare announced Agent Memory in private beta on April 17. The service extracts information from conversations and retrieves it for later use. The original Agent Memory announcement explains the proposed memory model.

Why it matters: Managed retrieval could reduce implementation work. A team still needs to evaluate what the agent recalls, whether the information remains correct, and who can access it.

My take: I did not test Agent Memory in Keystone because I did not have access to the private beta. My interest here was in the design, not a measured result.

Other announcements I noted

• AI Gateway. Cloudflare expanded its model catalog and access through the Workers AI binding. I would compare the required models, data handling, and failure behavior before choosing a gateway. Original inference announcement.
• Kimi K2.5 on Workers AI. This launched in March, before Agents Week. I had been using Kimi K2.5 in my own OpenClaw setup and liked having another hosting option for it. Original model announcement.
• Email Service. Cloudflare announced Email Sending public beta alongside its existing inbound email capabilities. I tried email in the prototype and appreciated the integration with Workers. Original Email Service announcement.
• Cloudflare Mesh. Mesh connects private networks and integrates with Cloudflare’s access controls. Teams still need to configure which resources an agent can reach and what actions it can take. Original Mesh announcement.
• Unified CLI (cf). The April release was a technical preview covering a subset of products, not a complete replacement for Wrangler. I was interested in the plan for consistent commands across the platform. Original CLI announcement.

The "interesting but niche" pile

• Artifacts. Cloudflare announced Git-compatible versioned storage in private beta. I would evaluate it when an agent needs separate versioned workspaces. Original Artifacts announcement.
• Flagship. Cloudflare introduced a feature flag service for controlling releases. An agent-driven rollout still needs approval rules, monitoring, and a rollback plan. Original Flagship announcement.
• Unweight. Cloudflare reported reduced model-weight memory use through lossless compression. Those are the vendor’s measurements, not results from Keystone. Original Unweight engineering post.

The "I'm not sure this matters" pile

• Agent Readiness Score. Cloudflare introduced a tool for checking how websites support agents. I would use the checks to investigate specific issues, rather than treat a vendor score as proof of search visibility or useful AI answers. Original Agent Readiness announcement.
• Redirects for AI Training. The announced feature redirects verified training crawlers to qualifying same-origin canonical URLs. It does not redirect all AI assistants or change material they have already ingested. Original redirect announcement.
• Shared Dictionaries. Cloudflare previewed support for compressing resources against previously cached versions. The benefit depends on browser support, configuration, and how assets change. Original compression announcement.

What I'd actually do with all this

My next step would be to choose one workflow and test the capabilities it needs:

• For multi-step work, test checkpoint recovery and prevention of duplicate actions.
• For generated code, choose the execution environment and restrict its capabilities.
• For browser work, define access permissions and the actions a person must approve.
• For voice, measure response time and transcription quality with representative conversations.
• For memory, evaluate retrieval quality and deletion behavior before relying on it.

I came away interested in the platform and clearer about what I needed to test next. For a current project, our AI agent development work starts with the workflow and its constraints, then the choice of tools.