Managed agent runtimes.
A managed agent runtime is sold as one product and is really five — compute, the orchestration loop, a tool gateway, an identity broker, and a store for conversation state — and only the last one is hard to leave. The loop is the cheapest of the five to write yourself and the most expensive to rent, because renting it usually means renting the state welded to it. Buy the substrate; keep the loop.
What the category is, and what it is not.
Once an agent leaves your laptop, something has to hold it: a process that survives between turns, a place to put the transcript, credentials for the tools, and a trace of what happened. A managed agent runtime is a hosted service that supplies those. The hyperscaler entries are the obvious examples — Amazon Bedrock AgentCore, Microsoft Foundry Agent Service, Vertex AI Agent Engine, Cloudflare Agents — but the category is defined by the job, not the vendor.
It is a different layer from two neighbours it gets confused with. An agent framework is a library that decides how you express the loop; a runtime decides who operates it. An inference provider serves model tokens; a runtime is the thing calling it. You can and usually should mix: a framework you chose, on a runtime you rented, calling a model from whichever provider is cheapest this quarter.
The five primitives, and which of them you can actually leave.
Every runtime in the category decomposes into roughly the same five services. Sorted by how hard each is to walk away from:
- Compute — a place to execute the process. The most portable thing in software. Vendors price it accordingly; where a per-vCPU-hour rate is published at all, the market has converged to within a few percent, and some vendors do not meter it separately.
- The orchestration loop — call the model, choose a tool, feed the result back, decide when to stop. Conceptually this is the agent, and it is perhaps two hundred lines of code. Portable if you wrote it; portable-ish if a framework wrote it; not portable if the vendor's configuration format wrote it.
- The tool gateway — discovery, schemas, invocation, retries. Increasingly this speaks MCP, which is exactly what makes it re-pointable: a standard wire format is a portability guarantee.
- The identity broker — whose credentials a tool call travels on. See agent identity & permissions. Moving means re-issuing credentials and re-binding scopes: real work, bounded work.
- Conversation state — threads, sessions, and extracted memories. This is not code. It is accumulated data in the vendor's shape, and it is the only one of the five that gets harder to move every day the deployment runs.
Four of these five are a sprint. The fifth is a migration project whose size is set by how long you waited. That asymmetry is the whole subject — every other question about a managed runtime is downstream of "where does the conversation live and can I export it".
Bundling is the lock-in, not managed-ness.
It is tempting to conclude that managed runtimes are a trap and you should self-host. That is the wrong lesson, and there is a worked example. AWS launched a config-defined managed agent product in November 2023, and closed it to new customers in July 2026 — then shipped another config-defined managed agent product six weeks before doing so. Managed loops did not lose. What lost was a bundle in which the loop, the state and the model catalog were a single purchase, so freezing one froze all three.
The test that distinguishes a rentable runtime from a trap is a single question: if the loop product were frozen tomorrow, what would you still hold? If the memory store, the gateway and the identity broker are separately callable services, you hold a substrate and you rewrite two hundred lines. If they were only ever reachable through the loop, you hold nothing, and the product's end-of-life is your migration date.
Note also what a frozen model catalog does. A runtime in maintenance mode usually keeps running indefinitely, which sounds generous — but if it will never offer the models released after the freeze, the practical deadline is not the shutdown notice. It is the day the model you want is one it cannot give you.
How to choose, and what to keep in your own hands.
The comparison that matters is short, and it is not the one on the pricing pages. Ask where conversation state lives and whether you can export it; whether the primitives survive the loop product; what the runtime does to your traces and whether they leave in a standard format; and whether the vendor has retired something in this category before, because that is the only evidence you have about the next time.
Two structural options are worth naming. Some runtimes let conversation state live in a database you already own, which converts an export request into a data migration you can plan. Others give each agent instance its own real database on their platform — queryable, but shaped by an object model that exists nowhere else. Both beat an opaque managed store; they are not the same guarantee, and the difference only shows up on the way out.
Rent compute, the gateway, identity and observability without much anxiety — they are commodities with standard interfaces. Write the loop against a framework rather than a vendor's configuration format, even when the configuration format is genuinely nicer, because that file is the difference between a rewrite and a redeploy. And before you accumulate a year of threads, answer one question in writing: what does an export of the conversation store look like, and has anyone tried it? Do those two things at adoption and the exit stays cheap; retrofit them later and you will be quoting a migration.
Related: exiting a managed agent runtime for the extraction order when you do leave, durable state & resumability for what the runtime is actually solving, and the agent loop for the two hundred lines under discussion.