We've moved past AI that stops after one response. Cloud agents run entire workflows autonomously in the cloud, iterating through code changes, test runs, and API calls without pausing for approval at every turn. The setup depends on sandboxed environments where agents write and test real code in isolation, keeping your production systems untouched. Understanding how cloud agents work clarifies what tasks you can hand off completely and where human review still makes sense.
TLDR:
- Cloud agents run autonomously in isolated sandboxes, writing and testing real code across multi-step tasks without touching production.
- Sandboxes give agents containment, reproducibility, and reversibility, letting them iterate safely before changes reach a pull request.
- MicroVMs like Firecracker isolate each agent session with its own kernel, preventing compromised agents from affecting other workloads.
- 33% of enterprise software will include agentic AI by 2028, up from under 1% in 2024, driven by faster feedback loops and zero local setup.
- Cloud agents built for product teams can capture any page behind authentication and iterate in sandboxes that mirror your real design system and codebase.
What Cloud Agents Are
Cloud agents are AI systems that run entirely in the cloud, executing multi-step tasks autonomously without requiring local compute or human hand-holding at each step. Where earlier AI tools waited for a prompt and returned a single output, cloud agents act on a goal across many sequential actions, calling APIs, writing and running code, reading outputs, and adjusting course based on what they find.
The distinction matters because it changes what AI can own end-to-end.
How Cloud Agents Execute Tasks
When a cloud agent receives a task, it spins up an isolated sandbox environment where it can read files, write code, run tests, and call external APIs without touching anything in production. Each action the agent takes is logged, observable, and reversible, which gives engineering teams a clear audit trail instead of a black box.
The execution loop follows a consistent pattern: the agent reads its context, selects a tool, executes it, observes the result, then decides what to do next based on what it learned.
The Core Tools a Cloud Agent Uses
Cloud agents work through a defined set of tools that map to real developer workflows:
- File read/write lets the agent inspect existing code and write new files or edits directly into the sandbox, keeping changes grounded in your actual codebase.
- Shell execution lets the agent run commands, install dependencies, and trigger test suites to verify its own output before surfacing results.
- API calls let the agent fetch live data, post to services, or read from external systems as part of completing a multi-step task.
- Search and retrieval let the agent pull in relevant documentation or codebase context it needs to make accurate decisions.
Why Sandboxes Are Critical for Cloud Agents
Sandboxes give cloud agents a safe boundary to write, test, and throw away code without ever touching a live product. Every change a cloud agent proposes gets executed inside an isolated container, purpose-built for agentic code execution, so a broken refactor or a failed API call has nowhere to cascade.
Why Isolation Matters in Practice
There are a few properties that make sandboxed execution non-negotiable for agentic code work:
- Containment means a cloud agent can run untested code, install dependencies, or fire off external requests without any risk to production state or other users' sessions.
- Reproducibility means each session starts from a clean, known baseline, so iteration results are consistent and comparable across runs.
- Reversibility means if an agent goes down a wrong path, the entire sandbox can be discarded and a new one spun up from the last good checkpoint.
These properties combine to make real-code iteration practical. Without them, every agentic action would carry production risk, and teams would rightly hesitate to let an agent touch anything important.
Sandbox Isolation Technologies: Containers, MicroVMs, and Beyond
Keeping agents in check requires more than good prompting. The actual enforcement happens at the infrastructure layer, where isolation tech draws a hard boundary between what an agent can touch and everything else.
Containers
Containers (Docker, Podman) package the agent's runtime, dependencies, and filesystem into a portable unit. They spin up in seconds and share the host kernel, which makes them fast but leaves a thin surface for kernel-level exploits.
MicroVMs
Firecracker microVMs go further. Each session gets its own microVM with an isolated kernel, so a compromised agent cannot affect neighboring workloads. Many cloud providers use microVM-based isolation for multi-tenant workloads because it offers stronger separation than containers alone.
Beyond the Basics
Newer approaches layer on ephemeral disk snapshots, network namespacing, and cryptographic attestation to prove a sandbox has not been tampered with before code runs inside it.
| Technology | Isolation Method | Spin-Up Speed | Security Trade-offs |
|---|---|---|---|
| Containers (Docker, Podman) | Package runtime, dependencies, and filesystem into portable units that share the host kernel | Spin up in seconds due to shared kernel architecture | Fast but leave a thin surface for kernel-level exploits |
| MicroVMs (Firecracker) | Each session gets its own microVM with an isolated kernel | Slower than containers but still fast enough for cloud workloads | Compromised agents cannot affect neighboring workloads due to kernel isolation |
| Advanced Isolation | Layer on ephemeral disk snapshots, network namespacing, and cryptographic attestation | Variable depending on implementation complexity | Prove a sandbox has not been tampered with before code runs inside it |
Cloud Agents vs. Local Agents
Cloud agents run entirely in the cloud, while local agents run on your machine or within your own infrastructure.
Local agents can read your file system directly and integrate tightly with local tooling, but they carry real risk: a bad instruction can modify production files, overwrite local state, or leave your environment in an unpredictable state.
Cloud agents sidestep this by spinning up isolated sandboxes for every session, where the agent reads, writes, and iterates without touching anything outside its boundary.
How Cloud Agent Sessions Typically Work
Most cloud agent sessions begin when a user provides a task, code repository, application environment, or high-level objective. The agent then provisions an isolated execution environment, gathers the relevant context, and starts working through the task autonomously.
The exact workflow varies, but the underlying pattern is consistent: the agent receives a goal, accesses the resources it is allowed to use, executes actions inside a sandbox, analyzes the results, and continues iterating until it reaches a stopping condition or requires human input.
Sessions are typically stateful, allowing the agent to maintain context across multiple actions. This lets the agent track prior decisions, remember intermediate outputs, and build on previous work throughout the execution process.
Starting a Session
Cloud agent platforms commonly allow sessions to begin through one or more of the following methods:
- Connecting to a source code repository
- Providing access to specific files, datasets, or documentation
- Defining a task, objective, or workflow in natural language
- Connecting approved external systems through APIs or integrations
Managing Sessions Mid-Run
Many cloud agent platforms allow users to intervene during execution. Teams can provide additional instructions, adjust priorities, approve actions, or redirect the agent toward a different outcome. Because execution occurs within an isolated environment, changes can typically be reviewed, reverted, or discarded before they affect production systems.
Cloud Agent Adoption and Usage Patterns
Cloud agent adoption has accelerated sharply over the past two years. According to Gartner, 33% of enterprise software applications will include some form of agentic AI by 2028, up from under 1% in 2024. Teams that ship frequently are pulling toward cloud-based agents because the feedback loop is shorter and the setup cost is near zero.
Security and Compliance Considerations
Each sandbox session runs in an isolated environment, so your code and data never touch another user's workspace. Credentials passed to cloud agents are encrypted in transit and at rest, keeping API keys and tokens out of plain-text logs. All changes stay inside the sandbox until you explicitly merge them through a pull request, so nothing reaches production without a human review step. SOC 2 compliance is currently in progress, reflecting a commitment to meeting enterprise-grade security standards as adoption grows.
Limitations of Cloud Agents
Cloud agents still have real gaps worth knowing before you commit to a workflow.
- Context window limits mean very large or tangled legacy codebases can overwhelm an agent, leaving changes incomplete or missing cross-file dependencies buried deep in the repo.
- Ambiguous requirements produce inconsistent output. Tasks that depend on fine-grained judgment or deep organizational context still need a human in the loop.
- Cost scales with usage. High-volume workloads generate real compute bills, and the economics shift as session counts climb.
- Some workflows still favor local development, particularly anything requiring specialized hardware access or tightly coupled IDE tooling the cloud cannot replicate.
How Alloy Works as a Cloud Agent for Product Teams
Alloy is a cloud agent built for product teams. Instead of generating throwaway mockups or standalone demos, Alloy works directly within your existing product, capturing any page behind authentication or a VPN and spinning up an isolated sandbox where code changes happen in real time.
The workflow runs in one continuous loop: idea to sandbox to feedback to implementation. You capture a live page, describe what you want to change, and Alloy writes real code against your actual design system. Nothing is recreated from scratch using generic components.
When a change is ready, it moves to a GitHub Pull Request, not straight to production.
FAQs
Can I build with a cloud agent without setting up a local development environment?
Yes. Cloud agents run entirely in the browser, spinning up isolated sandboxes where all code execution happens remotely. You point the agent at your codebase or a live URL, and it works directly in the cloud without requiring local installs, environment configuration, or consuming your machine's resources.
What happens when a cloud agent makes a mistake during execution?
The agent writes, tests, and revises code inside its sandbox using a tight feedback loop. If a test fails or an API call returns unexpected results, the agent adjusts and tries again without human input. Because each iteration runs in an isolated environment, you can roll back individual steps or discard the entire session and start fresh without any production risk.
How do cloud agents handle multi-step tasks?
Cloud agents execute tasks through a continuous loop: they read context, select a tool (file write, shell command, API call), run it, observe the result, then decide the next action based on what they learned. Each session is stateful, tracking context across all steps instead of treating actions as independent. The agent logs every action, giving you a full audit trail from start to finish.
Final Thoughts on Building with Cloud Agents
Understanding how cloud agents work is the first step to knowing what you can hand off. Sandboxed execution keeps iteration fast and safe. The pull request handoff keeps you in control of what goes live. If your team needs to move faster without adding local setup friction or production risk, cloud agents are worth trying. Alloy is the cloud agent built for product teams. It captures any page of your real product, runs changes in an isolated sandbox, and moves finished work to a GitHub Pull Request, no local installs, no generic components.