What AI agents actually need from infrastructure: 7 requirements, and where human-first hosting gets in the way

Most hosting was designed around a person at a keyboard: a sign-up form, a card, a dashboard, an email when something goes wrong. An AI agent that needs compute doesn't fit any of those steps. It can't solve a captcha, it can't tell a maintenance page from a broken one, and it won't notice that it has created the same server forty times.

It's tempting to say "just give it an API". That's the first requirement, not the last. Below are seven that we think matter, from building our own MCP server and REST API for agents. For each: what goes wrong without it.

1. Everything an agent needs is programmable

Creating, inspecting, resizing and deleting resources has to work without a browser. That includes the dull parts: finding out the price before buying, checking whether a location has capacity, reading the password of a new machine, cancelling.

Without it: the agent gets 80% of the way and stops at the one step that needs a click, and a human has to finish the job anyway. A partial API is often worse than none, because it invites automation that can't complete.

2. Errors a program can act on

An agent reads a response and decides what to do next. A JSON body with a stable code (402 insufficient_balance, 409 sandbox_paused, 429 budget_exceeded with the time it resets) is something it can branch on. An HTML error page, or a 500 with a vague message, leaves it guessing: often retrying something that will never succeed.

Without it: retry loops. The most expensive agent failures tend not to be wrong decisions; they are the same failing call repeated thousands of times.

3. Payment without a human in the loop

Card payments are full of steps built to confirm a person is present: 3-D Secure codes, bank app confirmations, identity checks. Those are good for fraud prevention and impossible for software. A prepaid balance, topped up in advance (in our case, often with stablecoins), lets an agent pay for what it uses without a human approving each charge.

Without it: either a human approves every purchase, which defeats the point, or someone gives an agent a card, which is a risk nobody should take.

4. Hard limits on spending

A prepaid balance caps the worst case at whatever is in it. That can still be a lot. A daily and monthly cap, in dollars, enforced by the platform rather than the agent's own good intentions, turns a looping agent into a small loss. The cap should fail loudly, with an error the agent recognises, and stop or pause what it's running.

Without it: you find out about the loop from the balance. Our sandbox billing has caps for this reason, and the MCP guardrails page suggests which actions should need a human's approval at all.

5. Compute at the right granularity

Agents produce three very different kinds of work:

• Seconds: run a generated snippet, check an answer, try a fix.
• Hours: an evaluation, a scrape, a long build.
• Always on: a bot, an API, a scheduled worker.

A platform that offers only monthly servers makes the first kind absurdly expensive; one that offers only short-lived sandboxes makes the third kind fragile. A 20-second task on a machine billed by the hour pays for 59 minutes of nothing. How per-second billing works shows where each model stops making sense.

Without it: agents either overpay for short work or run long-lived services on infrastructure that wasn't meant to stay up.

6. Isolation by default

Code an agent writes is code nobody has reviewed. It should run somewhere that holds nothing of value: not the agent's own host, not a server with your keys, not the machine that sends your email. In practice that means a separate VM or microVM per task, deleted afterwards. Isolation levels for untrusted code compares the options; Firecracker microVMs explained covers why a kernel of its own matters.

Without it: the first prompt injection that makes it into generated code has access to everything the agent's host can reach.

7. Visibility and an off switch

The human responsible for an agent needs to see what it did and stop it quickly. That means per-resource usage and cost, a list of everything the agent created, and a way to delete all of it. Credentials should be revocable and short-lived enough that a leaked one isn't valid forever, with a way to refresh them that doesn't need a person.

Without it: cleanup becomes archaeology. Forgotten resources keep billing; a leaked token keeps working.

What agents don't need

Equally telling is what doesn't help: dashboards designed to upsell, onboarding emails, plans whose real limits are in a footnote, prices shown only after sign-up. None of it is readable by software, and some of it is actively misleading to a model that takes text literally.

What's still unsolved

Not everything here is a solved engineering problem.

• Accountability. Someone is responsible for what an agent does with an account. Platforms need a way to tie automated activity to a responsible person without forcing that person through every step.
• Abuse. Open, fully automated sign-up is exactly what abusers want too. Every platform that serves agents is balancing frictionless access against farming and mining, and none has a perfect answer.
• Long flows. Agents still fail more often on ten-step processes than on single calls. Infrastructure can help by making each step idempotent and its state easy to query, so a retry resumes rather than duplicates.

Where we've landed

We've tried to build for these requirements rather than around them: an MCP server and REST API that cover the full lifecycle, machine-readable errors, a prepaid balance, spending caps, per-second code sandboxes for short work and monthly servers such as the AI agent plan for long-running work. A walk-through of the sandbox side is in sandbox for AI agents. We'd rather you judge the list on its own merits; it's a useful checklist for any platform you let an agent loose on.