Where to Deploy AI Agents: Cloud Runtimes, Hosting Platforms, and Sandboxes Compared
Compare six agent deployment options by runtime, state, tools, and operational responsibility. Distinguish managed agent platforms, durable runtimes, application hosting, and code sandboxes before choosing infrastructure for a concrete workload.
An AI agent needs an execution environment, a way to retain the state its work depends on, and controlled access to tools. Those responsibilities can live in a managed agent platform, a durable application runtime, an ordinary hosted service, or several services working together. A code sandbox solves a narrower problem: giving an agent somewhere to execute code.
This guide compares six options by the responsibilities they take on. It is a documentation-based comparison, checked on 21 October 2026, rather than a performance benchmark or an exhaustive market directory. Fit assessments are our analysis of the documented architecture.
What does deploying an AI agent actually mean?
An agent deployment is the operational system around the model. It receives a trigger, loads the relevant state, runs a model-and-tool loop, records outcomes, and decides whether to continue, wait, or finish.
Four layers are useful to distinguish:
- Model access supplies inference. A model API does not, by itself, operate the rest of the application.
- The agent harness controls the loop: instructions, tool selection, intermediate results, and stopping.
- The runtime provides execution, lifecycle, connections, and potentially durable state or recovery.
- Tools and sandboxes provide capabilities, including databases, browsers, external applications, and code execution.
A platform may combine several layers. Buying one layer does not establish that the others are configured for your workload. In particular, a persistent filesystem, conversational memory, and recoverable workflow execution solve different problems.
Six deployment options at a glance
| Option | Documented role | State or lifecycle offering | Main responsibility to examine |
|---|---|---|---|
| Amazon Bedrock AgentCore | Modular agent infrastructure | Runtime, memory, and related services | Which modules your application uses and what authority its tools receive |
| Google Agent Platform | Managed agent application platform | Agent Runtime, Sessions, and Memory Bank | Application packaging, identity, and evaluation requirements |
| Cloudflare Agents | Durable agent runtime | Local SQL state, scheduling, connections, recoverable execution | Agent behavior, tool policy, and workflow recovery semantics |
| LangSmith Deployment | Agent workflow runtime | Durable execution and deployment environments | Control-plane and data-plane placement |
| Railway | General application hosting | Persistent services, scheduled jobs, optional persistent storage | Agent-specific state, orchestration, and recovery implemented by your application |
| Daytona | Programmable code sandboxes | Sandbox lifecycle and snapshots | How sandbox execution connects to the agent’s larger workflow |
The records below explain each row and link to its primary documentation. An offering omitted from this directory has not been assessed; omission is not a negative score.
Amazon Bedrock AgentCore: assemble managed agent services
Amazon Bedrock AgentCore documents modular services for runtime execution, memory, tool access, and agent operation. Its Runtime accepts agents built with multiple frameworks, while its Gateway exposes tools through MCP-compatible interfaces. The services can be used together or separately. AWS overview
Our fit assessment: consider AgentCore when you want managed agent infrastructure while retaining choices about the harness and model. Evaluate the modules individually. A memory service and a runtime are separate architectural decisions even when the same vendor supplies both.
Check before selecting: supported packaging for your exact framework, session lifecycle, regional availability, identity propagation into tools, and the full set of metered services used by one completed task.
Google Agent Platform: managed runtime with context and evaluation services
Google’s current overview at the Vertex AI Agent Engine URL describes Gemini Enterprise Agent Platform. It groups managed Agent Runtime execution with Sessions, Memory Bank, evaluation, and code or computer-use capabilities. The documentation also distinguishes deployment, access management, tracing, logging, and monitoring. Google overview
Our fit assessment: consider this approach when you want managed execution and associated context and evaluation services within Google Cloud.
Check before selecting: the current product name and API for the feature you need, supported application interfaces, resource location, service-account boundaries, and how session state is retrieved after an interruption. A historical tutorial using “Agent Engine” is not sufficient evidence of a current feature contract.
Cloudflare Agents: stateful, event-driven agent applications
Cloudflare Agents documents a runtime with durable session identity, local SQL storage, real-time connections, scheduled work, and recoverable execution. It distinguishes communication channels, the agent harness, the runtime, and tools. A developer can use the provided harness or supply their own loop. Cloudflare Agents documentation
Our fit assessment: consider this model for agents reached through messages, webhooks, or scheduled events where state belongs close to the agent instance.
Check before selecting: how your particular operation resumes, how external side effects are deduplicated, and what happens when a tool completes but its response is lost. Durable runtime state does not automatically make a payment, email, or third-party API call safe to replay.
LangSmith Deployment: explicit workflow execution and hosting choices
LangSmith Deployment documents durable execution, streaming, and scaling for agent workloads. Its deployment environments include managed cloud, hybrid infrastructure, self-hosting with a control plane, and standalone Agent Server. The placement of execution and databases can differ from the placement of observability services. LangSmith Deployment documentation
Our fit assessment: consider this approach when workflow execution and deployment topology are central decisions. The relevant comparison is not simply “hosted or self-hosted”; it is who operates the control plane, Agent Servers, databases, and traces.
Check before selecting: plan and licensing requirements, framework integration paths, and the operational dependencies of your chosen environment.
Railway: host the application you already own
Railway services are container-based deployment targets. Its documentation distinguishes persistent services from scheduled jobs and supports deployment from repositories, local directories, or container images. Files outside an attached volume are ephemeral across deployments. Railway Services documentation
Our fit assessment: consider general application hosting when your agent is already an application with an API, worker, scheduler, and database architecture. You retain the application design while the platform handles deployment infrastructure.
Check before selecting: where checkpoints live, how jobs resume, what triggers execution, and how upgrades affect in-flight tasks. Keeping a service running is different from preserving a workflow correctly.
Daytona: give an agent a programmable execution environment
Daytona documents programmatically managed sandboxes for executing code, manipulating files, and controlling processes. Its APIs cover sandbox lifecycle and runtime configuration; snapshots and volumes provide additional state-management options. Daytona documentation
Our fit assessment: consider a sandbox when an agent must run generated code or work in a configurable filesystem. A sandbox can be a tool used by an agent hosted elsewhere.
Check before selecting: sandbox lifetime, snapshot behavior, network policy, resource limits, and how results leave the environment. A sandbox API alone does not define your user-facing service, durable agent address, or task acceptance rules.
How should you choose?
Describe one complete workload before comparing plans. Specify its trigger, expected duration, required tools, retained state, and acceptable result. Then ask:
- Can an ordinary scheduled job or deterministic workflow do the work?
- Which parts actually require model-directed decisions?
- Does the agent need persistent execution, or persistent state between executions?
- Does it execute untrusted or generated code?
- Which external actions must not be repeated?
- Who operates the database, queue, credentials, and recovery procedure?
An always-available agent does not necessarily require continuous inference. It can retain an identity and working state while computing only when an event or schedule requires it.
A useful proof of concept tests restart, timeout, duplicate delivery, permission withdrawal, and cost per accepted result. Run these against your own workload; a vendor’s feature list cannot supply the outcome.
For operational evaluation, continue with AI Agents in Production. For continuity across hosting changes, see Persistent AI Agent Identity.