What an agent needs from a cloud

Most conversations about agent infrastructure start and end with accelerators. That is understandable: the model is the expensive part, and GPU supply has set the pace of the industry for three years. But a model answering a prompt is not an agent doing a job. An agent that reconciles invoices, answers customers or runs a release has to keep working between prompts, be reachable, spend money and stay inside rules. Each of those is an infrastructure problem in its own right, and none of them is solved by buying more GPUs.

There are four of them.

Compute that keeps running

An agent is a process, not a request. It holds a working directory, a browser session, half-finished files and a plan. It calls tools, waits on people and resumes. That needs a sandbox: an isolated machine the agent can write to and run code in without touching anyone else's, and which survives long enough to finish the work.

Most of what happens inside that sandbox is ordinary CPU work. A study first posted to arXiv in November 2025 profiled five representative agent workloads and found that CPU-side tool processing accounted for up to 90.6% of total latency. Hardware vendors have reached the same conclusion from the other direction. When NVIDIA introduced Vera in May 2026, it described it as a CPU built for agents, and named tool use and sandbox execution as work that sits on the critical path.

Two properties matter. Isolation, because an agent runs code nobody reviewed, often written by a model. And persistence, because a sandbox that is wiped every few minutes turns a long task into a series of restarts. The market differs most on the second.

An address and a record

People at work have an email address, a phone number and a paper trail. Agents need the equivalent. Another business, another agent or a customer has to be able to reach the agent, and the business that runs it has to be able to see afterwards what it said and to whom.

On the open web this is becoming explicit. Cloudflare reports that operators including OpenAI, Google and AWS now cryptographically sign their agents' requests, so a site can recognise an agent without guessing from its IP address. Inside the enterprise, Microsoft gives each hosted agent in Foundry a dedicated Entra identity. Identity answers who an agent is. A record answers what it did, and that second half is the one auditors, regulators and customers will ask for.

A way to pay

An agent that buys data, calls a paid API or settles a supplier invoice needs a payment method it can use without a person typing in card details each time. The payments industry is building for this. Google published the Agent Payments Protocol, which uses cryptographically signed mandates as proof of what a user authorised. Visa describes Intelligent Commerce as its platform for agentic commerce, and in June 2026 added a directory of agents and merchants it has verified. Cloudflare has put HTTP 402 Payment Required to work through the open x402 protocol, so that an agent can pay a seller directly for a single request.

The common thread is that payment is moving into the protocol an agent already speaks, rather than living in a checkout page built for people.

Limits

The fourth requirement is the one that decides whether a business lets an agent near anything that matters. An owner needs to say what the agent may do, how much it may spend, which systems it may touch and when it must stop and ask.

Regulators are converging on this. Singapore's IMDA, in its governance framework for agentic AI, tells organisations to bound risks early by setting limits on agent autonomy, tools and data access, and to trigger human approval at significant checkpoints. The framework was launched in January 2026 and updated in May. In the UK, the FCA's review of AI in retail finance found that a fifth of consumers would be likely to use AI that acts on its own within pre-set goals, and that the same people worry about trust and control. Limits are what make that trust possible.

How the market splits today

Three groups of vendors cover parts of this.

Hyperscaler agent runtimes host the agent close to the provider's models and identity system. AWS runs each AgentCore session in a dedicated microVM with isolated CPU, memory and filesystem; a session ends after 15 minutes idle or 8 hours in total, and AWS says session state should not be relied on for long-term durability. Microsoft's Foundry Agent Service runs hosted agents as containers, with each session in a VM-isolated sandbox when connected to a customer network. Google's Agent Runtime offers managed sessions and a memory bank. These are strong on identity and integration with each provider's own estate, and they tie the agent to it.

Sandbox vendors sell the compute and little else. E2B describes each sandbox as a secure Linux VM created on demand, and keeps paused sandboxes, memory included, until they are killed. Modal runs sandboxes on gVisor by default, with a default lifetime of five minutes, extendable to 24 hours, and recommends snapshots for anything longer. They are good at isolation and fast start-up. Address, payment and limits are left to the customer.

Framework platforms host agents written with a particular framework. LangChain's LangSmith Deployment, formerly LangGraph Platform, provides infrastructure for long-running agent workloads built with its tools. Convenient when the framework fits; the agent's state and operations follow the framework's choices.

Each group solves one or two of the four. None of them, on its own, gives an agent all four on infrastructure the customer can reason about end to end.

What this means for CTOs

Plan capacity around the agent, not the model. Model calls are bursty and can come from an API; the sandbox, the browser and the tool calls are steady and CPU-bound, and they are where an agent spends most of its time.

Read the lifetime limits before you design the workflow. An 8-hour session ceiling or a 24-hour sandbox limit is a design constraint. A task that waits two days for a person to approve something has to survive it.

Treat address, payment and limits as platform features, not application code. If every team builds its own mailbox integration, its own card handling and its own spending rules, you will have as many audit trails as teams, and no single view of what your agents are doing.

Ask where the machines are. For workloads under UK, EU or Singapore supervision, the answer to where an agent ran, and on whose hardware, is part of the compliance file.

Where Praecise fits

Praecise Cloud provides compute, MCP servers and backends for agents on hardware Praecise owns. Agents are built from source, placed behind the edge, supervised and reversible. Each agent gets an address and a searchable record through Praecise Inbox, on a domain the business verified once, so a person can open and search everything it said. Skerry gives agents payment rails, including stablecoin settlement, with Bridge and Stripe performing the regulated acts under their own licences. Ipnops runs agents across payments, accounting, commerce and mail inside limits the owner sets, acting with permission, never ownership, and leaving a record of every run. Underneath, Praecise Metal places, powers and cools the machines to measured targets, on Praecise Furcate and the open-source Furcate operating system.