Every cloud you can buy was built for a person at a keyboard.

You cannot review an agent's code and know what it will do.

Same code, same permissions, a different prompt — and it takes a different action. Reading the source told you what a program would do; it tells you almost nothing about an agent. So the guarantee cannot come from the review it passed before it shipped. It has to come from what the agent is allowed to touch while it is running, and from what is kept about what it did. That is a different job from serving a request, which arrives and is gone, and a different job from running a deployment, which sits there until you change it.

• A task can stop and pick the work back up later with what it knew intact. This matters more here than it does for a job queue: an agent that starts over from nothing does not resume, it re-decides — and nothing promises it decides the same way twice.
• How many copies are running is decided by the agent, mid-task — not by you, in a capacity plan written the week before. Not because forecasting is tedious, but because the number is a function of what the model just decided to do, and nobody holds that number in advance, including the model.
• The worst thing an agent does never throws an error — it succeeds at the wrong thing. So what is kept is the record of what it decided and why, not only of what failed, because monitoring built to catch exceptions is waiting for one that never comes.

Storage was never the problem. Disagreement is.

An agent's knowledge is usually spread across systems that quietly disagree: what it retrieves sits in one, what the business considers true sits in another, what it remembers about a customer sits in a third, and who is allowed to see any of it sits in a fourth. An agent is only as right as the least fresh copy it can reach. So it reads the older one, and your customer is told something confidently wrong by a system in which every component passed its tests. Here, what is retrieved, what is recorded and what is remembered are one thing under one set of permissions — so there is no older copy to read.

• What an agent retrieves, what the business considers true, and what the agent remembers are the same object — not three copies held in step by a job that sometimes fails.
• Whether an agent may see something is decided when it asks, not by the account it borrowed in order to ask — so the same agent working for two customers sees two different worlds.
• Nothing anywhere raises an error when two copies drift apart. That is why the second copy had to go, rather than the sync between them being made more reliable.

A budget an agent cannot exceed has to live below the agent, not inside its prompt.

You are not shipping an app any more. You are handing a customer something that spends. The first day it runs on someone else's behalf, three questions arrive together: whose data was that, who pays for these tokens, and what stops it spending more. A cloud that bills you for machines cannot answer any of the three, so attribution becomes a spreadsheet that grows with every customer you win. Here the unit is the task — one agent's run, attributed to the customer it ran for, charged against a ceiling that was set outside it.

• Anything an agent can talk itself out of was never a limit — it was a suggestion written in the same language it argues in. So the ceiling is enforced by the platform, underneath the agent, where its reasoning does not reach.
• The bill answers what a task cost and who it ran for, not what an instance cost — which is the question you are actually asked when a customer disputes a number.
• Your customers' customers are kept apart by the platform, not by isolation code you write again for every product you launch. It cannot go on being your code, because the isolation now has to hold against something that improvises: your tests cover the inputs you thought of, and producing the ones you did not is the entire value of the agent.

Defaults are chosen at the bottom, or they are not chosen at all.

Execution that is untrusted until proven otherwise. Outbound traffic that is closed until something opens it. A contained environment thrown away after a single task. None of these is a feature you install on top of primitives designed for a trusted person who deploys once a week — a default is what happens when nobody configures anything, so it gets decided underneath everything, before anything above it exists. This is also what makes running the whole thing again cheap, which is where the circuit starts over.

• Outbound is closed until something opens it. A list of banned destinations is the wrong shape, because the address an attacker picks is precisely the one nobody thought to forbid.
• A task gets its own contained environment, and it is thrown away when the task ends. Not for tidiness — what just ran was written by a model minutes ago and read by nobody, so the only safe assumption is that it should not outlive the task that asked for it.
• This is not a friendlier surface over someone else's defaults. Ours go all the way down, which is the only reason the three parts above can promise what they promise.