The core thesis of this litepaper sits at the intersection of agentic AI and web3: the moment an AI system stops being a chatbot and starts becoming an autonomous software worker...
The core thesis of this litepaper sits at the intersection of agentic AI and web3: the moment an AI system stops being a chatbot and starts becoming an autonomous software worker, it needs both an execution environment and an economic environment. The execution environment is the sandbox — a safe computer where the agent can browse, write code, run commands, manage files, and persist state. The economic environment is where web3 becomes relevant: programmable money, portable identity, scoped permissions, receipts, provenance, and ownership. In other words, every serious agent needs a computer — but not your computer — and every agent that transacts across the internet needs economic rails that look much more like web3 than traditional SaaS billing.
This is why agent sandboxes are becoming one of the most important infrastructure layers in AI. The first wave of AI applications was organized around inference: send a prompt, get a completion. The second wave was organized around tools: let the model call an API. The third wave is being organized around execution: let the agent operate inside an environment where it can write code, run tests, browse websites, install dependencies, manipulate files, and produce artifacts. The model is no longer the entire product. The model is the reasoning engine inside a larger execution loop.
Platforms such as E2B, Daytona, Runloop, Modal, Vercel Sandbox, and Browserbase are converging on this insight from different directions. Some provide full virtual computers for coding agents. Some provide ephemeral execution environments for untrusted or AI-generated code. Others focus on browser-native automation, because much of the digital economy still lives behind interfaces designed for humans rather than clean APIs. The details differ, but the category is stabilizing around a recognizable control surface: isolation, filesystem, process execution, network policy, credential handling, persistence, observability, and cost control.
For web3-AI, the relevance is not that every sandbox should run on-chain. That is the wrong frame. The right frame is that sandboxes solve the agent’s execution problem, while web3 can help solve the agent’s economic coordination problem. Once agents need to pay for APIs, purchase data, invoke paid tools, maintain portable identities, enforce spending limits, prove what happened, and own or monetize outputs, web3 primitives become highly relevant.
The strongest version of the thesis is not “decentralized compute replaces the cloud.” The stronger version is: cloud hosts the agent’s body; web3 coordinates the agent’s identity, budget, receipts, permissions, and economic relationships.
The next wave of web3-AI may not be defined by putting models on-chain. It may be defined by giving autonomous agents safe computers, programmable money, portable identity, and verifiable execution trails.
A chatbot is a brain in a jar. It can reason, summarize, explain, hallucinate, apologize, and occasionally write a surprisingly elegant paragraph. But it cannot really do much. It emits text into the void. It is a very smart oracle trapped behind a glass wall.
An agent is different. An agent is closer to an intern sitting in front of a laptop. It receives a goal, opens files, searches the web, writes code, runs commands, observes failures, makes corrections, fills out forms, pays for a resource, and comes back with an artifact. The artifact might be a pull request, a report, a dataset, a generated app, a trading workflow, or a research memo. What matters is that the agent is not just predicting the next token. It is participating in a loop: plan, act, observe, repair, continue.
That loop needs a runtime.
In the early LLM era, the missing primitive was the prompt. Then the missing primitive became the tool call. Now the missing primitive is the computer. Tool calling works well when the universe is conveniently decomposed into stable APIs. But much of the world is not like that. Repositories require local dependencies. Websites require browsers. Data analysis requires files. Software engineering requires tests. Procurement workflows require authenticated sessions. Financial workflows require credentials and policy. Even “simple” tasks become multi-step state machines once the agent has to actually execute.
This is why sandboxes are suddenly central. The model is the brain. Tools are the hands. The sandbox is the body and workspace. Logs and traces are the nervous system. Wallets and credentials are the economic identity. Policy engines are the rules of behavior. Without the sandbox, the agent can only suggest actions. With the sandbox, the agent can take them.
A useful analogy is the evolution from pure mathematics to robotics. A theorem prover can reason inside symbols, but a robot needs a body, sensors, actuators, power, constraints, and a safe test environment. Agentic AI is undergoing a similar transition. The LLM is the cognitive core, but execution requires embodiment. In software, embodiment looks like a Linux environment, a browser, a filesystem, and a network boundary.
This also changes how we should think about reliability. A chatbot fails by saying something wrong. An agent fails by doing something wrong. That distinction is enormous. If the model writes bad code in a chat window, the blast radius is low. If the model runs bad code in your production environment, opens the wrong browser session, leaks a credential, or spends money on the wrong API, the blast radius is suddenly very real. The sandbox exists to cage the blast radius.
Every serious agent needs a computer. Every serious computer for agents needs a sandbox.
An agentic sandbox is a secure, isolated, programmable computing environment where an AI agent can execute actions without exposing the user’s machine, production infrastructure, sensitive credentials, or external systems to unnecessary risk.
It sounds simple, but there is a lot packed into that definition.
First, the sandbox must be isolated. Agents should be treated like untrusted junior developers with rootless enthusiasm. They may execute code they wrote themselves, code pulled from the internet, package installation scripts, test suites, shell commands, browser automations, and arbitrary transformations of user data. The default assumption should not be “the agent is safe.” The default assumption should be “the agent is powerful and therefore must be contained.” Isolation is the membrane around the cell.
Second, the sandbox must be programmable. It cannot be a static container where one command runs and exits. Agents need to create files, edit files, run commands, install packages, start local servers, inspect processes, clone repositories, open ports, invoke scripts, and branch their work. A useful agent runtime looks more like a cloud laptop than a function call.
Third, the sandbox must be observable. Agent workflows fail in strange ways. A model may choose a wrong dependency, misread a stack trace, get stuck in an authentication loop, overwrite a file, exceed a budget, or retry the same broken command ten times. Developers need logs, command history, filesystem diffs, network traces, browser replays, resource metrics, and ideally full task-level traces. Observability is the black box recorder for autonomous software.
Fourth, the sandbox must have policy. It should be possible to say: this agent can access the internet but only these domains; this agent can run commands but not open outbound network connections; this agent can use this API key but never see the raw secret; this agent can spend ten dollars but not eleven; this agent can write files but not publish them; this agent can trade in simulation but not in production. A sandbox without policy is just a smaller danger zone.
Fifth, the sandbox needs state. One of the great lies of simple agent demos is that every task starts fresh. Real work does not. Dependencies should remain installed. Browser sessions should remain authenticated. Repositories should remain cloned. Intermediate artifacts should remain available. Snapshots, pause/resume semantics, persistent volumes, and reusable environments are not luxuries. They are the difference between a toy agent and a worker that can compound progress.
Taken together, an agentic sandbox has several core primitives:
PrimitiveWhy it mattersIsolationContains untrusted code and unpredictable behavior.FilesystemLets agents create, inspect, and modify artifacts.Shell/process executionLets agents run code, tests, scripts, and servers.Package installationLets agents adapt the environment to the task.Browser accessLets agents use the web as humans do.Network controlsLimits exfiltration, abuse, and unexpected calls.Secrets managementLets agents use credentials without exposing raw keys.PersistenceSupports long-running and resumable workflows.SnapshotsEnables branching, rollback, and fast startup.ObservabilityMakes agent behavior debuggable and auditable.PolicyBinds execution to human or organizational constraints.
The key point is that the sandbox is not a feature. It is the unit of agent execution. Just as the process became the unit of execution for operating systems, the sandbox is becoming the unit of execution for autonomous software workers.
The agent sandbox market is still early, but it is already beginning to segment. The companies do not all describe themselves in the same way, but they are circling the same object: a safe computer for AI agents.
One group is building full-computer sandboxes. E2B, Daytona, and Runloop are representative of this direction. Their center of gravity is the idea that an agent needs a real execution environment: terminal, filesystem, package management, persistent state, and lifecycle controls. These platforms are especially relevant for coding agents, data agents, evaluation agents, and software-development workflows where the agent needs to behave like a developer inside a machine.
E2B has become one of the clearest examples of this category. Its positioning is straightforward: give AI agents secure computers with real-world tools. The use cases are code execution, coding agents, computer use, data analysis, and sandboxed workflows where generated code needs to run safely. Daytona approaches the problem with the language of “full composable computers” for agents. That phrase is important because it points beyond containers into something closer to a programmable unit of work: an environment with its own filesystem, network stack, compute resources, and lifecycle. Runloop focuses heavily on coding agents, devboxes, secure execution, snapshots, event streams, and production-grade controls for software-engineering agents.
A second group is emerging from cloud and serverless infrastructure. Modal and Vercel Sandbox are strong examples. Modal sandboxes fit naturally into workloads that need ephemeral, scalable execution of untrusted or AI-generated code. Vercel Sandbox sits inside a broader developer cloud and is explicitly aimed at safely running untrusted or generated code in isolated environments. These platforms may not begin with the metaphor of “an agent computer,” but they are being pulled into the same orbit because agents need fast, secure, programmable execution.
A third group is browser-first. Browserbase is the most visible example. This category starts from a different observation: a lot of useful work happens not in APIs but in browsers. The modern web is a giant semi-structured interface for humans. Many valuable tasks live behind dashboards, forms, procurement portals, travel sites, financial tools, CRM systems, developer consoles, healthcare portals, and internal SaaS apps. If agents are going to operate in that world, they need browser sessions that are reliable, observable, persistent, and identity-aware.
This is a subtle but important distinction. For coding agents, the sandbox is often a terminal with a filesystem. For browser agents, the sandbox is a browser with memory, identity, replay, and workflow control. In both cases, the agent needs a bounded environment where action is possible and mistakes are contained.
The market can be compared across a few dimensions:
DimensionWhy it mattersIsolation modelDefines the security boundary around agent behavior.Startup latencyAgents may spawn many short-lived environments.PersistenceLong-running agents need resumable workspaces.Filesystem supportAgents need to read, write, diff, and move artifacts.Browser supportMany workflows require interaction with websites.Network controlsAgents should not have unconstrained internet access.Secrets managementAgents need credentials without raw secret exposure.ObservabilityDevelopers need to debug behavior, not guess.Cost modelAgent workloads are bursty and unpredictable.Enterprise controlsLarger customers need governance, compliance, and access control.
The interesting thing is not that these platforms differ. Of course they do. The interesting thing is that they are converging on the same control plane: execution, state, policy, and observability. That is what platform formation looks like. When different vendors independently rediscover the same primitives, it usually means the underlying market need is real.
For web3-AI builders, this matters because it suggests that “agent runtime” is becoming a durable layer in the stack. The model layer is crowded. The agent framework layer is noisy. The application layer is fragmented. But the runtime layer has a simple gravitational center: agents need safe computers.
The current sandbox market solves a major problem: execution. It gives agents a place to act. But as agents become more autonomous, another problem appears immediately: economic coordination.
Suppose an agent is asked to produce an investment research memo. It opens a browser, logs into a data platform, runs a Python notebook, calls a premium market data API, queries a specialized model, pays for a research database, generates charts, stores the output, and sends the final artifact to a human. The sandbox handles the execution environment. But who handles payment? Who says the agent is authorized? Who limits the budget? Who receives the receipt? Who proves which API was called? Who owns the output? Who can inspect the trace if something goes wrong?
This is the strategic gap.
Cloud sandboxes are excellent at providing compute primitives. They are less naturally suited to becoming neutral economic rails across many independent services. Traditional SaaS solves this with accounts, invoices, API keys, OAuth flows, enterprise contracts, and credit cards. That works tolerably well for humans and companies. It works poorly for autonomous software that wants to discover, meter, and pay for capabilities dynamically.
Agents need a more machine-native commercial interface. They need to be able to encounter a paid resource, understand the price, check their policy, authorize a payment, receive access, log the receipt, and continue the task — all without a human filling out a checkout form.
This is where web3 becomes interesting. Not as a replacement for the sandbox, but as the coordination layer around it. The sandbox is the workshop. Web3 can become the wallet, badge, receipt book, meter, and ownership registry.
The strongest thesis is therefore hybrid:
Sandboxed compute gives agents a safe place to act. Web3 gives agents a programmable way to pay, identify, prove, and own.
That is a much more practical thesis than “run all agents on decentralized compute.” Most agent execution will likely remain close to cloud infrastructure, data, browsers, and enterprise systems. But the economic boundary around agent execution may become increasingly open, programmable, and cryptographic.
Web3 fits agent sandboxes because agents are not just users of compute. They are becoming economic actors.
A human browsing the web can pay with a credit card, create an account, remember a password, approve a subscription, and reconcile a receipt later. An agent needs a software-native equivalent. It needs a wallet or payment capability, but that wallet cannot be unconstrained. A sandboxed agent with no money is operationally limited. A sandboxed agent with unlimited money is terrifying. The opportunity sits in the middle: scoped wallets, programmable budgets, approved counterparties, transaction limits, session-level policies, revocation controls, and auditable receipts.
This is exactly the kind of primitive web3 is unusually good at. Stablecoins are machine-readable money. Wallets are programmable accounts. Smart contracts are policy surfaces. Signed messages are portable identity primitives. On-chain receipts are shared settlement records. None of these magically solve agent safety, but they map very cleanly to the economic needs of autonomous execution.
The analogy is useful: the sandbox is the warehouse floor; web3 is the cash register, badge system, receipt printer, and settlement network. You do not want to replace the warehouse with a blockchain. That would be absurd. You want the warehouse to operate in an economy where autonomous workers can buy inputs, prove authorization, generate receipts, and settle with external providers.
There are five especially relevant web3 primitives.
First, payments. Agents will need to buy API calls, model inference, browser sessions, datasets, simulations, storage, verification services, and other agents’ outputs. Stablecoin-based payment protocols can make these resources payable by software directly, without the full baggage of human checkout flows.
Second, identity. Agents need persistent identities that travel across tools and runtimes. An agent identity might represent the user who delegated authority, the organization that owns the workflow, the wallet that funds the session, the permissions attached to the task, and the reputation accumulated from previous work.
Third, permissioning. Wallets can become policy objects. A sandbox session might receive a wallet that can spend up to $50, only on approved services, only for the next hour, only for a particular task, and only after human approval above a threshold. This is not speculative crypto theater. It is basic safety engineering for agents that can transact.
Fourth, provenance. Agents produce digital artifacts: code, reports, datasets, workflows, media, trading strategies, and decisions. For many of these artifacts, it will matter which agent produced them, under what policy, using which data, paid for by which wallet, and with which runtime trace.
Fifth, composability. Once agent services become payable and discoverable, they can compose. One agent can buy a data transformation from another agent, invoke a browser session, pay for a model call, produce a dataset, and sell the output into another workflow. This is where the web3-AI narrative becomes more than vibes. It becomes an agent service economy.
The biggest near-term opportunity in web3-AI may not be decentralized model training. It may not be on-chain inference. It may not even be tokenized agents. Those may all matter eventually, but the immediate opportunity is more concrete:
Build the economic, identity, and provenance layer around sandboxed agent execution.
This is attractive because the sandbox market is already forming. Builders do not need to convince the world that agents need computers; the market is doing that. The question is what happens once those computers need money, credentials, permissions, and receipts.
The first opportunity is the wallet-aware sandbox. Every sandbox session could be provisioned with a scoped wallet or payment capability. This wallet would not be a generic hot wallet tossed into an environment variable. It would be a controlled economic instrument attached to the task.
A wallet-aware sandbox might include:
This turns the sandbox into a bounded economic actor. The agent can pay for resources, but only inside a cage of rules. This is the agent equivalent of giving an employee a corporate card with limits, merchant restrictions, and receipt requirements.
The second opportunity is machine-payable service discovery. Today, APIs are usually monetized through accounts, API keys, dashboards, invoices, and enterprise contracts. Agents need something more dynamic. They should be able to discover a service, read the price, pay programmatically, receive access, and continue.
This matters especially for long-tail tools and data. A world of agentic workflows will need millions of small paid resources: niche datasets, domain-specific APIs, expert models, browser sessions, simulation engines, compliance checks, verification services, analytics tools, and micro-SaaS capabilities. Web3 payment rails make these services easier to expose to autonomous buyers.
The third opportunity is provenance. If an agent generates a research report, codebase, dataset, or trading signal, the output may need an execution record. Not necessarily a full public transcript, which could leak sensitive information, but a selective proof surface: hashes of inputs, hashes of outputs, runtime metadata, payment receipts, policy records, and signatures.
This becomes more important as agents produce artifacts that enter markets. A dataset generated by an agent may need licensing metadata. A trading strategy may need an audit trail. A code contribution may need a signed execution environment. A research artifact may need to prove which paid sources or tools were used. A compliance workflow may need to demonstrate that the agent operated under approved constraints.
The fourth opportunity is portable agent identity. Today, agents are often ephemeral. They exist as sessions inside applications. But if agents transact across services, their identity becomes valuable. An agent might accumulate a history of completed tasks, payment behavior, service ratings, verified outputs, and delegated permissions.
This is not identity in the human sense. It is closer to a cryptographic service passport. The identity says: this agent is owned by this user or organization, funded by this wallet, authorized for these capabilities, and associated with this history. For web3-AI, this could become a major primitive because it connects execution, payments, and reputation.
The fifth opportunity is runtime-agnostic coordination. The sandbox market will likely remain fragmented. One workload may run best on E2B, another on Daytona, another on Vercel Sandbox, another on Modal, another on Browserbase. The web3 layer should not bet on a single execution substrate. It should sit above them.
That creates room for runtime gateways that abstract over providers while preserving wallet policy, identity, payment, and provenance. The gateway chooses the runtime based on task requirements, but the economic layer remains portable.
The investment thesis is straightforward: if the sandbox is where agent action happens, then identity, spend, discovery, and provenance become monetizable control points around that action.
Web3-AI becomes compelling when agents stop being content generators and start becoming economic actors.
A practical architecture should be hybrid by design. The goal is not to force compute on-chain. The goal is to make off-chain agent execution economically programmable and selectively verifiable.
At a high level, the stack looks like this:
Another way to visualize it is as a control loop:
The architecture has seven layers.
The user or application defines the goal, constraints, and approval requirements. This is where intent enters the system. The user might ask for a report, a code change, a dataset, a transaction, or a workflow execution. The important point is that the task comes with constraints: time, budget, data access, tool access, and risk tolerance.
The agent controller is the cognitive loop. It plans, decomposes the task, selects tools, chooses when to spawn a sandbox, observes outputs, handles errors, and decides when human approval is needed. This layer may be built using an agent framework, a custom orchestrator, or model-provider tooling.
The policy engine translates human and organizational constraints into runtime rules. It decides what the agent can access, what it can spend, which tools it can use, which domains it can reach, which credentials it can invoke, and when it must stop for approval. In agentic systems, policy is not an afterthought. It is the difference between autonomy and chaos.
This is where action happens. The sandbox provides isolated compute, shell access, filesystem, browser sessions, package installation, process execution, network controls, logs, snapshots, and persistence. The runtime may be E2B, Daytona, Runloop, Modal, Vercel Sandbox, Browserbase, or another provider. The architecture should treat the runtime as replaceable, because different tasks will prefer different substrates.
The wallet layer gives the agent controlled economic agency. It enforces session budgets, per-transaction limits, approved counterparties, expiration rules, and receipts. In the ideal design, the agent never has unconstrained access to private keys. It receives a scoped capability to pay under policy.
The agent accesses tools, APIs, MCP servers, browser sessions, datasets, model endpoints, internal systems, and paid external services. Some are free. Some require authentication. Some require payment. The service layer becomes much more powerful when agents can pay and authenticate programmatically.
This layer records what happened in a privacy-aware way. It may store runtime metadata, task hashes, output hashes, payment receipts, policy versions, signed approvals, and selected logs. The purpose is not radical transparency. The purpose is selective accountability.
The elegant property of this architecture is that the web3 layer is narrow but high-leverage. It does not need to schedule every process or host every browser. It needs to coordinate money, identity, permissions, and proofs around execution.
The strongest objection is that cloud platforms may absorb the entire stack. This is plausible. Large cloud providers already control compute, identity, observability, billing, and enterprise distribution. If they add agent sandboxes, payment controls, browser infrastructure, and policy engines, much of the market could become vertically integrated.
A second objection is that conventional billing may be good enough. Many enterprise agents will operate inside a single company’s environment. They will use existing IAM, internal APIs, procurement contracts, and cloud billing. They may not need stablecoins, wallets, or open settlement rails.
A third objection is that web3 adds complexity. Wallets, signatures, gas, compliance, custody, fraud, and user education are all real obstacles. A beautiful architecture diagram does not eliminate operational friction. Many developers will choose the simplest thing that works, and the simplest thing is often an API key and a credit card.
A fourth objection is that verifiability can be overclaimed. A hash of an output does not prove the output is useful. A signed log does not prove the agent made good decisions. A TEE attestation does not prove the task was correct. Provenance is useful, but it is not magic.
A fifth objection is safety. Agent wallets create new failure modes. Agents can overspend, pay malicious services, get tricked by prompt injection, leak information, or transact under false assumptions. The more economic agency we give agents, the more important policy and human oversight become.
These objections are valid. But they do not kill the thesis. They refine it.
The right claim is not that every sandbox needs web3. The right claim is that web3 becomes useful when agents operate across trust boundaries. If an agent is entirely internal, conventional cloud controls may be enough. But when an agent discovers third-party services, pays independent providers, carries portable identity, sells outputs, or needs auditable receipts across organizations, open economic rails become more compelling.
Web3 is not necessary for all agent execution. It is highly relevant for agent commerce.
Every agent needs a computer. That statement sounds almost childish, but it is a deep product insight.
The first generation of AI products made models talk. The next generation will make models work. Work requires an environment. It requires files, browsers, commands, memory, credentials, policies, logs, and the ability to recover from mistakes. That is why agentic sandboxes are becoming a foundational layer of AI infrastructure.
But execution is only half the story. Once agents become workers, they also become economic actors. They need to buy resources, authenticate to services, operate under budgets, generate receipts, and produce ownable artifacts. This is where web3-AI has a practical opening.
The most compelling opportunity is not to put the model on-chain or pretend blockchains are better CPUs. The opportunity is to wrap sandboxed execution with programmable money, portable identity, transaction-aware policy, and selective provenance.
Cloud will likely host much of the agent’s body. Web3 can coordinate the economy around it.
In that stack, the sandbox is not a feature. It is the runtime. And the runtime is where the agent becomes real.
Share it with your community!
Start for free and receive $50 in credits to accelerate your AI software engineering.
© 2025 Runloop AI, Inc.
© 2026 Runloop AI, Inc.
