June 10, 2026
“Managed agents” are convenient until you can’t leave
Google, Anthropic, and others are pushing the easiest pitch in AI: one API call and we'll run your whole agent — the sandbox, the tools, the memory, the state — on our infrastructure. It's genuinely convenient, and for a prototype it's great. But notice what you just handed over. A managed model API rents you the brain, which stays swappable. A managed agent rents you the entire nervous system of your product, and that's a much deeper hook. Convenience and lock-in are the same purchase here — and the bill comes later.
The hottest pitch in AI right now is the managed agent. Google made Managed Agents in the Gemini API official this season: one API call spins up an agent in an isolated cloud sandbox where it reasons, plans, calls tools, runs code, manages files, and keeps state — and Google's infrastructure handles all of it, so you provision nothing. Anthropic shipped its own Claude Managed Agents as a one-stop shop. The promise is the same everywhere: skip the plumbing, ship the agent in a day.
It is genuinely convenient, and I don't want to pretend otherwise. For a prototype, a throwaway, a thing whose stakes are low, a managed agent is a great deal. But it's worth being clear-eyed about what you're actually buying, because convenience and lock-in are, in this case, the exact same transaction — and the cost shows up much later than the convenience does.
You're not renting a model anymore. You're renting the nervous system.
Here's the distinction that matters. I've written before that a model behind a clean seam stays swappable — you rent the brain, and you can change brains with a config value. A managed agent is a different purchase. You're not just renting the model; you're renting the runtime (where the agent executes), the memory and state (what it remembers across runs), the tool layer (how it acts), and the observability (how you see what it did). That's not one component. That's the entire operating system of your product, running inside one vendor's walls.
And unlike the model, those parts accumulate. As the analysis of this wave puts it, you end up embedding your agent architecture into the platform's runtime, governance, and observability in ways that compound over time and become increasingly difficult to unwind. The longer it runs, the more of your product's memory and behavior lives somewhere you can't easily take with you. This is the context-lock-in problem from a few weeks ago, pushed one layer deeper: not just your data, but the whole machine that acts on it.
The 10% test
There's a brutal stat worth keeping in your pocket. One 2026 assessment found that roughly 90% of AI "agent" launches are vendor-controlled feature-wrappers — they lack persistent state you control, model portability, and external auditability. Only about 10% are genuine, portable platforms where the agent can actually run independently of the vendor's infrastructure.
That gives you a clean gut-check for any managed-agent product: can you take your agent's memory, tools, and definition and run them somewhere else? If yes, it's a real platform and the convenience is free. If no — if your agent's brain, memory, skills, and runtime are all the vendor's, with no export — then it's not a platform, it's a feature with an exit fee, and the fee is your whole product.
Use it for speed, decouple what compounds
This isn't a "never use managed agents" argument — that would be silly, the speed is real. It's a "know which transaction you're making" argument. The pattern the sharpest teams use is to decouple the parts that compound from the vendor's runtime: keep the memory layer, the tool/skill library, and the orchestration in formats you control, so you can switch the runtime without losing your product's accumulated state. A few practical lines:
- Managed is fine for low-stakes and prototypes; decouple for anything core. The faster you'd be hurt by being unable to leave, the less of your nervous system should live in the vendor's runtime.
- Own your memory and your tools. Your agent's accumulated state and its tool/skill definitions are the parts with gravity. Keep them exportable and in open formats — leaning on open layers like MCP for tools — so they're not trapped in one runtime.
- Apply the same exit test you'd apply to a model. I keep asking of a provider: if they doubled the price or shut the service tomorrow, how long to move? Ask it of the agent runtime too. If the honest answer is "we couldn't," you didn't buy convenience — you bought a dependency.
- Watch the data, not just the runtime. Logs, traces, and any fine-tuning live somewhere; if they only exist inside the managed service with no export, that's lock-in wearing a dashboard.
The bottom line
Managed agents are the most seductive offer in AI because they remove the most annoying work — the runtime, the plumbing, the state management — with a single call. And that's exactly why they deserve a second look. The plumbing they remove is also the part that, once it's full of your product's memory and behavior, you can't get back without rebuilding it.
So take the convenience where the stakes are low, and where they're not, remember what you're handing over: not a model you can swap, but the whole machine your product thinks with. Build so the parts that compound — memory, tools, orchestration — are yours and portable, and let the vendor run the boring execution underneath. Get that boundary right and managed agents are pure leverage. Get it wrong and one convenient API call becomes the reason you can never leave.
Comments
No comments yet
Sign in to join the conversation.
Be the first to share a thought.