What is an AI agent cloud? A practical definition

The core idea

An AI agent cloud is not a new type of server. It is a set of services that let you write a small program that talks to an event source, does some computation, and then publishes a result. The platform gives that program a sandbox, a persistent identity, and the ability to talk to other services on your behalf. The agent is the unit of deployment, the unit of scaling, and the unit of billing.

When we built the platform we started from the same problem that most teams face: they want to run an AI-powered bot that watches a queue, processes a document, or answers a question, but they do not want to manage the underlying infrastructure. The answer we found was to expose a simple runtime that hides the complexity of containers, networking, and key management. That runtime is what we call the AI agent cloud.

What an agent looks like

An agent is a container image that follows a small contract. The contract is a single entry point that receives an event payload, runs a loop, and writes back to an output channel. The image can bundle any binary, any language runtime, or any model file. The only requirement is that the agent can start quickly, stay idle until it receives work, and shut down when it is not needed.

The platform supplies the following to every agent:

• Compute - a CPU share and a memory quota that are metered per second. The platform scales the number of instances up or down automatically based on the event queue depth.
• Storage - a temporary file system that is reset on each start, and a persistent volume for logs that can be queried from the dashboard.
• Networking - a private VPC that isolates the agent from the public internet, with a single ingress point that the platform uses to deliver events.
• Identity - a vault that holds the agent’s API keys and secrets. The keys are scoped to the agent and cannot be accessed by other agents or by the platform itself.
• Observability - metrics, logs, and traces that are automatically collected and sent to the platform’s monitoring stack.

When you deploy an agent you do not need to write any Terraform or Kubernetes manifests. You simply push the image to the registry, declare a name, and the platform creates a deployment that lives in its own namespace. The platform then watches the event source you specify - a queue, a webhook, or a scheduled trigger - and starts the agent when a new event arrives.

How the platform runs an agent

The platform’s runtime is built on a lightweight orchestration layer that sits on top of our dedicated infrastructure. When an event arrives, the runtime does the following:

1. Pulls the image from the registry and verifies its signature.
2. Starts the container in a sandbox that limits CPU, memory, and network access.
3. Injects the event payload into the container’s standard input or a file.
4. Monitors the container’s health and restarts it if it crashes.
5. Collects the output from the container and publishes it to the target channel.
6. Parks the container when it becomes idle, freeing resources for other agents.

Because the runtime is stateful only for the duration of a single event, it can scale to thousands of agents without a proportional increase in resource usage. The platform also keeps a small cache of the most recent image layers so that the next start is fast. In practice, the average start time is under 200 milliseconds for most agents.

Security and key ownership

Security is a first-class concern in an AI agent cloud. Every agent runs in its own sandbox that is isolated from other agents and from the host. The sandbox is implemented with Linux namespaces and seccomp filters that restrict system calls. The platform also enforces a strict network policy that allows outbound traffic only to the services the agent explicitly declares.

Key ownership is handled by a vault that is integrated into the runtime. When you create an agent you can attach a set of API keys. The platform stores those keys in a key-management service that encrypts them at rest and only gives the agent process access to the keys it needs. The keys are never exposed in logs or in the container image. If an agent is compromised, the attacker only has access to the keys that were attached to that agent, not to the keys of other agents or to the platform itself.

We wrote a dedicated post on this topic, “Key ownership for agent API keys.” It explains the vault architecture and the best practices for rotating keys. If you want to dive deeper, you can read that post for more detail.

Scaling and cost

Because the platform starts an agent only when there is work, the cost model is per-second billing. Compute is metered in 1-second increments, and the platform does not charge for idle time. The only time you pay for a running agent is when it is actively processing an event. This is a direct contrast to the traditional VM model where you pay for the whole instance regardless of usage.

The platform also supports autoscaling at the cluster level. If you have many agents that all listen to the same queue, the platform can spin up additional instances of the queue consumer and distribute the load. The scaling decisions are based on event queue depth, latency targets, and the number of active instances. The platform exposes these metrics in the dashboard, so you can see how many instances are running and how long each event takes to process.

The free tier of the platform gives you a small amount of compute and storage that is ideal for experimentation. It includes a limited number of concurrent agent instances and a small event