What Makes Managed Agent Hosting Actually Built for Agents and Not Just Relabeled Cloud

Managed cloud hosting for AI agents needs four non-negotiable layers, which are persistent state, orchestration and recovery, per-user isolation, and agent-aware observability. These layers distinguish infrastructure built for autonomous work from cloud compute that merely runs an agent process. A platform missing even one is selling relabeled compute.

Why "agent hosting" has become a meaningless label

A buyer looks at compute specs, watches a fast demo, signs up, and hits a wall in month three. The agent runs, but the team now owns recovery, credential management, and customer separation. The demo showed only that the software could start.

The label hides three different kinds of product. Compute platforms run code, managed agent services combine orchestration with enterprise integrations, and orchestration platforms coordinate work and state. Frameworks for writing agent logic and tools for observing it do different jobs again. When buyers compare them without naming those jobs, a page full of features can look like a complete plan for running agents.

Any cloud platform can host an agent binary. That objection is true but misses the distinction. Beyond serving files, scripts, and database queries, agent infrastructure must support long-running asynchronous work, sandboxed code, persistent state, and per-user tool authentication. Running the process is the easy part.

How agents actually fail in production, and why generic cloud cannot catch it

A production agent can crash mid-task, take an unlogged action, or leave a workflow half-finished without producing a useful error. A process monitor cannot reconstruct that missing history. Even when it detects a crash, it does not explain which work finished or whether an action should run again. Half-finished work can leave corrupted state, so the failure may not be clean.

Two changes make that gap more consequential. Agents went from chat to writing to databases, sending emails, and filing tickets. Execution also moved from interactive sessions, with a person watching, to autonomous runs on a schedule. The human checkpoint disappeared as the actions gained consequences. An action that fails silently or runs twice is now an incident.

Generic uptime monitoring answers a narrower question. It can report whether a process is available, but availability does not establish whether a workflow completed correctly. This does not make agents inherently dangerous. Agents do more than ordinary hosting was built to watch.

AWS identifies runtime, memory, identity, security, and observability as infrastructure teams need before agents take action. Its build-and-ship guide describes Cox Automotive putting 17 agents into production in a single year by standardizing on one platform and reusing the stack each time. The four connected layers begin with durable state and extend through recovery, customer isolation, and a trace of agent behavior.

Layer one: persistent state that survives crashes, disconnections, and redeploys

An agent working autonomously for hours needs its progress and outputs to outlast the session that produced them. The work must not be lost when a connection drops. Neither should a process restart or a redeploy. Without that continuity, long-running, multi-step execution depends on everything staying alive until the task ends.

Persistence is therefore more than an attached storage option. Files need to survive, and databases need to support agent state management. Ephemeral volumes that reset on each deploy do not meet the requirement, even if they retain files while the process runs.

Attaching a relational database can solve part of this. It also leaves the developer responsible for connecting that database to the agent’s state and recovery needs. That is valid engineering, but it is not work the hosting provider has managed away. A service sold as managed agent infrastructure should do that glue work without quietly handing it back to the customer.

AWS Bedrock AgentCore provides managed runtime and memory, freeing teams from storage architecture work to focus on agent logic. Memory supplies one part of a complete platform. Persistent state gives the system something to recover. The next requirement is knowing how to recover it.

Layer two: orchestration and recovery that handles failures the agent cannot see

A process manager can restart a crashed container without knowing where the agent stopped in a multi-step workflow. Restarting is not the same as resuming. If the system has no durable, replayable state, starting it again cannot tell it which steps still need to run and which have already finished. Recovery can repeat the incident.

The orchestration layer requires durable execution, including the ability to replay and resume work after a crash even when the agent cannot report the loss. It also requires built-in scheduling, retries with exponential backoff, and concurrency controls. Without those primitives, the developer inherits queue management as another piece of hidden platform work.

Durable-execution tools solve an important part of this problem. Temporal, Inngest, Trigger.dev, and Restate make multi-step workflows reliable for general code. They do not, by that role alone, supply agent-level audit or MCP support. A reliable workflow engine is not automatically a complete agent platform. The execution layer and the agent-specific governance layer need separate evaluation.

AWS’s build-and-ship guide describes Swisscom deploying automated tech support and personalized sales agents handling thousands of requests monthly in under four weeks. The platform supplied orchestration, saving the team the work of building it separately. The same guide says Thomson Reuters built one internal agent hub so that every team would not have to build its own stack. These examples show why reuse has value beyond an individual workflow. Recovery infrastructure should not become a fresh project for every agent a company wants to deploy.

Layer three: per-user isolation that makes multi-tenant agent products architecturally sound

Reliable execution for one agent does not settle how a product serves many customers. An agent may hold each customer’s tools, files, credentials, configuration, and conversation history. Those are access boundaries. Sub-accounts on a shared instance do not keep customers isolated just because each sees a different screen.

Shared infrastructure can work for agents used only for simple chat. Agents entrusted with customer tools and credentials need a genuinely separate environment for each client, with distinct data, configuration, and history. With a shared API key, users have the same access and no agent-level boundary. That puts products that handle customer information at risk of security and compliance failures.

For an operator selling an agent-powered product, the unit of scale is one isolated, persistent agent per customer. Provisioning belongs in automated onboarding. White-label infrastructure expresses this model through a private, persistent, branded agent environment provisioned for each customer.

As agents spread across an organization, isolation also needs one access-control model that they all share. Agents deployed across sales, IT, HR, customer service, and finance can multiply across vendors without a common governance layer. Separate customer environments address one boundary, while consistent access control addresses how those environments are governed. A sub-account label or a growing list of agents does not prove that the boundary holds.

This is where internal tools and customer products diverge. A platform that works for a single team may still leave the essential multi-tenant architecture to its buyer.

Layer four: agent-aware observability that traces what the agent decided, not just whether the process ran

Process-level monitoring tells an operator that an agent is running. Agent-aware observability shows what it decided, which tools it called, on whose behalf, and whether its actions crossed a policy boundary. Those are different kinds of evidence. An uptime dashboard cannot substitute for an account of what the agent actually did.

Enterprise governance also needs visibility into costs, policy compliance, and delivered value. That gets harder when agents in several departments use different frameworks and clouds. A complete picture requires agent-level tracing. Otherwise, the company can know that its infrastructure is available while remaining unable to explain the actions taken through it.

Enforcement complements that visibility but does not replace it. AWS AgentCore uses Cedar policies evaluated on every tool call, with credentials managed at the gateway outside the agent’s loop. This puts enforcement in infrastructure the agent cannot reason its way around. Tracing records what the agent did so that it can be debugged, reviewed, and audited.

ISO/IEC 42001:2023 adds rules for AI system impact assessment, third-party supply chain controls, lifecycle documentation, and monitoring. Meeting those rules takes traceability that shows more than process health. The standard supports EU AI Act compliance, but does not cover all of the Act’s quality management requirements. A hosting feature alone does not mean that all regulatory rules have been met.

Built-in tracing can cover basic debugging and monitoring, while dedicated tools such as Langfuse go deeper into costs, environment separation, prompt versions, run filtering, and tracing across clouds. All four layers must be present. Missing persistence, recovery, isolation, or agent-aware observability means the platform is not built for how production agents actually behave.

How to apply the four-layer test when evaluating a platform

The practical test for buyers starts with persistence. Ask whether agent state and outputs survive both a crash and a redeploy. Then ask whether the platform can resume a half-finished workflow after restarting its process. Next, check whether each customer has an environment that is truly separate. Finally, ask whether the platform can trace the agent’s decisions and actions well enough to support an audit.

Fast deployment cannot make up for missing customer isolation, and durable execution cannot make up for a missing action history. The gaps often become clearest in the third and fourth layers. A compute-focused comparison can miss both because neither follows from faster processors or more memory.

For operators building customer-facing products, evaluation should include automatic provisioning at onboarding. The platform needs to set up isolated, persistent environments for customers without someone doing it by hand for every signup. A single-API-call provisioning model for per-user sandboxes sets the usability benchmark. Simple deployment of agents such as OpenClaw, Hermes, Claude Code, Codex, and OpenCode should not require DevOps expertise, though deployment convenience alone does not establish the four layers.

Integration-heavy workflows need another close look at authentication. Gmail, Slack, GitHub, and WhatsApp give agents ways to act, but those connections are production dependencies with their own failures. Managed authentication should store and rotate each user’s OAuth credentials without leaving developers to handle tokens. Composio’s catalogue lists hundreds of toolkits through a single MCP endpoint and handles refresh problems including Google’s short expiry window and Slack’s rotation cycle.

Before signing, buyers should also check SOC 2 Type I or II, ISO 27001, and, where applicable, HIPAA Business Associate Agreement availability. These checks complement the architectural test by covering compliance gaps left unresolved by a product demo.

For founders weighing self-hosting, the cost comparison must include setup, maintenance, monitoring, credential management, and recovery time. Self-hosting becomes more plausible when workloads are stable, predictable, and heavily utilized, with very high monthly token volumes and consistent utilization. Until that case is established, infrastructure labor remains part of the bill even when it does not appear on a cloud invoice. Platforms that clear all four layers free the builder from provisioning and recovering instances to spend that time selling and improving the agent.