For most of 2025, a long-running agent had nowhere good to live. A web request dies in seconds. A serverless function dies in minutes. An agent that opens a browser, calls three tools, waits for a human to approve a refund, and finishes the job tomorrow morning fits none of that — so you built the runtime yourself: a container that never sleeps, a queue, a state store, a scheduler, and a lot of glue you didn't want to own.
That gap is the story of this month. Microsoft moved hosted agents in Foundry Agent Service to general availability in early July 2026 — a managed, per-session sandbox that keeps your agent's state and bills you only while it's awake. It's not alone: AWS Bedrock AgentCore went GA last October, Google's Vertex AI Agent Engine has GA sessions and memory, Cloudflare's Durable-Object agents shipped a GA Sandbox SDK in April, and Vercel Sandbox went GA in January. The managed agent runtime is now a category you can buy, not only a thing you assemble.
Here's the whole landscape in one screen, then the one property that should actually decide it.
The runtimes, side by side#
| Runtime | Isolation | Session limit / idle | Status |
|---|---|---|---|
| Foundry (Microsoft) | per-session sandbox, persistent files | 15-min idle → resume; durable long-run mode | GA (Jul 2026) |
| Bedrock AgentCore (AWS) | per-session microVM | up to 8 hours; 15-min idle | GA (Oct 2025) |
| Vertex Agent Engine (Google) | managed sessions + memory bank | managed | GA |
| Cloudflare Agents | one durable instance per name | persistent + durable execution | Sandbox GA (Apr 2026) |
| Self-host (container/K8s) | whatever you build | whatever you build | always |
The rows look different, but notice what they share: every one gives an agent session its own isolated compute, memory, and filesystem, and bills scale-to-zero — nothing while the session sleeps. That shared shape is the tell. It's the industry agreeing on what an agent runtime is.
The property that bills you: session isolation and duration#
Ignore the logos for a second. The number that decides fit is how long a single session stays alive and how much state it carries between steps.
A managed runtime is built for a workload that is bursty, mostly idle, and occasionally very long — which is exactly what a real agent is. It sits at zero cost, wakes when a user or a schedule pokes it, holds a browser and a working directory and a half-finished plan in memory, maybe pauses for a human approval, and resumes. The runtime's job is to make that session cheap when asleep and instantly warm when poked.
The limits are where they differ, and where you should look first:
- AWS Bedrock AgentCore caps a single session at 8 hours, with a 15-minute idle timeout, each session in its own microVM that's wiped afterward.
- Foundry deprovisions compute after 15 minutes idle but persists the session and resumes it, and adds a durable workflow mode that suspends across genuinely long external waits (their example is a 6-hour API call) plus scheduled routines for agents that run on a timer.
If your agent's real unit of work is "run for a few minutes, then sleep for a day," these are the differences that matter — not the marketing. (How the agent waits on that long external call is its own decision — poll, don't rely on a webhook, because an ephemeral session has no inbound endpoint to be called back on.)
The managed agent runtime is the first piece of AI infrastructure that a solo founder can rent instead of build. The thing you stop owning — per-session isolation, state, autoscaling, idle billing — is precisely the thing that used to take a week to get right and a month to make reliable.
Framework lock-in vs runtime lock-in#
A fair worry: does renting the runtime chain you to a vendor's agent framework? On Foundry, no. The runtime is framework-agnostic — Microsoft's overview lists Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, the Anthropic Agent SDK, the GitHub Copilot SDK, or your own code, behind an OpenAI-compatible Responses protocol.
But be precise about where the lock actually is. You can write the agent in a portable framework and still be tied to the runtime and identity layer — Entra Agent ID on Foundry, IAM on AWS, a region list, a networking model. Leaving later means re-hosting, even if you never rewrite the agent's logic. That's the real switching cost, and it's smaller than a framework rewrite but not zero.
The decision#
Don't pick on the brand. Pick on the session.
- Long-lived, stateful, idle most of the time — a support agent, a research agent, a scheduled ops agent → a managed runtime, and let it delete the isolation, state, and idle-billing plumbing you'd otherwise own.
- Short and stateless — a tool call that returns in seconds → keep it in a plain serverless function or container. A managed runtime is premium compute you don't need.
- Already running Kubernetes, agent isn't especially long-lived → self-host still wins on cost and portability. The managed premium buys you time you don't need to spend.
- Regulated, region-pinned, or private-network required → check the region list, the identity model, and bring-your-own-VNet support before you build. Foundry added private container-registry support for projects created after June 25, 2026; these are the details that block a launch late if you skip them.
The quiet significance isn't that Microsoft shipped one more service. It's that "where does my agent run" stopped being an architecture project and became a line item — and for the solo builder, a line item you can afford is the difference between an agent that ships and one that stays a demo. Model the bill on peak concurrent active sessions, confirm the per-vCPU rate on the live pricing page, and rent the runtime you were about to build.
