Agent Cloud

Blog

Self-Serve Compute for LLM Agents: Why Agents Need Their Own Infrastructure

The bottleneck is the human

LLM agents are getting remarkably capable at writing code, running experiments, and orchestrating complex workflows. But the moment an agent needs compute — a build server, a test environment, an isolated sandbox to run untrusted code — it stops and waits for a human.

The human has to provision the VM, configure SSH access, pass credentials back to the agent, and eventually remember to tear everything down. This manual loop is the single biggest bottleneck in agent-driven workflows today. It breaks the autonomy that makes agents useful in the first place.

Self-serve compute for LLM agents means removing that bottleneck entirely. The agent handles the full lifecycle — discovery, signup, provisioning, usage, and teardown — without a human in the loop.

What "self-serve" actually means for an agent

When we say self-serve compute for humans, we mean a dashboard where someone can click buttons and spin up resources. That definition is useless for an LLM agent. Agents don't click buttons. They call APIs.

Self-serve compute for an LLM agent means five things, all available via API with no human intervention:

  • Discover. The agent finds the compute provider through machine-readable mechanisms — an OpenAPI spec, an llms.txt file, a tool definition it can install.
  • Sign up. The agent creates an account with a single POST request. No email verification, no CAPTCHA, no OAuth redirect flow.
  • Provision. The agent requests a VM, container, or sandbox and gets back connection details — IP, SSH key, or API endpoint — in seconds.
  • Use. The agent SSHs in, runs commands, deploys code, or interacts via API. The compute is a standard Linux environment with no artificial restrictions on what the agent can do inside it.
  • Tear down. When the task is done, the agent destroys the resource. No orphaned infrastructure, no forgotten bills.

Every step happens programmatically. The agent never leaves its conversation context to go fiddle with a web console.

Why existing cloud platforms don't work

In theory, an LLM agent could use AWS or GCP. In practice, the onboarding flow for every major cloud provider is designed to keep machines out:

  • Human-only signup. Creating an AWS account requires a credit card, phone verification, and CAPTCHA. An agent cannot complete this flow.
  • Dashboard-first configuration. Even after signup, most platforms assume you'll configure networking, security groups, and IAM through a web console. The CLI exists, but it assumes a human installed and authenticated it first.
  • OAuth and SSO flows. Modern cloud platforms use browser-based authentication. An agent has no browser session to redirect.
  • Billing requires human identity. Every provider gates resource creation behind a verified payment method tied to a human identity. There is no concept of "let the agent try it first, bill the human later."

These aren't bugs — they're deliberate design choices for a world where humans are the only infrastructure operators. But that world is ending. Agents need a platform built for them from the ground up.

What self-serve compute enables

When agents can provision and tear down compute autonomously, entirely new workflows become possible:

  • Agents that spin up test environments. A coding agent can create an isolated VM, run a full test suite against a branch, collect the results, and destroy the VM — all within a single task. No CI/CD pipeline to configure. No shared runner to contend with.
  • Agents that run code in isolation. Instead of executing untrusted code on the host machine, an agent provisions a sandboxed VM, runs the code there, and captures output. The blast radius of any failure is contained to a disposable instance.
  • Agents that deploy services. An orchestration agent can provision a VM, deploy a service, configure DNS, run health checks, and hand the endpoint back to the user — or to another agent.
  • Agents that research autonomously. A research agent can spin up an isolated environment with a browser, crawl sources, process data, and tear everything down when the report is complete. No long-lived infrastructure to maintain.

The common thread: compute becomes ephemeral and task-scoped. Agents create exactly what they need, use it, and clean up. This is how agents naturally want to work — the infrastructure just hasn't supported it until now.

The sandbox model: trust through limits, not gates

The obvious objection to self-serve compute for agents is abuse. If any LLM can sign up and get a VM with no human verification, what stops bad actors from spinning up thousands of instances for crypto mining or spam relay?

The answer is the sandbox model. Instead of making signup hard, you make the free tier small and tightly constrained:

  • One micro VM at a time — 1 vCPU, 1 GB RAM
  • 72 hour maximum lifetime with automatic cleanup
  • Restricted outbound networking — no SMTP, limited ports
  • Hard rate limits on signup by IP and ASN
  • Account expires in 7 days unless upgraded with a real payment method

This is enough compute for an agent to prove a workload — run a build, execute a test suite, prototype a deployment. It's not enough to be worth abusing at scale. The economics of abuse simply don't work when the sandbox is this small and this short-lived.

When the agent needs more — more VMs, more CPU, longer lifetimes — it asks the human operator to approve a paid upgrade. Humans only appear at the moment that actually requires human judgment: spending money.

The full lifecycle in practice

Here is what self-serve compute looks like end to end. The agent discovers the API, signs up, and provisions a VM in a single sequence of API calls:

# Agent discovers the API, signs up, and provisions a VM
# — all in a single conversation, no human needed

curl -X POST https://api.asiagent.cloud/v1/agent/signup \
  -H "content-type: application/json" \
  -d '{"agent_name": "build-agent", "agent_type": "claude", "terms_accepted": true}'

# Response includes an API key and sandbox limits
# The agent immediately provisions compute:

curl -X POST https://api.asiagent.cloud/v1/instances \
  -H "authorization: Bearer asi_sandbox_..." \
  -H "content-type: application/json" \
  -d '{"image": "ubuntu-24.04", "size": "micro"}'

The agent works inside the VM for as long as the task requires. When it's done:

# When the task is done, the agent cleans up after itself

curl -X DELETE https://api.asiagent.cloud/v1/instances/inst_x7y8z9 \
  -H "authorization: Bearer asi_sandbox_..."

# No orphaned resources. No forgotten VMs burning credits.
# The sandbox also auto-expires after 72 hours as a safety net.

The entire lifecycle — from zero to running server to clean teardown — happens without a human touching anything. See the quickstart guide for the complete flow.

Real examples

These are not hypothetical. These are the use cases we see agents attempting today, often unsuccessfully because the infrastructure doesn't support them:

The coding agent that needs a build server

A Claude Code session is working on a Rust project. The build takes 10 minutes on the developer's laptop and blocks the conversation. With self-serve compute, the agent provisions a 4-vCPU VM, clones the repo, runs cargo build in parallel, and reports the results back. The developer's machine stays responsive. The build VM is destroyed when the job finishes.

The research agent that needs an isolated browser

An agent tasked with competitive analysis needs to browse dozens of websites, extract pricing data, and compile a report. Running a headless browser on the host machine is a security risk. With self-serve compute, the agent provisions a sandbox VM, installs Chromium, crawls the target sites in isolation, extracts the data, and tears down the environment. The host machine is never exposed to untrusted web content.

The orchestration agent managing multiple VMs

A deployment agent needs to test a microservices application. It provisions three VMs — one for the API server, one for the database, one for the message queue — deploys the stack, runs integration tests across all three, collects logs, and tears everything down. What would take a human 30 minutes of console clicking happens in under 2 minutes of API calls.

Where this is going: agents as infrastructure customers

Today, agents are infrastructure users. A human sets up the environment, grants the agent access, and supervises the session. The agent operates within boundaries that a human defined and a human maintains.

Self-serve compute is the first step toward agents as infrastructure customers — entities that independently discover providers, evaluate offerings, provision resources, manage costs, and make purchasing decisions (within human-approved budgets).

This shift has implications beyond just compute. Once agents can self-serve VMs, the same pattern extends to storage, networking, databases, and eventually entire application stacks. The agent becomes the operator. The human becomes the sponsor — setting budgets, approving escalations, and reviewing outcomes.

We think this is inevitable. The question is not whether agents will become infrastructure customers, but which infrastructure providers will be ready for them when they do.

Get started

Agent Cloud is built for this future. Follow the quickstart to give your agent self-serve compute in under five minutes, read about agent-native cloud, or see the pricing to understand what the sandbox includes and what upgrades cost.