Why Agents Need Their Own Compute

The first agent you build may run happily on your laptop. The first agent you run for real has a different problem: it must work for many people without letting one person’s files, code, or secrets touch another’s. That is not mainly a model problem or a prompt problem. It is a compute problem. Agents need their own isolated place to work because the useful things they do, such as writing files, running code, and holding context, are exactly the things that become dangerous when shared.

Compute is where the work actually happens

Compute is the computer that runs a program: processor time, memory, storage, and network access inside a data center. When you open a web application, the application is not running on your laptop in any meaningful sense. Your browser is showing the result of work done on someone else’s compute.

The important question is not whether compute exists. It always does. The important question is what boundary surrounds it. Is your task running in a private environment, or is it sharing a running process, filesystem, memory space, or container with other customers’ tasks?

For simple web traffic, sharing can be efficient and safe. For agents, the same sharing pattern changes the risk because the workload leaves evidence of itself behind.

Ordinary websites are designed to forget

A typical website request is stateless. Stateless means each request carries what the server needs to answer it, and the running server instance does not need to remember the visitor afterward. A browser asks for a page, the server answers, and that particular exchange is over.

This is why web services scale so well. One running instance can handle a stream of requests from many people because those requests are short, independent, and disposable. The next request from the same person may be handled by a different instance, and the user should not notice.

Long-lived information, such as account records or shopping carts, usually belongs in a database, cache, or storage service built for shared access. It does not live as loose files and secrets in the web server’s working directory.

Agents are stateful by nature

An artificial intelligence agent is not just a web request with a larger answer. It takes on a task and works through many steps. It may plan, call tools, inspect the results, revise its plan, and continue.

To do that, an agent often needs a working directory, temporary files, downloaded material, generated code, execution logs, tool credentials, and the conversation or task history. This is state. Stateful means the workload accumulates information while it runs, and later steps depend on what earlier steps left behind.

That state is not incidental. It is the workspace of the agent. Remove it and the agent becomes less useful. Share it carelessly and the agent becomes unsafe.

The shared-instance failure mode

Now place two customers’ agents on the same running instance. Customer A’s agent writes a file containing private data. It holds a credential for a business system. It runs a script to transform a spreadsheet. Customer B’s agent is running beside it in the same environment.

If the boundary is only application logic, naming conventions, or a polite rule that one job should not look at another job’s files, the design is fragile. Bugs happen. Tools misbehave. Generated code may not respect assumptions. A path error, permission mistake, or escaped process can turn shared compute into shared exposure.

This is a cross-tenant leak: one customer’s data, code, or secrets become reachable by another customer’s workload. The risk is sharper for agents because they may execute code that was generated during the task or influenced by untrusted input.

Isolation is a hard boundary, not good manners

Isolation means each unit of work gets a private environment that other units of work cannot see or modify. In the agent case, the useful unit is often a session or task run: one agent doing one piece of work for one user or customer.

The important word is enforced. Strong isolation is not merely two programs agreeing to stay apart. It is a boundary below the program: separate filesystems, process spaces, network rules, identities, and resource limits, commonly backed by the same kind of hardware-enforced separation used by virtual machines in cloud computing.

A sandbox is an isolated environment where code can run, write files, and fail without affecting the host system or other sandboxes. For agents, the sandbox is not an extra feature. It is the safety mechanism that lets the agent use powerful tools without turning every task into a shared-risk event.

Own compute does not have to mean a dedicated physical server for every user. It means the agent receives its own isolated slice of compute for the duration of the work, with boundaries strong enough that another customer’s workload cannot cross them.

• Separate working directories so files do not mingle.
• Separate execution boundaries so one process cannot inspect or control another.
• Limited network access so a hijacked task cannot freely reach internal systems.
• Short-lived environments so leftover state is destroyed when the task ends.

Agents add a manipulation problem

Agents are unusual because the data they read can influence what they do next. A document, web page, email, tool result, or support ticket may contain instructions that try to steer the agent away from the user’s intent. This class of attack is often called prompt injection, meaning malicious or misleading instructions are smuggled into content the model processes.

Prompt injection matters because agents can have agency: the ability to take actions through tools, not just produce text. If a manipulated agent can write files, run code, and use credentials, then the damage depends on what its compute environment can reach.

Per-session isolation changes the shape of the incident. A tricked agent may still damage its own temporary workspace. It may produce a bad result. It may waste time. But it should not be able to read another customer’s files, steal another customer’s credentials, or compromise a shared instance used by many sessions.

In practice, isolation does not replace careful tool permissions, input handling, logging, and human approval for high-risk actions. It gives those controls a floor. When higher-level defenses fail, the sandbox is what keeps the failure small.

The decisions leaders and builders actually face

The architectural decision is not simply whether to use agents. It is where to let them act. A low-risk assistant that summarizes public documentation has a different compute requirement from an agent that downloads customer data, writes code, and connects to production systems.

Teams should classify agent workloads by what they can touch and what they can execute. The more an agent can read, write, run, or authenticate to, the stronger its isolation should be. The safest default for customer-facing or sensitive work is one isolated sandbox per session, destroyed after completion unless there is a deliberate reason to persist state elsewhere.

Cost and latency matter, but they should be compared with the real alternative. A cheap shared instance that mixes tenants may only look efficient because it has moved security risk off the spreadsheet. Good designs make the isolation boundary explicit, then optimize startup time, pooling, storage, and scheduling around that boundary.

• Ask whether the agent handles customer, employee, financial, health, source code, or credential data.
• Ask whether the agent can run generated code or invoke tools that change systems.
• Ask whether one customer’s session can ever share a writable environment with another customer’s session.
• Ask what is preserved after a session ends, where it is stored, and who can access it.
• Ask how quickly a compromised or malfunctioning session can be destroyed and audited.

A simple test for this week

Pick one real agent workflow and trace it from start to finish. Do not start with the model. Start with the machine. When the agent writes a scratch file, where does the file go? When it runs code, what process boundary contains it? When it calls a tool, where are the credentials held? When the job ends, what is deleted?

Then ask the uncomfortable question: if this agent were tricked midway through the task, what is the largest thing it could reach? If the answer is only its own short-lived sandbox, the architecture is on the right path. If the answer includes another customer’s files, a shared working directory, long-lived secrets, or a common runtime, the compute model is the urgent risk.

The lesson is simple but easy to miss: agents need their own compute because agents create and use state. Once a workload remembers, writes, and executes, isolation stops being a luxury and becomes the safe default.

Glossary

Compute

The processor, memory, storage, and network resources that run a program, usually inside a data center.

Central processing unit

The main processor in a computer that executes instructions for running programs.

Instance

One running copy of a program or environment on compute resources.

Stateless

A design where each request contains what it needs and the running instance does not retain private working state afterward.

Stateful

A design where a workload accumulates information, files, memory, or context that later steps depend on.

Sandbox

An isolated environment where code can run and write files without being able to affect other environments.

Virtual machine

A software-defined computer with strong isolation from other virtual machines on the same physical hardware.

Cross-tenant leak

A failure where one customer’s data, code, or secrets become reachable by another customer’s workload.

Prompt injection

An attack where instructions hidden in content try to manipulate an artificial intelligence system into taking unintended actions.