One Agent Per Spreadsheet Cell Requires Elastic, Secure Infrastructure

? akshat-bubna uses a financial analyst’s portfolio spreadsheet to make the infrastructure requirements concrete. An analyst might need to examine every company in a fund’s portfolio, connect each one to its data sources, and run company-specific analysis. Work that used to take days, he says, could instead be distributed across agents—one for each cell.

Bubna points to Hebbia as an example: its product lets users run a query across a spreadsheet in which every cell is backed by a separate agent. The interface shows company returns and performance assessments alongside numbered agents. The challenge, he argues, is not just launching many agents. It is giving them a secure place to execute, a way to share work, and the ability to start quickly and shut down when the query is done.

In the architecture Bubna describes, each agent has a sandbox: a secure environment for running untrusted code. The agent harness—the loop that calls the model, selects and runs tools, and continues the task—runs separately from the environment where tool calls execute. The harness calls the model API, chooses the next tool, and manages the task’s loop. The sandbox can contain multiple containers or micro VMs, including a main container for the harness and a sidecar for tool execution. The separation keeps the code that decides what to do apart from the environment that runs tool calls, which Bubna says matters for security and isolation.

Shared storage connects parts of this architecture that need to work together. Agents can use volumes for documents, working files, and generated artifacts; the main container and sidecar can also share files. The storage arrangement can reflect the task. In a spreadsheet, for example, agents in the same row might share a volume and collaborate on one company’s analysis. With thousands of cells, the system must launch many agents quickly and bring them back down when the query ends.

Bubna describes Modal as a platform of infrastructure primitives built for AI applications, including inference, sandboxes, training, and functions. The company built its own filesystems, scheduling, and runtime, he says. In this talk, sandboxes are the focus: not a complete agent application, but an execution environment that can be combined with other pieces to meet the application’s needs.

Agents need workspaces shaped around their jobs, Bubna says. A coding agent needs a code repository, dependencies, and development services such as Postgres or Redis. Ramp Inspect, Ramp’s internal coding agent, is one example; Bubna says it pushes almost every PR at Ramp. An accounting agent needs documents, workpapers, and scripts together. A game-development agent needs a game engine and its assets. In each case, the workspace gathers the resources the agent needs to work on the task.

The workspace also has to persist while the agent waits. In Bubna’s accounting example, documents arrive and trigger work; then the agent may need to wait for an accountant’s response. That pause could last days. When the response comes, the agent should resume from where it left off, with its prior state intact.

Keeping the state does not mean keeping the compute running. Compute is expensive, Bubna says, so it should be active only while the agent is working. The persistence mechanism depends on what needs to survive: sometimes the whole root filesystem should be snapshotted; sometimes only a directory, such as a node_modules folder, needs to persist while the base image is upgraded; and sometimes the right model is a shared filesystem or volume. These are different requirements: resuming the same environment, preserving one useful part of it, or sharing files across agents.

Resource needs vary widely, both between agents and over time within a single agent. Bubna shares data from Ramp Inspect showing CPU and memory use across 57 sandboxes from the same application on the same day. A compilation or memory-heavy analysis can produce a short-lived spike; other phases use much less. Peak needs also differ from sandbox to sandbox.

If every sandbox were provisioned for its peak, Bubna says, each would need something like 15 CPU cores and 15 gigabytes of RAM. That would not make economic sense. The infrastructure challenge is to let users avoid fixing resource requests in advance, while still supplying resources reliably when the sandbox needs them—and charging for them only during that period. The point of the Ramp charts is not that every task needs the same smaller allocation; it is that one fixed allocation is a poor fit for workloads whose demand shifts across agents and over time.

The same elasticity applies to specialized compute. Bubna points to Claude Science, which he says ships with a Modal integration. When it needs intensive computation—preprocessing data on CPUs or running a scientific model on GPUs—it can offload the work to a sandbox. He sees similar GPU needs in game design, video editing, and 3D development, including CAD. Over time, he says, agents may also need TPUs or AMD accelerators.

Bubna also connects GPU sandboxes to recursive self-improvement. In an example described in a Modal blog post, an agent is given sandboxes to search for improvements in model training. It can switch GPUs, run ablations in parallel, and conduct many experiments, he says, reaching its target quickly. The infrastructure implication is that an agent needs more than a fixed machine: it needs to be able to call on different compute resources as the work changes, including parallel environments for experiments.

Agents increasingly work alongside subagents and humans on shared tasks. Bubna’s accounting example shows a parent agent, a subagent, and an accountant all accessing a shared workpaper. That calls for filesystems that are fast, consistent, and predictable enough for people and agents to work against together.

He describes a related pattern in agent memory. An agent can read and update its memories during a run, while a background task—sometimes called “dreaming”—consolidates those memories for later use. In Bubna’s account, this is also a filesystem problem: the information is stored as files, and the storage needs to perform well.

Access to tools and data needs equally deliberate boundaries. Agents can make mistakes, Bubna says, and may leak sensitive information without recognizing what they are doing. Operators therefore need controls over which IP addresses can reach an agent, how it authenticates, and which domains it can contact. When credentials are required, they should be injected in a way that prevents the agent from reading and later exfiltrating them.

Domain allowlists may not be specific enough. Some users want to limit not only which service an agent can reach, but which paths or operations it can use—for example, on Datadog or GitHub. Bubna describes sidecars as a way to run a lightweight, customer-controlled proxy beside the agent, with rules tailored to those operations. A displayed example from Ramp’s principal software engineer, Zach Bruggeman, describes the need to monitor and restrict a coding agent’s outbound requests.

Bruggeman’s displayed example makes the rule-level distinction concrete: a proxy beside the agent can allow specified Datadog and GitHub paths and drop requests that are not on the allowlist. The control is not simply whether the agent can reach a service; it can be what the agent is permitted to do there.

Observability is not only for the people operating infrastructure. Bubna argues that agents should be able to inspect logs, metrics, and budgets themselves. In an automated training workflow, if a run fails, the agent should be able to read the logs, reason about the failure, and try again with different parameters. While a run is underway, it should be able to check metrics such as GPU utilization, detect whether it has stalled, and see whether spending is getting too high.

That changes observability from a human-facing dashboard into part of the agent’s working environment. The agent needs enough visibility to diagnose and adjust its own work; humans still need the same information to monitor it. Bubna presents logs, metrics, and budget data as inputs agents can use to decide what to do next.

Bubna rejects the idea of using an AI coding assistant to “vibe code” a sandbox platform. His reasons are reliability, security, and scale. Even with AI, he says, it is difficult to reason through a system’s feedback loops and rare failure cases. Security requires ongoing work to examine the boundaries and keep them defensible as the environment changes. And scale depends on engineering decisions that need to hold up when demand grows.

He cites Modal’s experience as an indication of the platform load these systems are already handling: about 20 million snapshots per week, 8.4 petabytes of snapshot data processed per day, and nearly 2.6 million volumes created per week.

A single customer’s personal-assistant workload presents a separate set of demands:

Those figures describe one customer workload, not Modal’s platform-wide totals. Bubna adds that this capacity cannot always come from one cloud provider. CPU supply, not only GPU supply, is becoming constrained, he says. Modal aggregates capacity from multiple hyperscalers and neoclouds so users can access CPUs around the world rather than depend on a single provider.

Bubna’s longer-term picture separates the agent harness—the “brains”—from the sandbox or runtime—the “hands.” Harnesses can spin up environments for the task at hand, run code, snapshot the resulting state, and retain it as an artifact for later. They can create new environments or adapt existing ones as requirements change. The harness manages the task, while the environment is something it can select and shape around the work.

He frames this as a shift in the familiar progression from “pets” to “cattle.” Early services were pets: bespoke deployments that needed individual care. Containerization and Kubernetes made servers more like cattle—interchangeable instances that could scale up or down and be replaced when they failed. Bubna says many agent deployments now rely on this kind of homogeneous environment.

But he thinks the model is limiting. Agents can reason about dynamic environments, create many when needed, snapshot them, and work across them. The next stage, in an analogy he credits to Swyx, may look less like a herd of uniform machines and more like an ocean of self-evolving organisms working with one another. His claim is that stronger primitives for compute, storage, and networking will let agents do more: creating environments, collaborating, and adapting their resources to the work.