A managed agent runtime is a hosted agent loop. The vendor runs the orchestration, context compaction and subagent coordination; you supply the tools and the task. Three shipped during 2026, and the question is no longer whether they work. It is which part of your agent now lives on somebody else's control plane, and what that costs you in data retention, data residency and the price of leaving.
What actually shipped in 2026?
OpenAI put its Agents API into public beta on 10 September 2026. It exposes the same Codex harness that drives OpenAI's own coding agent through a single session call, with context compaction, tool search, programmatic tool calling and parallel subagents all handled server-side. Anthropic got there first: the Managed Agents beta carries the header managed-agents-2026-04-01, which dates the interface more reliably than the launch-day write-ups do, since published accounts put the announcement variously on 8, 9 and 10 April. Google arrived from the opposite direction. ADK 2.0 rebuilt the framework itself as a graph execution engine, with BaseAgent now subclassing BaseNode, and deploys onto Vertex AI Agent Engine.
This is a different layer from the one we wrote about in AI agent frameworks 2026. A framework is a library you run. A managed runtime is a service that runs the library for you. What happened in 2026 is that the loop itself became a product you rent.
The pitch is strong and mostly honest. Long sessions survive context limits because the vendor compacts earlier turns for you. Subagents fan out without you writing an orchestrator. Tool definitions load on demand instead of burning tokens on a catalogue the model will not use. And a harness maintained by the people who trained the model tracks it better than one you maintain on the side.
Where does the loop run, and where do the tools run?
These two questions used to have one answer. In 2026 they came apart, and confusing them is how compliance reviews go wrong.
Anthropic exposes an environment object whose config type is either cloud or self_hosted. Cloud runs the container on Anthropic's infrastructure. Self-hosted moves tool execution into yours: you run a worker holding an environment key, it polls Anthropic's queue, and the agent's bash commands, filesystem and network egress never leave your perimeter. The agent loop still runs at Anthropic. OpenAI offers the same shape with more options: an OpenAI-hosted sandbox, your own compute, or one of nine named partners including Cloudflare, Modal, E2B, Oracle and Vercel.
So your customer files can sit in a container in Amsterdam while the transcript of what the agent thought about them does not. A self-hosted sandbox answers where the code runs, not where the session is stored. Teams read the first answer and assume it covers the second, and that is the most common error we see in agent architecture reviews this year.
Why does the managed endpoint lose Zero Data Retention?
Here is the part almost nobody has written down. OpenAI publishes a per-endpoint retention table in its data controls documentation, and the rows side by side make the trade explicit.
The chat completions and responses endpoints are both listed with application state retention of None, Zero Data Retention eligible, and eligible for Eyes Off and Safety Retention. The agents endpoint is listed with application state retention of Until deleted, not Zero Data Retention eligible, and not Eyes Off eligible. Conversations, threads and vector stores sit in the same not-eligible group, which gives you the principle.
The Agents API overview says the same thing in prose: the Agents API supports data residency only in the United States, and does not support Zero Data Retention. One sentence there settles the question the previous section raised. Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible. A container in your own cloud account is a location; Zero Data Retention is a contract, and moving the first does not buy the second.
So a team that built its own loop on the responses endpoint under Zero Data Retention, then migrates it onto the managed Agents API for free compaction and subagents, drops out of Zero Data Retention. Nothing about that migration looks like a compliance change. It looks like deleting orchestration code. If your data protection impact assessment or your customer contract names Zero Data Retention, this is a blocking change, not a refactor. None of which is hidden, or a scandal: it is the bill for the feature, because a session that survives a restart is a session somebody stored. The mistake is choosing the runtime without reading the row.
Can you keep a managed agent's data in the EU?
OpenAI documents both regional storage and regional processing for Europe, covering the EEA and Switzerland, through a prefixed endpoint at eu.api.openai.com. Two conditions attach: residency outside the United States requires approval for abuse monitoring controls and a modified retention amendment, and residency endpoints carry a 10 percent uplift for eligible models released on or after 5 March 2026. Support for regional storage does not imply support for regional processing, and eligibility is enumerated endpoint by endpoint. For the Agents API the enumeration is already done, and the answer is the United States.
Anthropic states its limitation flatly rather than leaving you to infer it. The inference geography setting accepts only United States or global, and the workspace geography governing data at rest is United States only, fixed when the workspace is created. The route to EU processing for Claude runs through AWS Bedrock or Google Vertex in a European region, which is not where the Managed Agents control plane lives. You can have Claude in Europe, or Managed Agents. Today those are different architectures.
Google is the interesting one for a Dutch reader. Vertex's agent platform location list includes europe-west4, and europe-west4 is Eemshaven, in Groningen. That makes it the only one of the three whose managed agent plane can be pinned to a datacentre on Dutch soil. Google attaches a caveat worth stating: its documentation warns that a regionalised resource may not sit physically in the region you specified, and points anyone with a hard regulatory requirement to the specific service's residency commitment.
If nothing acceptable exists yet, that is a legitimate finding, and it points at a different architecture: private AI assistants, where the model runs inside your own environment and residency stops being a vendor's question to answer.
What do you actually rewrite if you switch vendors?
Portability arguments tend to be asserted rather than itemised. Here is the itemisation.
Your MCP servers survive. All three runtimes speak the Model Context Protocol, and the 2026-07-28 specification made the protocol core stateless, so a tool server written once keeps working against a different harness. This is the one genuinely load-bearing piece of standardisation in the stack, and the reason to write your tools as MCP servers before choosing a runtime rather than after. Prompts and skills mostly survive too, being text, though the scaffolding each harness wraps around them does not: expect to re-tune rather than copy.
Your session model does not survive. Anthropic uses a strict two-step shape: create a versioned Agent object once, then create Sessions that pin to a specific version, with the model, system prompt, tools and MCP servers living on the agent rather than the session, though a session may override exactly those fields for its own run. OpenAI's session carries the agent configuration inline at creation. Google's is a workflow graph of nodes. Your control code is written against exactly one of those, and none of the three translates.
Your operational surface does not survive either, and this part gets underestimated. When an Anthropic session needs you, it does not fail: a pending tool confirmation leaves it idle with a stop reason of requires_action and the blocking event IDs attached. Your client is expected to reconnect, list the event history and deduplicate by event ID, because the opt-in event deltas are best-effort and never persisted while the buffered events are. That reconnect logic is real code, vendor-specific, and none of it transfers.
So the honest estimate for a switch is: your tools come with you, your control plane integration does not. Budget a migration as rewriting the loop you adopted the runtime to avoid writing. That is not an argument against adopting one, but for keeping the model-independent posture that makes the number small.
How do they bill you, and why does that change the design?
OpenAI states plainly that there are no additional fees for the Agents API: you pay for the tokens and tools your agents use. Anthropic bills session runtime on top of token rates, and its pricing page puts that at 0.08 dollars per session-hour. Third-party breakdowns circulate a higher figure, so take it from the vendor. The detail that actually governs architecture is what does not count: runtime accrues only while a session is running, so time spent idle waiting for your next message or for a tool confirmation is free.
That reverses the obvious reading, which is worth saying out loud because the obvious reading leads to bad architecture. Time billing does not punish the human approval step, because the wait is idle and idle costs nothing. It punishes long unattended stretches where the agent is genuinely working. So do not tear a session down to rebuild your own state around an approval that takes hours: leaving it open is what the runtime is for. A re-read of a large context shows up on the token bill, not the clock.
What would we tell a Dutch team building this quarter?
This lands hardest on companies large enough to have a data protection impact assessment and small enough not to have a platform team, which in practice means roughly 50 to 500 people. That is the band where a managed runtime looks most attractive, because it removes exactly the infrastructure work you cannot staff, and where the retention and residency rows bite hardest, because you carry a compliance obligation and nobody whose job it is to read endpoint tables. We set out the wider sequence on applied AI for mid-sized businesses.
Five steps, in this order. First, write your tools as MCP servers before you choose a runtime, because that is the portable asset. Second, pull the retention and residency rows for the endpoints you will call, into the architecture review rather than a footnote. Third, decide what a self-hosted sandbox actually answers: if the concern is customer files, it helps; if it is the transcript, it does not. Fourth, keep your own evaluation and tracing, because a managed harness hands you its events but will not tell you whether the agent was right; that gap is the subject of AI agent observability. Fifth, do not let the harness blur who is responsible.
On that last point the EU AI Act position is worth stating carefully. The Digital Omnibus, Regulation (EU) 2026/1744, deferred the core high-risk obligations for Annex III systems to 2 December 2027, so the high-risk clock runs later than most 2025 planning assumed. What was not deferred is the Article 4 AI literacy duty, which the Omnibus rewrote into a duty to take measures supporting literacy rather than to guarantee it, and which binds providers and deployers alike, nor the Article 50 transparency duties on disclosing AI interaction and marking generated content. Renting somebody else's harness does not rent their obligations.
None of this argues against managed agent runtimes. For most teams building their first serious agent they are the right default, for the same reason most teams should not run their own database. The argument is narrower: the loop did not disappear when you stopped writing it. It moved, and it took your state with it. Read the table before you sign. For which shape fits a specific process, that is what our AI agent development work is for, and the proof-of-concept cost page sets out what a first build runs.
