Best Hosting and Deployment Platforms for AI Agents

Contents

Figure 1: Long runs, durable state, real isolation — agents need more than a stateless API host

Managed runtimes, edge runtimes, durable execution engines, and a portable pattern that survives any of them

Hosting an agent isn't like hosting a web app. A request can run for minutes or hours, pause for a human decision overnight, spawn tool calls that touch real systems, execute code nobody has reviewed, and cost real money with every step. A platform that's perfect for a stateless API can be a poor home for that. This guide covers what agents need from infrastructure, the main categories of platform, honest profiles of the leading options, and a way to choose without being steered by vendor-written rankings.

A caution about sources: most "best platform" comparisons come from companies that sell hosting, gateways, or orchestration, and this market renames and restructures products constantly. Verify current capabilities, limits, and pricing in each vendor's own documentation before committing.

What Agents Need From a Platform

Durable state and resumability. Runs should survive crashes and deploys, and resume where they stopped.
Long execution windows. Minutes to hours, far beyond typical HTTP request timeouts.
Human-in-the-loop support. The ability to pause for approval, possibly for days, then continue.
Session isolation. Untrusted or model-generated code and tool use shouldn't be able to reach other sessions or your internal network.
Elastic concurrency. Bursty demand, ideally with scale-to-zero when idle.
Identity and permissions. Agent-level identity, credential handling, and scoped access to tools.
A tool and MCP gateway with governance and auditing.
Memory and session storage.
Observability. Traces of every model call, tool call, and state change, exportable to your tooling — the same trace discipline the observability guide in this series covers.
Cost controls. Budgets, rate limits, and per-agent spend tracking.
Model flexibility and failover, so a provider outage doesn't stall long-running work.
Compliance and data residency, plus a realistic exit path if you outgrow the platform.

No platform nails all of these, which is why the market splits into layers.

The Layers of the Market

Hyperscaler managed runtimes: AWS, Azure, and Google Cloud's agent platforms, bundling runtime, identity, memory, and governance.
Framework runtimes: hosting built around a specific agent framework, such as LangGraph's.
Serverless, edge, and compute platforms: general infrastructure suited to agents, such as Cloudflare and Modal.
Durable execution engines: Temporal, Inngest, and similar, which make multi-step code reliable without being agent-specific.
Sandboxes for isolated code execution.
AI and model gateways that sit in front of model providers.
DIY containers or Kubernetes, maximum control and maximum operational burden.

Most production systems combine two or three of these.

Hyperscaler Managed Runtimes

Amazon Bedrock AgentCore is AWS's managed platform for production agents. It provides managed infrastructure including runtime, memory, identity, gateways, browser automation, code execution, policy controls, evaluation, and observability. Its runtime runs isolated agent sessions on dedicated microVM compute, with each lifecycle lasting up to eight hours, and it's framework-agnostic, supporting options like Strands, LangGraph, CrewAI, and the OpenAI Agents SDK. One 2026 comparison says it reached general availability in October 2025, and that AWS is winding down the older "Bedrock Agents Classic" product, which is in maintenance mode and closed to new customers as of July 30, 2026 — verify that detail with AWS before planning a migration. Best for: teams standardized on AWS who want identity, billing, and governance in one place. Watch-outs: an AWS-centric design, and an eight-hour session cap that long autonomous jobs must plan around.

Microsoft Foundry Agent Service (formerly Azure AI Foundry Agent Service) offers hosted agents running in VM-isolated sandboxes, one per session, with sessions that resume after idling. A comparison highlights Entra-based agent identity, guardrails, and tenant-wide policy, and notes it supports LangGraph as well as Microsoft's own Agent Framework. Best for: Microsoft 365 and Azure-native organizations. Watch-outs: it's strongest inside the Microsoft ecosystem.

Google's Gemini Enterprise Agent Platform (the successor branding for Vertex AI, which includes Agent Engine) provides a managed runtime with sessions and a memory bank, and pairs naturally with Google's Agent Development Kit. Best for: Google Cloud teams building on Gemini. Watch-outs: naming and packaging have been shifting, so confirm which service names and features are current.

Across all three, the pitch is the same: if identity, logging, and billing already live in one cloud, its managed runtime is the path of least resistance. The cost is portability and a tendency to deepen lock-in over time.

Framework Runtimes

LangSmith Deployment (formerly LangGraph Platform) hosts LangGraph agents with durable execution, persistent state, streaming, human-in-the-loop controls, and integrated tracing, and is offered in cloud, hybrid, and self-hosted forms. Best for: teams that built on LangGraph, as covered in the LangGraph tutorial earlier in this series, and want checkpointing, interrupts, and replay handled for them. Watch-outs: it ties you to LangChain's ecosystem, and LangSmith's commercial tiers add cost.

A note on OpenAI: one 2026 platform roundup reports OpenAI is closing Agent Builder after November 30, 2026 and pointing developers to the Agents SDK, which teams host themselves. If you built on Agent Builder, plan the move now and confirm the shutdown date with OpenAI.

Serverless, Edge, and Compute Platforms

Cloudflare Agents combines Durable Objects for state, the Agents SDK, and Workflows, providing persistent state, durable execution, and edge deployment. Each agent can be a stateful, globally distributed object that wakes on demand, which suits chat-style and event-driven agents well. Watch-outs: it's a distinct runtime model rather than a lift-and-shift of a Python service.

Modal runs Python functions and sandboxes on CPU or GPU, with executions up to 24 hours according to one comparison. Best for: Python-heavy agents, GPU workloads such as local models, and sandboxed code execution. Watch-outs: you assemble orchestration, state, and identity yourself.

Containers on managed services, such as Google Cloud Run, AWS Fargate, Fly.io, Railway, and Render, remain the simplest way to host an agent API. They're easy to understand and portable, but you add durability, queues, and isolation on top.

Durable Execution Engines

Temporal is an open-source durable execution platform, not an agent framework, with a managed cloud option. It's well suited to long-running, multi-step workflows, but a comparison notes it provides execution reliability, not agent identity or policy. Inngest, Trigger.dev, and DBOS play similar roles, with Trigger.dev oriented toward durable TypeScript background tasks. Best for: teams who want reliable retries, timers, and resume-after-crash behavior independent of any agent framework, and who are willing to write the agent logic as workflow code. These engines also pair with frameworks, since several agent frameworks now offer durable-execution integrations.

Sandboxes and Gateways

Agents that run code need real isolation — container sandboxes, gVisor, or Firecracker microVMs, covered in the coding agent guide in this series. Hosted sandbox providers exist so you don't build this yourself.

AI gateways sit between your agents and model providers. A 2026 comparison of gateways for the Claude Agent SDK lists the capabilities that matter: Anthropic-format streaming, multi-provider failover, per-agent budgets, and governed MCP tool access, naming options like Bifrost, LiteLLM, Kong AI Gateway, Vercel AI Gateway, and Cloudflare AI Gateway. Gateways help with failover and spend control, and they're the layer where per-agent budgets are usually enforced — the same budget discipline the guardrails guide enforces inside the harness.

Choosing by Scenario

Everything already runs on one cloud: that cloud's managed runtime — AgentCore on AWS, Foundry on Azure, or Gemini Enterprise Agent Platform on Google.
LangGraph agents needing pauses and replays: LangSmith Deployment, or self-host with a durable checkpointer.
Stateful, event-driven, globally distributed agents: Cloudflare Agents.
GPU or Python-heavy workloads and sandboxed code: Modal or a sandbox provider.
Long, multi-step workflows where reliability is the priority: Temporal, Inngest, or Trigger.dev, optionally under a framework.
Small team, one agent, modest scale: a container on Cloud Run, Fly.io, or similar, with a database and a queue.
Strict data control or air-gapped requirements: Kubernetes or self-hosted options, accepting the operations burden.
Multi-cloud or avoiding lock-in: framework-neutral code, MCP for tools, OpenTelemetry for traces, and a gateway for models, so the runtime stays swappable.

A Minimal Pattern That Works Anywhere

Whatever platform you pick, the same design principles apply. The most important: don't run a long task inside a web request. Accept the request, return a run ID, execute elsewhere, and let clients poll or stream. This skeleton shows the shape:

import uuid
from fastapi import BackgroundTasks, FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()
RUNS = {}   # replace with Postgres or Redis: process memory is lost on restart
            # and isn't shared across replicas

class RunRequest(BaseModel):
    task: str
    idempotency_key: str | None = None

def execute(run_id: str, task: str):
    RUNS[run_id]["status"] = "running"
    try:
        result = run_agent(task)        # your agent loop, with step and token budgets
        RUNS[run_id].update(status="succeeded", result=result)
    except Exception as e:
        RUNS[run_id].update(status="failed", error=str(e))

@app.post("/runs", status_code=202)
def create_run(req: RunRequest, bg: BackgroundTasks):
    if req.idempotency_key:                             # retries must not duplicate work
        for rid, r in RUNS.items():
            if r.get("key") == req.idempotency_key:
                return {"run_id": rid, "status": r["status"]}
    run_id = str(uuid.uuid4())
    RUNS[run_id] = {"status": "queued", "key": req.idempotency_key}
    bg.add_task(execute, run_id, req.task)
    return {"run_id": run_id, "status": "queued"}

@app.get("/runs/{run_id}")
def get_run(run_id: str):
    if run_id not in RUNS:
        raise HTTPException(status_code=404)
    return RUNS[run_id]

This is a teaching skeleton. In production, BackgroundTasks should give way to a real queue and worker or a durable workflow engine, and RUNS should live in a database. The essentials to carry forward are the 202 response, the idempotency key, and persisted run state.

Architecture Practices for Hosted Agents

Keep state out of process memory. Persist conversation state and checkpoints in a database so any replica can resume a run, and so deploys don't kill work in flight.
Make tools idempotent, because retries and resumes will happen.
Queue long work, with concurrency limits and backpressure so a traffic spike doesn't become a model-provider rate-limit storm.
Stream progress with server-sent events or WebSockets so users see activity during long tasks.
Implement pauses as persisted state plus a callback, not as a held-open connection, so human approvals can take days.
Version everything: prompts, tools, model IDs, and agent code, with safe rollout and rollback as described in the GitOps guide and the blue-green guide in this series.
Budget at the platform edge: per-run caps on steps, tokens, time, and spend, plus per-tenant limits.
Isolate tenants and sessions. Don't share filesystems or credentials between users' runs.
Export traces in an open format so observability isn't tied to one vendor.

Security and Governance

Treat each agent as a service identity with least-privilege access, and keep credentials in a secrets manager, never in prompts or tool results. Restrict network egress for sandboxes, since an agent with open internet access and sensitive data in reach is an exfiltration risk. Log every tool call for audit. Require human approval for irreversible actions. Use agent-level identity features where your platform offers them, such as Entra-based agent IDs on Azure or AgentCore's identity services on AWS, and confirm where data is stored and processed for residency requirements.

Cost Considerations

Token spend usually dwarfs hosting cost, so the biggest savings come from step budgets, caching, and routing simpler work to cheaper models — the tradeoffs in the LLM API pricing guide — not from picking a cheaper host. Still, the hosting model matters. Always-on containers cost money while idle, scale-to-zero platforms save money but introduce cold starts, and per-session microVMs bill by session lifecycle. Model your real traffic pattern, including idle time and long-running sessions, before assuming a platform will be cheap.

How to Evaluate a Platform

Ask these before committing:

What's the maximum run duration, and what happens when it's reached?
How is state persisted, and does a run survive a crash or deploy?
How are pauses and human approvals handled?
What's the isolation model between sessions?
Does it support my framework and models, or does it steer me toward one?
Can I export traces and logs in open formats?
What are the quotas, concurrency limits, and regions?
What's the pricing model, including idle time and storage?
What's the exit path if I leave?

Then run a pilot with your real agent under stress: kill the process mid-run, pause a run for a day, spike concurrency, and send hostile input. How the platform behaves when things break tells you more than any feature matrix.

Common Pitfalls

Running long agent tasks synchronously in web requests, then hitting timeouts.
Storing run state in memory on a single instance.
Choosing a platform from a vendor-written ranking without testing failure behavior.
Skipping idempotency, so retries duplicate refunds, emails, or charges.
Giving agents broad network and credential access.
Ignoring session caps like eight-hour limits for jobs that run longer.
Building deep on a product in transition, such as a service being renamed or wound down.
No spend limits at the platform edge.

Recommended Books

Book	Description	Get it
Designing Agentic AI Systems	- runtime, state, and isolation architecture behind production agents.	View on Amazon
AI Engineering	- serving infrastructure, cost modeling, and scaling LLM workloads.	View on Amazon
AI Agents in Action	- real agent deployments where hosting choices show up.	View on Amazon

Unlock AI That Actually Works

Get lifetime access to GPT-6 Astra, Claude Fable 5.1, Gemini 3.5, Grok 4.5, and more — all in one platform. Build websites, apps, videos, content, and digital products from a single command. No monthly fees. No tool-hopping.

Click here to get GPTAstra Max now — one-time payment, lifetime access.

Frequently Asked Questions

What do AI agents need from a hosting platform that web apps don't?

Agents break the stateless-request model. A run can execute for minutes or hours, pause overnight for a human decision, call tools that touch real systems, execute code nobody has reviewed, and spend real money at every step. So platforms are judged on durable state and resumability, long execution windows, human-in-the-loop pauses, session isolation, elastic concurrency, agent-level identity, MCP gateway governance, memory, observability, cost controls, model failover, and a realistic exit path — no single platform nails all of them.

What are the main categories of agent hosting?

Hyperscaler managed runtimes (AWS Bedrock AgentCore, Microsoft Foundry Agent Service, Google's Gemini Enterprise Agent Platform), framework runtimes (LangSmith Deployment for LangGraph), serverless and edge compute (Cloudflare Agents, Modal), durable execution engines (Temporal, Inngest, Trigger.dev), isolated code sandboxes, AI gateways for model failover and budgets, and DIY containers or Kubernetes for maximum control. Most production systems combine two or three of these layers.

How should I choose a platform for my agent?

Start with the simplest platform that gives you durable state, a long enough execution window, isolation, and observability. If everything already runs on one cloud, use that cloud's managed runtime; if you built on LangGraph, LangSmith Deployment handles checkpointing and interrupts; for stateful event-driven agents, Cloudflare Agents; for GPU or Python-heavy workloads, Modal; for long multi-step reliability, Temporal or Inngest; for a single agent at modest scale, a plain container. Keep agent code portable with MCP for tools and OpenTelemetry for traces, and test failure behavior before trusting it with real users.

What usually costs more: hosting or model tokens?

Token spend usually dwarfs hosting cost, so the biggest savings come from step budgets, prompt caching, and routing simpler work to cheaper models — not from picking a cheaper host. That said, the hosting model still matters: always-on containers cost money while idle, scale-to-zero platforms save money but add cold starts, and per-session microVMs bill by session lifecycle. Model your real traffic pattern, including idle time and long-running sessions, before assuming a platform will be cheap.

Wrapping This Up

The right home for an agent depends on where your systems live and what the agent does. Hyperscaler runtimes like Bedrock AgentCore, Foundry Agent Service, and Google's Gemini Enterprise Agent Platform fit single-cloud shops, LangSmith Deployment fits LangGraph users, Cloudflare and Modal suit stateful edge and Python or GPU workloads, durable execution engines add reliability, and plain containers remain a solid choice for simple cases. Gateways and sandboxes fill in model failover, budgets, and isolation.

Start with the simplest platform that provides durable state, a long enough execution window, isolation, and observability for your agent, keep your agent code portable through open protocols like MCP and OpenTelemetry, and test the failure modes before you trust it with real users. In this fast-moving market, an easy exit is itself a feature.