Agent Cloud Explained: Infrastructure for Production Agents

Agent Cloud is a managed infrastructure for running AI agents in production. It brings isolated compute, persistent state, durable orchestration, scaling primitives, and observability into one runtime layer.

An agent that works in a demo can lose its place after a retry, time out while waiting for a multi-step approval, or restart in a different sandbox without the state needed to finish the task. That frustration is why the term "agent cloud" matters, even though it collides across the search results page. Cloudflare uses it for production runtime infrastructure, Rubrik for agent governance, Stagwell for a marketing AI workspace, and agentcloud.dev for an open-source RAG platform. This guide uses the developer-infrastructure frame, where agent cloud means the runtime layer that keeps AI agents durable, isolated, and recoverable.

The production boundary becomes clear when teams map demo behavior to runtime requirements:

Augment Cosmos, the unified cloud agents platform, applies that boundary through Sessions, turning one-off prompts into durable workflows that teams can audit, replay, and reuse across days-long and week-long runs. Sessions ship standard on every paid Cosmos plan, not behind a preview flag.

What Agent Cloud Means in Developer Infrastructure

Agent cloud in the developer-infrastructure sense refers to the managed stack on which AI agents run in production. It is an execution layer, distinct from the marketing and governance products that share the label.

Three distinct uses compete for the same query. Conflating them can place stateful agents on layers designed for short, stateless requests.

Cloudflare uses the label for runtime infrastructure. Its Cloudflare release describes moving AI agents from local laptop demos to production workloads running across Cloudflare's global network. The runtime uses Durable Objects, stateful micro-servers with Durable Objects scaling, and runs via agents-sdk on Workers infrastructure.

Stagwell's Agent Cloud, launched October 21, 2025, is a marketing workspace that centralizes access to LLM subscriptions and purpose-built marketing assistants. It aggregates LLM subscriptions for marketing practitioners. Rubrik Agent Cloud is an agent control layer, a control plane above agent runtimes. Neither product supplies the runtime primitives that define the developer-infrastructure frame.

This developer-infrastructure frame separates runtime readiness from model quality. Enterprise agentic AI pilots can expand before deployment infrastructure is ready, and runtime design blocks deployment after pilots expand.

The Five Layers of Agent Cloud Infrastructure

Agent cloud infrastructure consists of five layers that support workloads beyond traditional stateless request platforms. Those layers cover execution and sandbox environments, orchestration, memory and state management, scaling, and observability. Each layer addresses a property that distinguishes agents from stateless HTTP request handlers.

Traditional cloud platforms assume stateless, short-lived requests. AI agent infrastructure instead depends on long-running processes, persistent state across sessions, sandboxed code execution, multi-agent communication, and integrated observability. Augment Cosmos organizes those needs into Sessions for workflow history, Environments for execution boundaries, Experts for agent roles, and Capabilities for tool and MCP-server access.

Layer 1: Execution and Sandbox Environments

Agent cloud execution and sandbox environments host agents as stateful control loops inside microVM, gVisor, or hardened-container boundaries. This preserves task continuity and limits the blast radius for untrusted code execution. The execution layer repeatedly invokes a stateless reasoning core, the LLM, and interprets its outputs. Production agent designs use defense-in-depth with three isolation primitives. The boundary condition is whether the agent executes reviewed, trusted code or untrusted AI-generated code.

• MicroVMs (Firecracker, Kata Containers): Kernel-boundary isolation, with each workload getting its own kernel. Firecracker microVMs provide lightweight microVM isolation for serverless workloads.
• gVisor: A user-space application kernel that intercepts syscalls. Google's gVisor gives each sandbox an independent guest kernel-like userspace that intercepts system calls and is more lightweight than a full VM, but it does not implement virtualized devices.
• Hardened containers (seccomp, AppArmor, capability dropping): Appropriate only when agents execute reviewed and trusted code, because the shared host kernel creates an escape path.

In Cosmos, Environments define where Experts run and enforce boundaries, while Experts and Capabilities define which tools or MCP servers they can access.

Layer 2: Orchestration

Agent cloud orchestration routes multi-agent workflows through task graphs, checkpoints, and guardrails. Retries, deploys, and human approvals should not erase progress. Orchestration coordinates multiple agents through workflows that teams can govern, observe, and recover.

LangGraph workflow docs, trusted by Klarna, Uber, and J.P. Morgan, structure workflows as directed graphs where nodes represent agents and edges control execution flow. Its persistence layer checkpoints thread state at each super-step, so a crash, deploy, or transient failure mid-reasoning-loop does not erase prior work. The choice of orchestration carries operational weight because state management must survive each graph transition. A Temporal migration case describes an initial LangGraph-plus-Redis architecture as "powerful in concept but incredibly brittle in practice," prompting migration to Temporal for state management.

Cosmos Experts add human steering checkpoints around prioritization and spec review. The workflow layer also carries shared memory and coaching-based feedback for domain-specific work.

Layer 3: Memory and State Management

Agent cloud memory and state management stores short-term task state and long-term recall outside the model. That external state helps agents continue work across sessions, retries, and sandbox restarts. LLMs are stateless functions: they process a prompt and return a completion. Memory infrastructure gives agents continuity. Short-term memory is the live prompt state holding recent turns, tool outputs, and retrieved documents. Long-term memory stores and recalls information across sessions through databases, knowledge graphs, or vector embeddings.

Teams should test whether the state survives active prompt limits, retries, and sandbox restarts. For long-running agents, state stored outside the model's active prompt supports session handoff design. Design the agent to keep its place when it wakes in a different sandbox.

The state model separates active prompt context from durable recall and workflow progress:

Cosmos with Context Engine processes entire codebases across 400,000+ files through codebase analysis and semantic dependency graph analysis.

Layer 4: Scaling

Agent cloud scaling moves bursty, stateful agent workloads through external state stores and stateless workers. Platforms can then recover, scale out, and scale down without losing progress. Agent workloads can follow an idle-burst-idle pattern that does not align with autoscaling policies designed for steady-state utilization. Agents maintaining conversation state in memory cannot scale horizontally without external state management, so teams move state into external stores and keep agent code stateless.

Teams can evaluate the scaling boundary by matching each runtime pressure to the primitive that prevents lost progress:

A serverless agent model frames resilience around preserving progress through failures, scaling to zero while waiting for human approvals, and supporting high agent concurrency. Longer task durations increase the likelihood of API timeouts and infrastructure disruptions, so state persistence reduces the chance that a single interruption erases the entire task.

For long-running and parallel agent work in Cosmos, Sessions persist workflow state, and tenant memory carries corrections and patterns forward across runs.

Layer 5: Observability

Agent cloud observability captures LLM calls, tool execution, memory operations, and orchestration spans. Production teams use those records to trace decisions across long-running agent sessions. Traditional request logging captures only part of the debugging surface when an agent handles memory, context, and decisions across many turns. Agent observability assesses whether the system makes sound decisions over long-running sessions.

Agent observability captures LLM calls, tool executions, planning steps, reasoning chains, memory operations, cost, latency, and result status within a single traceable execution graph. It must preserve the connection between a decision, the context used to make it, the tool call that followed, and the state mutation that changed future behavior.

Cosmos Sessions captures reusable workflow records while Cosmos emits structured events for agent actions.

Why Agents Need Dedicated Runtime Infrastructure

AI agents require dedicated runtime infrastructure because traditional serverless and container platforms assume a request-response model. They expect short, bounded, stateless invocations that complete quickly. Agent workloads conflict with those assumptions when they span task lifecycles that involve retries, approvals, and external tool calls. As durable execution framing puts it, agent workloads involve "durable execution over time."

Serverless fails under agent workload boundaries through several runtime constraints:

• Hard execution limits: Bounded function lifecycles can terminate work before continuous monitoring or multi-round approvals finish.
• Statelessness and lost context: FaaS requires teams to store durable state in external storage and explicitly read and write that state on every use, which becomes challenging under weak execution guarantees.
• Partial failures: FaaS at-least-once semantics mean a single event can trigger multiple executions. For agents touching payments, the risk is repeating a dangerous side effect.
• Human-in-the-loop: An approval that takes hours cannot fit inside a short-lived function, and stateless handling turns the approval flow into a distributed system.
• Double-billing on waiting: A function pays for execution time while waiting on another function, which pays for both the active and the idle work.

The container side carries its own tradeoff. Standard containers share the host kernel, which leaves a shared-kernel boundary for AI-generated code. That boundary is why the execution layer distinguishes microVMs, gVisor, and hardened containers by the trust level of the code being executed.

One infrastructure response is durable execution, a programming model that persists execution state and checkpoints at the infrastructure layer, allowing code to resume after failures. Durable execution lets an agent resume a workflow from the last persisted step instead of retrying a request, which reduces the risk of repeating a dangerous side effect.

What "Production-Grade" Means for Agent Workloads

Teams make agent workloads production-grade by designing for durability, statefulness, observability, guardrails, cost control, evaluation, and AI security benchmarks against AI-specific threats. Production evaluation starts after a successful single run, because agents must survive retries, restarts, external tool failures, and human approvals.

Resource profiles document the difference between prototype and production workloads. arXiv research quantifies how AI coding agents differ from serverless workloads:

Durable execution and fault tolerance come first because agent workflows can update external systems before a crash or retry. In a refund process, updating database records and processing payments, durable execution protects the workflow boundary by resuming from persisted progress instead of repeating completed side effects.

Guardrails follow close behind because agents can call tools that affect production data and users. Action guardrails limit agent actions before the agent can delete records, send unauthorized emails, or expose data to the wrong user. Human approval, scoped permissions, and explicit tool policies turn agent autonomy into governed execution rather than unrestricted access to production.

Cost control, evaluation pipelines, and security complete the production checklist after durability and guardrails are in place. The AWS/Stripe case study reports that prompt-prefix caching targets repeated processing costs across agent turns. Evaluation must examine the decision trajectories an agent takes, not just the final answer. Security must address prompt injection, where an attacker embeds hidden instructions that cause an agent to disclose other customers' information. Cosmos human-in-the-loop policies place human judgment at three steering checkpoints: prioritization, spec and intent review, and contextual code evolution.

How Agent Cloud Compares to Cloud Agent Platform and Agentic Cloud Platform

Agent cloud, cloud agent platform, and agentic cloud platform describe adjacent concepts. Agent Cloud names the infrastructure stack. Cloud agent platform names the vendor-managed service and implements it. An agentic cloud platform describes the architectural posture for redesigning the cloud for agent autonomy. Mixing the terms muddies the evaluation.

Separating vendor products from the infrastructure category in which they are implemented clarifies the comparison. Amazon Bedrock AgentCore provides a secure, serverless runtime with complete session isolation, extended execution, and dedicated microVMs for each session. Google's Agent Runtime handles "the infrastructure to scale agents in production." An agentic cloud platform describes a higher-order shift, in which AWS frames the cloud as moving from "a platform for applications" to "a platform for delegated action."

Layer focus creates the distinction. The agent cloud and agent runtime answer the question of where and how agents execute. Cloud agent platform names the managed products implementing that infrastructure. An agentic cloud platform is the architectural posture of reconfiguring the cloud for autonomous agent workloads.

Teams can apply the distinction in a three-step evaluation sequence:

1. Identify which runtime primitives the agent workload requires: isolation, persistent compute, background workers, storage, and optionally GPU.
2. Map which cloud agent platform provides the managed service layer: serverless hosting, session isolation, scaling, and observability.
3. Separate strategic agentic-cloud architecture from the immediate runtime decision so platform teams do not confuse delegated-action design with execution hosting.

That sequence keeps hosting decisions separate from broader cloud platform engineering decisions.

In Cosmos, Environments define execution locations, Experts define agent behavior, Triggers define events, and Sessions record session history on a single platform.

Map Your Agent Infrastructure Requirements Before You Build

Start infrastructure planning with the failure modes your agents must survive: timeouts, duplicate execution, lost context, sandbox changes, and untraceable decisions. Platform teams can then decide which layers to build internally and which layers to consume as managed runtime primitives. Teams choosing to build internally must reserve platform engineering capacity for execution, orchestration, memory management, scaling, and observability, rather than treating agent deployment as a single hosting decision.

Once the required layers are clear, teams can evaluate what agent cloud infrastructure looks like as a managed runtime in practice. In Cosmos, shared context stores prior workflow information; tenant memory carries corrections and patterns across runs; human-in-the-loop policies gate key decisions; observability records agent actions; and Sessions make workflows replayable across the software development lifecycle.

Cosmos can keep cloud-agent workflows durable, observable, and reproducible across the software development lifecycle.

Frequently Asked Questions About Agent Cloud

These are the questions platform teams ask when they are trying to tell whether "agent cloud" means the runtime infrastructure they need to build on, or a different product entirely.

Related Guides

• AI Workflow Orchestration Platforms
• AI Observability Platforms
• Enterprise Cloud Integrations
• Private AI Coding Tools
• Enterprise CLI AI Agents