Claude Managed Agents, Gemini and Microsoft Agent Framework: Build or Buy Your Agent Runtime?

In six weeks, three of the largest AI platforms started offering to run your agents for you. Anthropic launched Claude Managed Agents on April 8. Microsoft relaunched hosted agents in Foundry Agent Service on April 22. On Tuesday, at Google I/O, Google added Managed Agents to the Gemini API.

They look like one product and sell different things. Anthropic and Google host their own harness, the loop that decides what the agent does next, running on their own models. Microsoft hosts your container and does not mind which framework is inside it. Only Anthropic's announcement states a runtime price.

Every number and claim below is the vendor's own unless I say otherwise. I have not run any of the three, and I found no independent comparison. Microsoft also shipped Agent Framework 1.0 in April, which matters to anyone with Semantic Kernel code, so I cover that too.

Claude, Gemini and Foundry managed agents compared

Since launch, Anthropic has added memory (April 23) and self-hosted sandboxes (May 19), and moved multiagent orchestration and outcomes into beta (May 6). Google's agent runs through the Interactions API and takes skills as markdown files such as SKILL.md. Microsoft lists LangGraph, Agent Framework, the Claude Agent SDK, the OpenAI Agents SDK and the GitHub Copilot SDK among the frameworks you can bring.

As of May 21	Claude Managed Agents	Gemini Managed Agents	Foundry hosted agents
Status	Public beta since April 8	Public preview since May 19	Public preview, refreshed April 22
Who writes the loop	Anthropic's harness, on Claude models	Google's Antigravity agent, on Gemini 3.5 Flash	You do, in a container, with any framework
Isolation	Sandboxed containers, started when a tool needs one	An isolated, ephemeral Linux environment	A VM-isolated sandbox for each session
State	The session is a durable event log; memory in beta	Resume an environment with files and state intact	Files, disk state and session identity survive scale to zero
Credentials and identity	Credentials held in a vault outside the sandbox	Not described in the launch posts	An Entra Agent ID for each agent
Observability	Session tracing in the Claude Console	Not described in the launch posts	OpenTelemetry traces into Application Insights
Published price	Tokens plus $0.08 per session-hour of active runtime	None in the launch posts	No rates in the announcements; nothing charged while idle

Source: vendor announcements, release notes and documentation, listed at the end.

What a managed agent runtime buys you

The hard parts of a long-running agent are rarely the model call. They are a sandbox per session, state that survives a crash or a dropped connection, credentials that generated code cannot read, and a trace of every step. That is what all three are selling.

Anthropic's engineering post is worth reading for the credential problem alone. In its first design the harness, session and sandbox shared one container, so model-written code ran next to the credentials, and a prompt injection only had to talk Claude into reading its own environment. The redesign keeps OAuth tokens in a vault outside the sandbox and sends MCP calls through a proxy. In Anthropic's words, "The harness is never made aware of any credentials."

That closes one door, and only one. A secret that never enters the model's context cannot be repeated by the model; it can still be misused through a tool that holds it. An injected instruction can no longer read the token, but it can still ask the proxy to use it. The PocketOS deletion last month took one over-scoped token and one API call. A vault does not narrow the scope of the token inside it.

Isolation has the same limit. A VM per session keeps one session's code away from another session's files. It does nothing about what the agent's identity can reach in your systems, and a sandbox is only as good as its configuration, as the Claude Mythos Preview system card showed in April. Buying the sandbox moves that work to the vendor. It does not remove it.

Managed agent pricing: the runtime fee is small and the tokens are not

Anthropic charges standard token rates plus $0.08 per session-hour of active runtime. By my arithmetic, a session must be active for 12.5 hours to cost a dollar in runtime, and one active around the clock for a 30-day month comes to $57.60. For most agent work I would expect tokens to cost far more, so the figure to compare is still cost per task, not cost per hour. The launch post does not define active runtime, so I would ask whether waiting for my own tools, or for a human approval, counts.

Google's launch posts give no price for the environment. Microsoft's give no rates either, only that an idle agent costs nothing, that compute is released after 15 minutes without a request, and that an unused session is kept for up to 30 days. Preview pricing is a weak basis for a budget anyway.

Lock-in sits in a different place with each vendor

With Anthropic and Google, you buy the harness and the model together. Your instructions, skill files and the services behind your tools can move. The loop's behaviour, the session API and the event history stay with the platform, so switching models later means building the part you chose not to build.

Previews also move under you. Google's changelog of May 6 announced a breaking change to the Interactions API schema, with the old schema due for removal on June 8. The migration work is yours.

With Microsoft, the loop and the framework are yours. The lock-in is the platform around them: an Entra identity for each agent, traces in Application Insights, Foundry endpoints and versioning. That is easier to leave than a harness, because your container holds the logic, and harder than it looks, because identity and telemetry end up in everything.

My rule of thumb: if the agent's behaviour is your product, own the loop and rent the hosting. If the vendor's harness is good enough and you would not switch models anyway, renting the harness is a reasonable trade.

Microsoft Agent Framework 1.0 and your Semantic Kernel code

Microsoft published Microsoft.Agents.AI 1.0.0 on NuGet on April 2 and announced Agent Framework 1.0 for .NET and Python the next day, with stable APIs and a commitment to long-term support. Since last October, Microsoft has called it the successor to Semantic Kernel for building AI agents. Semantic Kernel keeps fixes for critical bugs and security issues, most new features go to Agent Framework, and support continues for at least a year after Agent Framework's general availability. By my arithmetic that floor falls in April 2027. It is a floor, not an end date.

For agent code, the move is mostly mechanical. I compared the mapping in Microsoft's migration guide with the samples at the 1.0 release tag:

Semantic Kernel	Agent Framework 1.0
A `Kernel` behind every `ChatCompletionAgent`	An `AIAgent` from `chatClient.AsAIAgent(...)`, with no kernel
`[KernelFunction]` methods wrapped in a plugin	Plain methods passed as `AIFunctionFactory.Create(...)`
`agent.InvokeAsync(...)`	`agent.RunAsync(...)` and `RunStreamingAsync(...)`
An `AgentThread` you create for each provider	An `AgentSession` from `agent.CreateSessionAsync()`
Semantic Kernel message and content types	The types from `Microsoft.Extensions.AI`

Source: Microsoft's migration guide and the dotnet-1.0.0 samples.

Hosting is the unfinished part. The 1.0 announcement listed the Foundry hosted-agent integration as a preview feature, and Microsoft's May 6 post says the team is working towards general availability. The framework is stable; its managed home is not.

For a Semantic Kernel application in production, I would not migrate for its own sake. I would write new agent code on Agent Framework and move existing agents when they need something only it has, which is close to Microsoft's own advice.

First, decide whether you need an agent loop at all

Everything above assumes the work needs an agent that chooses its own next step. Often it does not.

When I built Career Rafeeq, an AI SaaS product, I chose a deterministic pipeline instead of an agentic loop: eight fixed phases, from validating the job description to generating the summary. Phases fan out in parallel where the data allows, and the refinement phase fires only below a confidence threshold, so the expensive path runs only when the cheap one is unsure.

A fixed pipeline has a known number of steps, so its cost, latency and failure points are known before it runs. Nothing chooses the next step, so there is no harness to rent, and if no model-written code runs, there is no sandbox to pay for by the hour. Managed runtimes are built for open-ended work, where the next step depends on what the last one found. I suspect that is a smaller share of production work than the launch posts imply.

What I would test before adopting a managed agent runtime

Kill the sandbox mid-task. Anthropic says a dead container reaches the model as a tool-call error. Check whether your agent then repeats work with side effects.
Try to reach a secret from inside. Plant an instruction in a document the agent reads, then try to misuse a tool that holds a credential.
Meter a real workload. Record active runtime, idle time and tokens for a representative task, and find out how waiting is billed.
Measure cold start and resume. Anthropic reports that starting containers only when a tool needs one cut median time to first token by about 60%. Measure your own.
Find out where the transcript lives. Session history, files and memory sit with the vendor. Check retention and deletion against your data agreements.
Rehearse leaving. Replay a week of tasks through a loop you control. If you cannot, you have found your lock-in.

All three will now happily host an agent that runs for hours. Before signing up, it is worth checking that yours was not meant to be a function.

Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on agentic AI, AI SaaS products, and .NET platforms.