Microsoft spent Build 2026 telling anyone who would listen that the enterprise AI fight is about reliability, not capability. In early July, Hosted Agents in Foundry Agent Service went generally available, and it's the clearest expression of that bet: a managed runtime that will take an agent you already built — in the Microsoft Agent Framework, the GitHub Copilot SDK, LangGraph, or something else entirely — and run it in production without a rewrite.
The infrastructure is genuinely good, and worth saying plainly before the criticism. Every session runs in its own VM-isolated sandbox with dedicated compute, memory, and a persistent filesystem at $HOME and /files. Sessions live up to 30 days; after 15 minutes idle the platform deprovisions compute and saves state, resuming when the session is referenced again. You pay $0.0994 per vCPU-hour and $0.0118 per GiB-hour while an agent is actually executing, and nothing while it sleeps. That is scale-to-zero for stateful agents — the thing that, until now, you either paid for around the clock or hand-rolled with a queue and a checkpointer. Pair it with routines (public preview), which fire an agent on a timer or a recurring schedule, and Foundry has quietly shipped cron for durable agents.
So the runtime clears the bar. The interesting decision is one layer up, and Microsoft doesn't frame it as a decision at all.
Two doors into the same building#
A hosted agent is reached over one of two protocols, and you choose when you deploy.
The Responses API is the OpenAI-compatible path. Here the conversation ID is the primary concept: the platform manages conversation history, associates a session with each conversation, and owns the streaming HTTP contract end to end. You bring a model and some tools; Foundry handles the plumbing. It's the low-glue option, and it's what the tutorials show you.
The Invocations protocol is the other door, and it's built for developers who don't want the plumbing. Your container exposes a single /invocations endpoint, you define the request and response schema, and the platform is pure pass-through — bytes in, bytes out, forwarded to your process as-is and returned raw. The session ID is primary and you manage state yourself. You get raw SSE control and total payload freedom. This is the path that makes "framework-agnostic" literally true: whatever loop LangGraph or your own harness runs, you can wrap it behind /invocations and never bend it to anyone's schema.
Reading the docs, it looks like an ergonomic preference — managed convenience versus raw control. It isn't.
The feature you lose is the one you came for#
Here is the line that reframes the whole thing: Teams and Microsoft 365 publishing, and A2A delegation, are available only through the Responses API. Pick the Invocations protocol to preserve your framework's native shape, and you have simultaneously opted out of Microsoft's distribution and interop surface.
Foundry will run anyone's agent. It only distributes the ones that speak its shape.
That's the trade nobody puts on the slide. "Framework-agnostic" is true at the compute layer — Foundry really will host your LangGraph agent unmodified — and quietly false at the distribution layer. The reach that makes Foundry worth choosing over a bare container on any cloud is the reach into Teams, into M365, into agent-to-agent delegation. And that reach is gated behind conforming your agent's I/O to the Responses contract. The pass-through door lets your framework in and locks you out of the rooms you came to stand in.
So the protocol picker is doing more work than it admits. It's not "managed vs. raw." It's a bet: do you want Microsoft's distribution, or your own control? The Responses API buys reach at the cost of reshaping your agent into Anthropic-adjacent, OpenAI-compatible request/response. Invocations keeps your agent exactly as you built it and hands you a very good, very isolated, very billable sandbox — and nothing above it.
What this means if you're choosing#
For a genuinely portable agent — one you might move to Bedrock AgentCore or Vertex Agent Engine next quarter — Invocations is the honest choice, because you're already declining platform lock-in and you'd rather own your schema. Just don't expect the Teams tile. For an agent whose entire value is that it shows up where your colleagues already work, the Responses API isn't optional, and "no rewrite" becomes "no rewrite unless you want anyone to use it."
The reliability story Microsoft is selling is real, and the sandbox economics are the best I've seen for stateful agents. But agnosticism at the compute layer is the cheap kind to give away. The expensive, opinionated layer — who gets distributed, who gets to delegate — is exactly where Foundry keeps its thumb on the scale. Read the protocol table as a pricing table for your independence, and choose with your eyes open.
