Beyond Serverless: How We Build an Agentic Virtual Computer on Cloudflare

The Evolution of Cloud Runtimes and Our Journey from Blocklet 1.0 to 2.0

Serverless made a powerful promise: write the application, and let someone else manage the servers. It changed cloud development. Yet a question remains after the deployment succeeds: what, exactly, is the application?

Is it a function? A repository connected to a deployment service? A collection of routes, database bindings, and background jobs? Those are useful answers for operating software. A person using that software has other concerns: where their data lives, who can act on it, and what they can keep when the software changes.

I think the next useful abstraction has to connect these two views. Serverless changed how applications run. ARC is our exploration of how applications are defined, composed, and owned. Modern cloud runtimes make that exploration practical.

Our journey from Blocklet 1.0 to Blocklet 2.0 reflects this change in emphasis. We started by making applications easier to package and operate. We are now working on an application model that can express more of what the application needs, while leaving execution to the environment underneath.

1. The serverless promise: stop managing servers

AWS introduced Lambda in November 2014. Its practical appeal was straightforward: upload code, connect an event source, and have AWS handle the execution environment. A developer could respond to a file arriving in storage without provisioning a server to wait for it.

The function was a useful unit. It gave the platform a defined entry point and gave the developer a smaller operational responsibility. Event sources, permissions, and execution limits became part of the programming environment. The machines still existed; managing them moved behind a service interface.

That shift mattered even when the application was much larger than any one function. A thumbnail generator might fit comfortably into a single event handler. An application with users, persistent records, scheduled work, and a web interface required several services to cooperate. Developers gained a simpler execution model and took on the work of connecting those services.

This is a recurring pattern in computing. A good abstraction removes one kind of work and makes another kind more visible. Once provisioning a machine becomes routine, application composition starts to consume more attention. Once deployment is automated, the relationships among data, permissions, and services become harder to ignore.

Lambda remains an important expression of this approach. Its contribution belongs in the history of serverless because it made event-driven execution accessible through a widely used cloud service. The history after that point branches into several overlapping efforts to give developers more useful units of work.

2. From functions to full-stack applications

Netlify helped make the website project a practical deployment unit. Its approach connected source control, builds, and delivery, with deploy previews making a proposed change visible before publication. The JAMstack movement emphasized prebuilt content, JavaScript, and APIs. Much of the operational workflow moved into the platform around the project. Netlify’s deployment documentation describes this source-to-site workflow; the Jamstack account explains its architectural origins.

For developers, that was a change in the daily experience of shipping software. A Git commit could produce a reviewable website. The platform understood enough about the build and its output to turn deployment into a normal part of collaboration.

Vercel developed another influential expression of application delivery, closely integrating framework behavior with hosting. Routes, rendering choices, caching, and server execution could become part of a coordinated development workflow. Its current Fluid compute model also illustrates how execution continues to evolve beyond the early picture of one isolated function invocation at a time. Its documentation describes concurrent invocations within a function instance.

These platforms overlap. Lambda can serve a full application; a website platform can execute server code; a framework-oriented platform can host background work. The useful historical distinction is the responsibility each made easier to express.

I see these developments as evidence that the boundary around “the application” keeps moving. Developers want to describe a meaningful result and hand more mechanical work to a runtime. Each successful abstraction has to understand enough of the application to take responsibility for that work.

There is still a choice about how much of an application's definition belongs to one hosting environment. A deployment configuration naturally describes what that environment can provide. An application model has to address a longer relationship: the application, its resources, and the person or organization controlling it.

3. Cloudflare Workers: a foundation with more than request handlers

Cloudflare Workers brought V8 isolates to a globally distributed execution environment. Isolates allow multiple JavaScript execution contexts to share a runtime process while maintaining isolation. That creates a different execution model from starting a separate operating-system process or virtual machine for every application. Cloudflare explains the isolate-based runtime model in its architecture documentation.

The surrounding platform now supports considerably more than short, stateless handlers. Durable Objects combine a uniquely addressed object, coordinated execution, and persistent storage. They provide a place to organize stateful interactions, including work that needs a single point of coordination. Workflows support durable, multi-step execution with persisted progress and retry behavior.

Containers extend the available execution options for workloads needing a container environment. Cloudflare's Agents SDK builds on platform capabilities for persistent agents, state, and communication. These services have different lifecycles and operating constraints; selecting the right combination is part of application architecture.

A useful way to read this collection is as a richer set of building materials. A request handler can initiate work. A durable object can coordinate an ongoing interaction. A workflow can carry a task through several steps and recover from interruption. A container can execute software with requirements beyond the isolate environment.

Those are substantial architectural capabilities. An application layer built on Workers needs to understand their behavior and use them deliberately. Hiding every distinction behind a generic “compute” box would make the application harder to reason about.

Our previous article on ARC's Cloudflare runtime explains where ARC runs and how our hosted implementation uses Cloudflare. Our official online services run on Cloudflare. Here, the question is what that foundation makes possible at the application layer.

We don’t see Cloudflare Workers as something ARC needs to replace. We see modern serverless runtimes, including Workers, as the foundation on which a new generation of application abstractions can be built.

4. Our journey: from Blocklet 1.0 to Blocklet 2.0

Blocklet 1.0 approached the problem through packaging. A Blocklet brought together an application and the information needed to install and run it. Blocklet Server provided an environment for hosting and managing those applications. Its lifecycle APIs cover installation, starting, stopping, and configuration.

The intent was familiar to anyone who liked the serverless promise: reduce the operational work between having an application and using it. The mechanism was an application hosting environment, with executable applications managed by a server. Its unit was a packaged application, rather than a Lambda-style event handler.

Packaging solved a real problem. It also left the application's internal structure largely inside its executable code. A host could install and run a package while knowing relatively little about the data and capabilities the application used. Those relationships depended on the application's implementation and integrations.

Blocklet 2.0 changes where we put that structure. Application content and declarations describe resources and interfaces that ARC can interpret. Custom logic still has a role, but the runtime can take responsibility for more behavior because the application expresses more of its requirements in a shared form.

That is the important transition for me: from understanding how to start an application to understanding more of what constitutes it.

There is an engineering cost to changing this boundary. An existing executable application can contain assumptions about subprocesses, local files, or a persistent server. Those assumptions need to be examined when adapting it to a different execution model. The old subprocess-hosting model is not the execution contract of Blocklet 2.0.

Continuity comes from the goal of making applications usable and manageable. The implementation has changed enough that migration requires real application work.

5. AFS, AOS, ARC: building a virtual computer

The most important way to understand ARC is as a virtual computer. An application model is part of that computer, but the environment continues to exist as applications are installed, changed, or removed. It organizes the resources and authority with which those applications work.

That distinction gives our architecture its shape. We begin with AFS, the Agentic File System: a virtual file system that addresses data and capabilities through paths. A path can lead to a document, a collection, an external service, or an executable tool. Providers implement access to those resources, while applications and agents use shared operations such as reading, listing, writing, and executing.

Above AFS, AOS, the Agentic Operating System, supplies operating-system services. It organizes identity and permissions, sessions, scheduling, and application lifecycle. A file system gives a resource an address; the operating-system layer organizes who can use it and how work proceeds over time.

ARC, the Agentic Realm Computer, brings these parts into a working computer on a particular host. Its runtime initializes the environment and connects its services to the host through adapters. AUP, the Agentic UI Protocol, describes interfaces that let people interact with applications in that environment. Agents reach data and capabilities through AFS paths.

“Virtual computer” describes a software-defined computing environment. The abstraction is at the level of resources, operating-system services, and applications; ARC uses the host's execution mechanisms. On Cloudflare, that includes Workers and Durable Objects. On a local machine, it can use a persistent Node/Bun process. Native Swift and Kotlin implementations connect the shared protocols to device capabilities.

A Blocklet is an application within this computer. Its directories and manifest describe content, resource mounts, and interfaces. Mounts make resources available at paths; surfaces expose selected paths through HTTP. Execution logic works with the resources supplied to that application. This website is itself one such Blocklet.

A person can use different applications in the same computing environment. Our long-term ownership goal is to make identity, application content, and personal data durable beyond a particular application or deployment. That requires understandable formats, permission boundaries, and compatible implementations. Each host still needs the adapters and capabilities an application requires. Lambda or another container-based host would need corresponding adaptation and validation.

The change from Blocklet 1.0 is therefore larger than a new deployment format. We are building the computer in which applications live.

How Cloudflare supplies the foundation

A virtual computer needs execution, persistent state, storage, and a way to schedule work. Cloudflare provides a coherent set of services for those responsibilities. Building ARC on that foundation is a natural architectural choice: we can compose managed infrastructure into the computing environment we want to provide.

Workers is particularly interesting to me because the isolate model changes the starting point for running software. A runtime can receive work without dedicating a traditional application-server process to each application. Together with addressable state and durable services, this gives us useful materials for constructing a computer whose parts do not have to live inside one long-running process.

Our Cloudflare implementation uses these materials in specific ways:

The storage mapping makes the separation concrete. AFS presents paths and operations. The Cloudflare storage implementation uses D1 to organize the tree and R2 to hold content. The application works with its resource interface; the adapter and provider implementations handle the platform mechanisms. Similarly, AOS defines session behavior, while the Cloudflare runtime uses Durable Objects to coordinate the ongoing interaction.

These are relationships between responsibilities, rather than a one-to-one replacement of every operating-system facility with a cloud product. One ARC service can use several Cloudflare components, and one component can support several ARC services. Permissions and data boundaries remain responsibilities of the computing environment we build.

The diagram shows the foundations connected in the current implementation. Cloudflare's Workflows, Containers, and Agents SDK offer additional capabilities to evaluate as that environment develops. Their availability creates engineering options; each integration still needs an explicit contract and implementation.

6. The next abstraction for the agentic era

AI agents make the application-definition question more pressing. An agent can generate a great deal of code. Someone still has to understand the result, grant it access, and operate it after the first successful demonstration.

Declarative structure can help because it gives both the runtime and its operators something inspectable. A proposed interface or resource declaration can be reviewed before execution. A named capability can have a permission boundary. Shared paths give an agent a more consistent way to find the data and tools available to it. These properties reduce how much behavior has to be inferred from arbitrary application code.

The corresponding responsibility is to keep the human in control of consequential choices. An agent constructing an application needs access appropriate to that task. Publishing it or granting new permissions remains a separate decision. A useful application environment should preserve those distinctions as the amount of generated software grows.

This is why I care about ownership alongside execution. A cloud platform can make an application available around the world. The application model still has to explain whose data it is using, what authority it has, and what persists when its implementation changes. Infrastructure and application architecture meet at that boundary.

The serverless promise removed much of the work of managing servers. Its continuing development gives us distributed execution, coordinated state, and durable work as usable services. Those capabilities allow an application runtime to take on responsibilities that once required much more infrastructure engineering.

Our move from Blocklet 1.0 to Blocklet 2.0 is an attempt to use that opportunity well. Packaging helped us say how an application could be installed. With ARC, we are building the virtual computer around those applications: AFS for resources, AOS for operating-system services, and host-specific runtimes that make the environment work. That gives application definition and long-term ownership a continuing place in which to develop.

The question after deployment succeeds is still the one from the beginning: what is the application? A useful answer should survive beyond the machine or service executing today's request. That is the next layer we are working on.