How to Tell If Your Hosting Provider Actually Understands Agents Before You Commit

Managed cloud hosting for AI agents should have persistent state, per-user isolation, durable execution with replay, and credentials scoped to each user. The best fit for a customer-facing agent business is a provider that can run the code and demonstrate all four. This guide explains how to test that distinction before committing.

Why "can it run my agent" is the wrong question to ask a hosting provider

Agents take consequential actions unattended, build memory across sessions, and use credentials belonging to individual users. When a process fails halfway through a task, bringing it back online may not bring back the work. A working deployment can hide all of these gaps.

That is why the familiar path from localhost to familiar infrastructure can turn painful in month three. A silent crash at 3am or a half-finished task exposes responsibilities the team assumed the host would handle. Generic compute, managed cloud runtimes, and agent-native hosts address different parts of this problem, even when their deployment screens look similar. The useful comparison is what each platform takes responsibility for after deployment. What follows is a set of concrete questions to ask before signing anything.

The four capabilities that separate agent-native hosting from rebranded compute

Use four capabilities as the lens for evaluating “agent support” in the vendor conversation. Persistent state keeps memory from being lost when an agent restarts or moves between sessions. Per-user isolation prevents one customer's actions, data, or runaway process from affecting another customer. Durable execution with replay recovers unfinished work after a failure. Credential scoping lets the agent act with a particular user's permissions.

These capabilities solve different failures, so one cannot substitute for another. An isolated agent can still forget its task, while an agent with perfect memory can still use the wrong customer's credentials. Recovery needs its own test, too. A restart policy says nothing about whether the agent will repeat an action it already completed. A provider that understands agents should explain each boundary on its own, including which parts the platform handles and which you have to handle.

How to probe a provider's state management before you commit

Ask about the location of the agent's memory and its survival when the process restarts. Then ask whether that memory survives a deployment without a developer having to step in. The answer should name the platform's responsibility clearly. “You can attach external storage” describes a possible building block. If your team must provision and connect a separate vector store, it still owns that part of the system.

Persistent memory is also more than saved conversation history. Nous Research's Hermes creates skill documents from completed tasks, allowing it to reuse procedural knowledge on repeat work. That benefit depends on keeping the resulting state. If a deployment wipes it, the agent loses knowledge it could otherwise use again.

Ask whether an operator can check, fix, or reset one user's memory without resetting the whole deployment. This tests control as well as persistence. A provider may offer Postgres or Redis as the answer, but attaching storage leaves questions about uptime, schema migrations, and backups. Make the provider explain who owns that work.

What per-user isolation actually means, and how to test whether a provider has it

For a product where each customer gets an agent, the architectural unit is one isolated, persistent agent per customer. A shared environment with separate customer labels is not enough. When agents share container namespaces, a runaway process, memory leak, or compromised agent can affect other tenants.

Ask the provider to describe its isolation model between tenant agents. “Containers” alone is an incomplete answer. It should explain namespace separation, resource limits, and the controls that keep damage from spreading when one agent fails. MicroVM or hypervisor-level isolation, including Firecracker or Kata, gives you concrete terms to ask about without needing a lesson in kernel mechanics.

Then put a specific failure to the provider. If one customer's agent enters an infinite loop or exhausts memory, what prevents it from affecting another agent on the same host. Ask how that protection works for instances that have just been provisioned, too. Isolation should arrive automatically when a customer signs up, automating the environment configuration a founder would otherwise perform.

Durable execution versus retries: why the difference matters more than providers admit

A retry and a recovery are different promises. Retrying from the beginning can be safe for an operation that produces no additional effect when repeated. It is dangerous when an agent has already sent an email, filed a ticket, or moved money. Starting over may repeat an action already done while trying to finish the rest of the work.

Durable execution checkpoints progress so recovery can replay the incomplete portion instead. Ask what happens when an agent crashes halfway through a multi-step task. “It retries” does not explain how unfinished work is recovered. The provider should describe checkpointing and replay, then explain how to see the actions taken before failure and resume from the last successful step.

Temporal, Inngest, and Trigger.dev provide durable execution for workflows. Workflow orchestration alone does not supply an agent-level audit trail or awareness of MCP tools. If a host uses one of these tools, ask what the host adds around it rather than assuming the tool's presence settles the question.

Credential scoping and the per-user auth problem most providers ignore

An agent's permission to act should belong to the user behind the request. A downstream service that sees only the application identity treats Sarah's request and Tom's as coming from the same identity, leaving gaps in consent, selective revocation, and the record of who authorized an action.

Ask whether authentication to third-party services is at the application level or the per-user level. A concrete answer should explain how user identity, connected accounts, tool permissions, and execution state bind into one runtime context. Then ask how to revoke one user's GitHub connection without affecting anyone else's session. Revocation makes the boundary easy to test.

The consent screen deserves attention as well. Managed OAuth flows that show your brand make authorization look like part of the product the customer chose. Showing an infrastructure provider the customer does not know at that point can hurt trust and conversion. An integration layer with pre-built connections to Gmail, Slack, WhatsApp, and GitHub, and over a thousand available toolkits, can manage authentication otherwise handled in custom code. But the number of connections does not replace the per-user credential test.

Security and compliance questions that expose whether a provider is ready for production

For regulated workloads, operational convenience is not enough. Put four specific questions to the provider before committing, starting with whether data is encrypted in transit and at rest, and which certifications cover the service. SOC 2 Type I or Type II is a minimum signal in this evaluation. Ask for the named certification rather than accepting a general claim that the platform is secure.

Second, ask whether the provider will sign a BAA for HIPAA-covered workloads. A refusal rules it out for PHI workloads requiring that agreement, while availability only on upper-tier plans changes which plan is usable. Third, ask whether agent conversations, files, or session data are used to train AI models. A “yes” or a reserved right to do so creates a product risk when customers share proprietary information. Fourth, ask where the data physically resides and whether you can choose its region.

Data residency controls are essential for customers with GDPR or data-sovereignty requirements. Keeping agents within your own perimeter puts the work of compliance on your team, which needs infrastructure engineering to keep it up. A managed provider with named certifications and strong contractual protections can offer more coverage than an under-resourced self-hosted stack.

Operational questions that reveal whether a provider can support a growing agent-powered business

A provider can answer the security questions well and still leave onboarding painfully manual. Ask how a new customer receives an agent instance. The answer should describe automated, API-driven provisioning. A single API call that creates an isolated, persistent sandbox per user is the useful benchmark. Anything more involved needs a clear explanation of which work your team must absorb.

Then ask about monitoring at the agent level. Server uptime does not tell you whether a task is stuck, an agent has crashed silently, or a process is looping. Ask how the platform alerts you to those failures and how it handles runtime updates across customer instances. White-label support is another operational requirement when customers should see your product's brand.

Billing should fit the same delivery model. Per-second compute billing favors idle agents and makes heavy usage more expensive, while a flat per-agent managed plan is more predictable when you sell agent capacity. Ask how the pricing behaves across your customer instances. The right time to discover a mismatch is before the first usage bill.

How to run a quick pre-commitment test on any provider

Spend two hours deploying a minimal agent. Give it a piece of information, kill the process, restart it, and ask it to recall that information. No manual restoration should be necessary. If state returns only after developer intervention, the platform has failed the managed-persistence test.

Next, deploy two instances if the platform supports them. Saturate one with a CPU-intensive task and watch whether the other's response time degrades. This probes the isolation claim under pressure. Then start a five-step task and kill the process after step two. Ask the provider to show the recovery path, distinguishing checkpoint replay from a restart at step one.

For credentials, authenticate to a third-party service as a named test user. Ask where the credential is stored, what permissions it grants, and how to revoke it for that user alone. Vague answers are not evidence of user-level scoping. Observe how quickly support answers these basic architecture questions, particularly whether it gives specifics or deflects. Before the trial ends, confirm that the billing model fits the way you will deliver agents to customers.

What a provider that actually understands agents looks like in practice

A credible provider can demonstrate the boundaries you have just tested. Its answers are concrete enough to compare with actual behavior, rather than promises to solve the difficult parts later. For deployment, that can mean one-click support for runtimes including OpenClaw, Hermes, Claude Code, and Codex without infrastructure configuration. For onboarding, it means a Cloud API that provisions an isolated, persistent, per-user sandbox in a single call.

The surrounding commitments should be equally specific. Named security coverage such as SOC 2 Type I, encryption in transit and at rest, and an explicit policy against training models on agent conversations, files, and sessions give buyers something definite to evaluate. White-label infrastructure keeps the hosting layer out of the customer experience. When per-agent pricing is easy to predict, the service is easier to sell as a product. Even with those claims, the provider should still have to pass the recovery and credential tests.

Generic compute provides infrastructure, while workflow tools address durable execution for general code. For a customer-facing business that needs one autonomous agent per user, choose managed hosting that demonstrates all four agent capabilities and automates the lifecycle around them. The hard part is provisioning, securing, monitoring, updating, and recovering an agent for every customer without turning each signup into another infrastructure job.