Managed Agent Runtime vs Self-Hosted: The Four Handoffs You Are Actually Signing

Managed agent runtime vs self-hosted: AWS, Microsoft and Google now sell the harness. Four handoffs decide whether you can ever take your agent stack back.

Managed Agent Runtime vs Self-Hosted: The Four Handoffs You Are Actually Signing

A team I worked with spent six weeks choosing an agent framework. They shipped none of it.

The evaluation was rigorous. Feature matrices, three bake-offs, a scoring rubric with weights. And it was aimed at the wrong layer, because the managed agent runtime vs self-hosted question was never on the agenda. By the time anyone asked where the loop would actually run, two of the three finalists had shipped hosted runtimes of their own and the matrix was stale.

That is not a story about slow procurement. It is a story about a category boundary moving underneath a decision while the decision was being made. Between April and August 2026, AWS, Google, Microsoft and Alibaba all turned the agent loop itself into billable managed infrastructure. The thing you used to write is now something you rent.

Why is the framework debate the wrong debate?

Start with the number that reframes everything. Research out of MBZUAI's VILA-Lab, cited in InfoQ's coverage of Microsoft's Agent Framework, estimates that roughly 98% of an agent codebase is harness infrastructure and about 1.6% is AI decision logic.

Sit with the ratio. The harness is the tool router, the retry policy, the step limiter, the history store, the context compactor, the approval gate, the trace exporter. The "agent" part, the bit where a model decides something, is a rounding error by volume.

Which means the framework debate was always a harness debate wearing a costume. Teams argued about abstractions and syntax when what they were really selecting was who owns the 98%.

An arXiv paper from this cycle makes the same point from the evaluation side: comparing LLM agents without disclosing the harness conflates model quality with engineering, because the scaffolding accounts for most of the observed behavior. If you cannot compare two agents without holding the harness fixed, the harness is the system.

So when a hyperscaler offers to operate that layer for you, they are not offering a convenience. They are offering to own almost all of it.

What did the hyperscalers actually ship?

Four announcements, one shape.

Microsoft moved Agent Framework from an SDK to a supported production runtime. The Agent Harness and Foundry Hosted Agents reached general availability, with planning, per-call history persistence, context compaction, tool approval, file memory, and OpenTelemetry on by default. Each default is individually removable, which matters more than it sounds. One detail is worth reading twice: the framework halts its loop after 40 round-trips, against a compared runtime that ran to 300. The brake lives inside the loop, not in your monitoring.

AWS put the loop behind two API calls. AgentCore exposes CreateHarness and InvokeHarness, runs per-session microVMs, allows model portability mid-session across several providers, auto-provisions memory, and supports five tool types including remote MCP. Pricing is consumption-based across five or more meters plus inference, currently around $0.0895 per vCPU-hour and $0.00945 per GB-hour. Model your own workload; do not reason from a headline rate.

Google folded all of Vertex AI into the Gemini Enterprise Agent Platform, which is now the exclusive delivery vehicle for those services. Components include Agent Runtime, Sandbox, Memory Bank, Identity, and a gateway with Model Armor.

Alibaba announced an Agent-Native Cloud suite at WAIC.

The convergence is real but it is convergence on primitives, not on interfaces. Every one of these ships a managed runtime, sandboxed execution, durable memory, agent identity, a policy-enforcing tool gateway, and observability. None of them ships a common surface for those primitives. Cross-cloud portability still runs through your own abstraction layer or through open protocols like MCP and A2A.

The Four Handoffs

Here is the framework I use when a team is weighing a managed agent runtime vs self-hosted harness. Adopting a managed runtime is not one decision. It is four handoffs, and they have very different reversibility.

1. The Loop. Step limits, retries, halting, planning mode. This is the handoff nobody negotiates and it is the one with teeth. Microsoft halts at 40 round-trips. Another runtime ran to 300. That difference is a spend policy expressed as a constant, and it now lives in someone else's code. Ask what the ceiling is, whether you can set it, and what happens at the boundary.

2. Memory. Session state, history persistence, compaction strategy, what gets evicted and when. Managed runtimes auto-provision this, which is genuinely useful and quietly consequential. Compaction decides what your agent forgets. If you cannot inspect the compaction policy, you cannot explain a failure that came from forgetting.

3. Identity. Who the agent acts as, how that principal is minted, and whether it is legible to your existing IAM. This is the handoff most likely to collide with the work you already did. It also connects directly to the session debt the stateless MCP spec created, because a managed runtime is one of the places that debt can get paid, or hidden.

4. Evidence. Traces, evals, audit trail. This is the handoff trending in your favor. Microsoft Foundry's tracing and evaluations are now generally available and framework-agnostic over OpenTelemetry, so pointing an existing OTel exporter at it lights up tracing regardless of the orchestration stack underneath. Evidence is the one layer where the industry is converging on an open standard, which makes it the cheapest handoff to reverse.

Rank your handoffs by reversibility, not by feature richness. Evidence is cheap to take back. The Loop is expensive. Memory is expensive and invisible, which is the worst combination.

What is the Export Test?

One question separates a runtime you are using from a runtime you are inside.

For each of the four handoffs, can you get it back as code you own, and has the vendor documented how?

AWS answers this partially and in writing: AgentCore documents an export path to Strands code, with a Claude Agent SDK export listed as coming soon. That is a real answer, and the fact that it is written down is worth more than the feature itself, because it means someone committed to a shape.

Treat a documented config-to-code export as a hard requirement, not a nice-to-have. If the answer is a roadmap slide, you are not evaluating a runtime, you are evaluating a relationship.

How do you tell GA from preview?

Check the docs, not the press release.

AWS's own documentation and regions table still say preview in places where its announcement says GA. This is not a gotcha, it is a normal artifact of staged rollouts, and it is exactly the kind of detail that turns into a production incident when a service is generally available in the launch region and not in yours.

The same skepticism applies to deployment metrics. Treat any vendor's adoption numbers as marketing until somebody independent reproduces them.

What I'd actually do

Two things, this quarter.

Write down your four handoffs before you take the meeting. For each of the Loop, Memory, Identity and Evidence, record what you currently own, what you would be handing over, and what it would cost to take it back. Most teams discover they have never written down their own step limit. That is the finding, and it is free.

Make Evidence the first handoff, not the last. Because tracing and evals are converging on OpenTelemetry, you can adopt a managed evidence layer now with low lock-in and get an honest baseline of what your agents actually cost and how often they actually succeed. Then decide about the Loop with data instead of a bake-off.

The framework wars are over and almost nobody noticed the terms of the peace. The question is no longer which library you standardize on. It is which 98% you are prepared to stop owning.


Sources: InfoQ on Microsoft Agent Framework harness and hosted agents reaching GA; Nerd Level Tech's analysis of managed agent runtimes across AWS, Google and Alibaba; Microsoft Foundry's Build 2026 observability post; arXiv 2605.23950 on harness disclosure in agent benchmarks.

Related: Agent harness comparison: the four dials that decide agent behavior ยท Agent control plane portability

Get the next one. I write one deep piece a week on moving enterprise agents from pilot to production. Subscribe at buildnextgen.ai.

Swipe the framework

The Four Handoffs carousel, slide 1 of 8

The Four Handoffs carousel, slide 2 of 8

The Four Handoffs carousel, slide 3 of 8

The Four Handoffs carousel, slide 4 of 8

The Four Handoffs carousel, slide 5 of 8

The Four Handoffs carousel, slide 6 of 8

The Four Handoffs carousel, slide 7 of 8

The Four Handoffs carousel, slide 8 of 8