Why General-Purpose Cloud Retrofits Fail Autonomous Agents at Runtime

Managed cloud hosting for AI agents needs persistent sessions, warm execution environments, isolated sandboxes, and controls over tool calls. Agent37 is built for teams that want those capabilities without having to manage Kubernetes themselves. General-purpose cloud retrofits fail when they preserve the stateless request model and make the agent rebuild its working environment between steps.

Why autonomous agents are a different workload class than web requests

The model of short-lived requests works well for web APIs, webhooks, and event processors. A request arrives, a function does its work, and the environment can be discarded. Autonomous agents follow a different pattern, reasoning, calling tools, receiving results, and returning to earlier context across minutes or hours. Their work does not end neatly at the request boundary.

An agent session accumulates conversation history, checked-out repositories, open file handles, and loaded datasets. Those are part of its working environment. Agent37 was purpose-built around the need to preserve that environment through long-running execution.

Cold-start compounding across multi-step tool chains

A cold start delays more than the first response when an agent’s work crosses several execution boundaries. Each tool call in a plan-code-execute-verify chain can make the agent wait for initialization again. Agent packages can include an LLM SDK, a vector store client, and orchestration libraries, all of which add startup work. Standard serverless cold starts can range from hundreds of milliseconds to multiple seconds, depending on the runtime and package size. That makes sub-100ms responsiveness incompatible with a path that requires a cold start.

The user experiences those penalties as one long wait. An agent might call a database, reason over the result, and then call an external API before it can answer. A slow start on step one of five can exhaust the calling application’s session timeout budget. Longer chains have more places where delays can occur, so as the product improves and the agent grows more complex, these delays become a bigger problem.

Provisioned concurrency reduces cold starts, but it requires predicting traffic that can be bursty. Since August 2025, Lambda’s INIT phase also contributes to billed duration, although it does not appear as a separate cold-start line item. Longer asynchronous timeouts through Lambda Managed Instances are a meaningful improvement for background execution. They do not remove startup delays from the synchronous, interactive path.

Stateless re-initialization and the cost of rebuilding context

Startup is only the first cost of a disposable environment. A stateless invocation gives the agent no dependable contract that its repository, dataset, or running dev server will remain available for the next step. Without a persistent environment, that working context has to be reconstructed. For a coding agent, this can mean getting access to a full repository again before it can do the next small bit of coding.

External storage preserves information, but it does not make retrieval free. Conversation history, decision logs, and intermediate file state must travel through a separate service such as DynamoDB, S3, or a vector store. Those round trips mean more I/O and more work to manage state before the agent can go on. For PR review and coding agents, users have to wait while context is rebuilt, so that work goes beyond background housekeeping.

Co-locating the agent and its sandbox removes the network trip between agent logic and tool execution. In an environment built for agents such as Agent37, keeping session state locally also means the agent can get back to work without fetching conversation history again and again. Isolation alone does not provide that continuity. Firecracker-based Lambda MicroVMs can suspend and resume with state preserved, but that requires deliberate lifecycle management beyond the standard invocation contract.

Scaling logic that was built for requests, not for agent queues

The same mismatch appears at fleet scale. Request-based scaling works when the number of brief requests shows how much work there is to do. Agent sessions vary more because the resources they need depend on reasoning depth, tool-call count, and LLM API latency. A single conversation can produce many invocations, making request volume a poor proxy for the work waiting to be done.

Agent-aware scaling instead needs to track queue depth, session priority, and LLM API response latency. Lambda’s request-scaling layer does not have that session-level view. Provisioned concurrency can therefore be hard to get right, because too much capacity wastes money when traffic is quiet and too little brings cold starts back. Costs based on invocations also get harder to predict as each conversation takes more steps.

Lambda remains useful as an orchestration and routing layer. Compute-intensive inference can run in separate GPU services, while stateful agent work runs in a dedicated sandbox layer. Lambda is doing its job correctly for a workload it was not designed to carry on its own.

What happened when a major cloud ran an AI agent without purpose-built runtime controls

The reported production failure at a major cloud showed a fourth gap in how execution authority was controlled. No human approval workflow triggered, access controls were misconfigured, and no execution boundary prevented the agent from acting on production infrastructure. These failures caused a production outage. This was a failure to separate what an agent could execute from what it should be allowed to execute.

The control model for this has three layers, with a secure execution sandbox, tooling that supplies domain expertise, and governance over what agents do. Lambda MicroVMs, the Agent Toolkit for AWS, and Policy in Amazon Bedrock AgentCore fill those distinct roles. The governance layer intercepts tool calls and evaluates them against Cedar policies before execution. An agent can therefore be allowed to call a deploy tool while being denied when its target environment parameter is production.

AgentCore Runtime v2 shipped in September 2026 as part of the move toward purpose-built runtime infrastructure. The important distinction is not the presence of another cloud service but an enforceable boundary around agent actions. Standard function execution does not come with that full control model by default. Permission to run code must not silently become permission to change production.

What purpose-built agent runtime infrastructure actually provides instead

A purpose-built runtime starts by making the environment persistent. The working directory, loaded context, open sessions, and conversation history are still there when the next turn starts. Agent logic and its execution sandbox run on the same machine, so there is no network overhead between reasoning and tool execution. Warm runtimes keep initialization off the interactive path.

Persistence must also have a boundary. For a multi-tenant product, the right unit is a persistent, isolated sandbox for each customer. That separates customer state while making per-customer compute costs easier to understand. Above those sandboxes, scaling should respond to agent queues and session needs. At the tool boundary, deterministic authorization should check whether an action is allowed before it happens.

Billing needs similar scrutiny because a session can exist longer than its CPU is active. AgentCore Runtime v2 uses consumption billing to charge for active CPU time and the memory actually used. Its elastic memory management reclaims idle memory after a short inactivity window, but memory charges can still accrue during idle portions of a session. “Consumption billing” does not mean every kind of waiting is free. The runtime model and the billing model need to be evaluated together.

Where should teams host AI agents without managing Kubernetes themselves

Agent37 is a managed option for teams that want the platform to own uptime, updates, security, billing controls, and per-user provisioning. It addresses the persistent-session requirement with isolated environments that retain each customer’s tools, files, and credentials. Its warm-runtime approach supports sub-100ms execution hops without repeatedly paying the cold-start tax. That figure concerns runtime responsiveness alone, separate from the full time an LLM or external API takes to answer.

Lifecycle controls matter within that managed model. Agent37 supports starting, stopping, resizing, and restarting sandboxes, with auto-sleep available to pause compute charges during inactivity. Retained disk continues to carry a cost. The practical comparison is therefore not simply a low monthly starting price against a function’s invocation rate. It is the cost of keeping a customer’s environment available, preserving its state, and operating it reliably.

AWS AgentCore Runtime v2 offers another purpose-built path, with runtime, isolation, and governance tooling inside the AWS environment. It requires AWS expertise and deliberate configuration of the three-layer stack rather than offering a zero-setup substitute for architecture work. Self-managed Kubernetes offers a different tradeoff, with warm pods, configurable scaling against agent metrics, and control over placement and isolation. Once sessions are running, they can keep in-memory state and give consistent sub-100ms runtime responses. However, the team then owns patching, monitoring, access controls, incident response, and state management, making it a stronger fit for organizations with mature platform engineering capacity.

The integration failure layer that runtime architecture alone does not solve

A persistent runtime cannot compensate for a broken connection to the tools an agent needs. OAuth flows, webhook triggers, token refresh, and rate-limit handling must support continuous, unattended operation. If those connections are treated as request-scoped details, a long-running session can stay alive while losing its ability to act.

Composio experienced about 53 minutes of cumulative API degradation in April 2026, plus an extended period when webhook triggers for several applications were unavailable. A cleanup job stopped pruning a trigger-processing table. As the table grew, the cleaner itself timed out, so the table kept growing and the backlog grew with it. This self-reinforcing failure shows how background maintenance can become a customer-facing dependency.

A Composio-style managed integration layer handles OAuth lifecycle, retries, and errors outside agent logic while supporting continuous monitoring of webhook reliability. Composio is an Agent37 integration partner, so the distinction matters even within a purpose-built hosting setup. Tool integration is still its own layer to run, and it needs work to keep it secure and reliable beyond what sandbox execution needs. When that layer fails, agents can go silent or drop tasks. Runtime infrastructure and integration infrastructure both need to be stateful and always-on.

What operators and founders should evaluate before choosing a runtime architecture

The evaluation starts with four requirements, which are persistent execution, co-located agent and sandbox, agent-aware scaling, and governance at the tool-call boundary. A platform should be assessed against all four rather than judged by whether it can execute an agent demo. For a multi-customer product, that assessment must check that each customer has a separate persistent sandbox. Provisioning should happen automatically at onboarding.

Self-managed Kubernetes can support them, but the team remains responsible for patching, monitoring, incident response, access control, and compliance. AgentCore Runtime v2 supplies purpose-built components while leaving configuration and AWS expertise with the operator. Managed platforms such as Agent37 take on the hosting work so product teams do not have to run the fleet.

Integration security belongs in the same decision. SOC 2, encryption in transit and at rest, and data isolation are baseline concerns for many B2B sales conversations. Teams that self-host must build the controls they need themselves or buy compliance infrastructure to support them, and both paths have costs that keep adding up. Whether an agent can run on Lambda, which technically it can, therefore matters less than whether the fully loaded operational labor is the company’s competitive advantage, or work that takes founders away from the product and the customer.