Microsoft Foundry hosted agents hit migration deadline without automatic move

The date is the uncomfortable part. Microsoft’s migration documentation says initial-preview Hosted agent deployments are supported only until 20 August 2026. That is today. It doesn’t publish a cut-off time or timezone, so organisations with an affected production agent should assume there is no useful safety margin.

This applies specifically to Hosted agents deployed before April 2026 using the old azure-ai-agentserver-agentframework or azure-ai-agentserver-langgraph packages, or custom code built against the original preview hosting APIs. It isn’t a blanket retirement notice for every agent built in Foundry. Where it does apply, though, Microsoft is clear: redeployment is required and the platform won’t do it for the customer.

Why this is more than a hosting refresh

The new Foundry Agent Service backend moves Hosted agents to a session-based sandbox model. Compute is provisioned on demand and deprovisioned after an idle period; Microsoft documents a default of 15 minutes. Each session gets an isolated sandbox, with persistent $HOME and /files storage across turns and idle periods.

That reduces operational plumbing. It also invalidates lifecycle and state assumptions that may be baked into application code, test harnesses and runbooks. The old manual start, stop and replica-management commands are gone. The new platform exposes provisioning statuses such as creating and active, while session-based scaling replaces explicit minimum and maximum replica settings.

The interface changes at both ends. The old pattern routed calls through a shared project endpoint and supplied an agent_reference in the request body. The current model gives each agent a dedicated endpoint; the SDK binds a client to it with get_openai_client(agent_name=...). Review any API gateway policy, allow-list, integration test or client implementation built around the shared endpoint.

Start with a proper inventory, not the Foundry portal

The quickest way to miss an affected deployment is to look only at the agents somebody remembers creating. Search source repositories, container build definitions, infrastructure code and CI/CD scripts for the previous stack:

• azure-ai-agentserver-agentframework, azure-ai-agentserver-langgraph and old preview hosting imports;
• from_agent_framework(...).run() or from_langgraph(...).run() entry points;
• The protocol label v1 in application configuration or azure.yaml;
• agent_reference in Responses API calls;
• az cognitiveservices agent commands, capability-host creation, or separate agent.manifest.yaml and agent.yaml files;
• Project managed-identity role assignments granting an agent access to Storage, Search, Key Vault, tool endpoints or internal APIs.

That last item is easy to overlook. The current model creates a dedicated Microsoft Entra identity for each agent at deployment. Microsoft says the old project managed identity is no longer the runtime identity, though it remains relevant to infrastructure tasks such as container image pulls. A redeployed agent can look healthy and pass a superficial chat test, then fail when it tries to retrieve a secret, query an index or call an internal service.

Inventory calling applications as well. A Hosted agent often sits behind a web application, Teams integration, workflow engine or another agent. Its endpoint and authentication path are part of the application contract, even when a helper library hides them.

The technical changes most likely to break production behaviour

It doesn't publish a cut-off time or timezone, so organisations with an affected production agent should assume there is no useful safety margin.

Framework users may not need to rewrite their agent logic, but the hosting layer changes materially. Agent Framework deployments move to protocol-specific hosting via ResponsesHostServer. LangGraph deployments replace the old LangGraph adapter with the Responses protocol host. Custom agents choose between Responses for OpenAI-compatible conversational traffic and Invocations for arbitrary JSON payloads.

That choice is architectural, not cosmetic. With the Responses protocol, Foundry manages conversation history when a conversation ID is present. With Invocations, state management remains the application’s responsibility. Moving a webhook-style worker across without addressing that distinction can change how it maintains context.

Container protocol 2.0.0 has a sharper edge: identity propagation changes. For raw outbound HTTP calls to Foundry services, an agent must forward the inbound x-agent-foundry-call-id header unchanged. Official protocol SDK adapters do this when their clients are used; hand-written HTTP code is the team’s responsibility. The platform also supplies x-agent-user-id as the per-user partition key for data stored by the container. Test this as a security concern, not just a functional one: protocol 2.0.0 permits multiple users in one session while carrying per-request user context.

There is a documentation wrinkle, and the conservative answer is straightforward. The migration page’s prerequisites specify azure-ai-projects 2.3.0 or later, while its checklist still says 2.1.0 or later. Use the newer 2.3.0 baseline in the prerequisites, then pin and test the exact versions in the replacement image. Choosing the lower figure because it appears in a checklist is needless risk on a deadline day.

What should be tested before traffic moves

A deployment reaching active status is necessary. It is not evidence of a safe migration. The minimum credible test plan should cover the behaviour the platform has changed.

• Functional paths: normal prompts or invocation payloads, tool calls, streamed responses, error paths, file upload/download and every protocol exposed by the agent.
• Identity and authorisation: access to each downstream Azure resource under the new dedicated agent identity; delegated-user cases where they exist; and raw HTTP paths that must propagate the call ID.
• State and isolation: multi-turn conversations, session reuse, persistent files after idle deprovisioning, concurrent users, and protection against one user reading another user’s stored state.
• Operational behaviour: cold-start-sensitive journeys, expected session concurrency, logs and alerts. Log streaming has changed from chunked plain text to server-sent events with JSON payloads, which can break a home-grown log consumer.
• Failure and recovery: failed image pulls, missing RBAC, unavailable tool services, timeouts and a controlled version rollback within the new platform.

Be precise about rollback. Don’t rely on the retiring preview deployment being available when needed. Retain a previously tested version on the current backend, establish how endpoint routing will change, and understand how sessions behave when versions change. Microsoft documents that a session can be bound to a specific version at creation, so include in-flight or long-lived sessions in testing—not just a fresh first request.

Actions for the rest of this week

1. Assign an owner to every affected agent. Include dependent applications, Azure resources, identities and the business service.
2. Freeze avoidable changes to the old deployment. Preserve configuration and image provenance for diagnosis, but don’t mistake preservation for a supported rollback path.
3. Build a current-backend version. Move to the protocol libraries, update configuration to the semver protocol notation, remove retired CLI steps and provision through the current SDK or Azure Developer CLI path.
4. Grant least-privilege RBAC to the dedicated agent identity. Verify assignments with real downstream calls, not a portal inspection.
5. Run a focused production-like test. Include stateful sessions, tool calls, failure handling and performance under plausible concurrent load.
6. Cut over with observability in place. Monitor request failures, latency, failed tool calls, authorisation denials, session errors and version status. Escalate support issues with deployment details, but don’t expect an undocumented extension or automatic conversion.

Microsoft’s migration guide is comprehensive, but it also shows the scale of the change: libraries, endpoint routing, lifecycle APIs, session management, identity and tooling all move together. The sensible unit of work is a redeployment project, however small the agent may appear.

Read the secondary Microsoft Q&A thread supplied with this story cautiously. Its staff response discusses the separate classic Foundry Agent experience and says no mandatory deadline had then been published for that broader transition; its later AI-generated answer cites the Hosted-agent deadline. For this narrower issue, Microsoft’s dedicated Hosted-agent migration documentation is authoritative. Don’t conflate classic-agent migration, Assistants API retirement and this preview-hosting backend retirement: their scopes and potentially their deadlines differ.