agent platforms have migrations too

There is a very useful moment in the life of every platform abstraction.

It is not the launch demo.

It is the migration guide.

Microsoft's refreshed public preview for hosted agents in Azure Foundry has one of those moments. The old preview hosting backend is being retired. Existing deployments on the initial backend do not move automatically. Teams that built on the earlier preview need to redeploy against the new model.

That sounds like normal preview churn, because it is. Preview platforms change. APIs move. SDKs rename things. Some early assumptions do not survive contact with actual users.

But the interesting part is not that a preview changed.

The interesting part is what changed.

The refreshed hosted-agent model has a new hosting backend, protocol libraries, identity model, management APIs, dedicated agent endpoints, and a session-based sandbox model. In other words, this is not just a wrapper around a model call getting a new package name. It is infrastructure.

Agent platforms are becoming real platforms, and real platforms have migrations.

preview is not a contract

I do not think Microsoft did anything especially surprising here.

If you deploy production-critical work on a public preview, you are accepting movement. That is the deal. Sometimes the movement is small. Sometimes the thing you built against turns into scaffolding for the thing that comes next.

The problem is that AI tooling encourages people to forget this.

The marketing surface says agent. The operational surface says runtime, identity, storage, isolation, protocols, lifecycle, files, sessions, and endpoints.

Those are very different categories of risk.

A chatbot prompt can be rewritten in an afternoon. A hosted agent wired into internal workflows, private tools, project data, authentication, audit logs, and user-facing automation becomes part of the system. When the hosting model changes, you are not only changing a library import. You are revisiting trust boundaries.

That is why migration guides are more honest than launch posts.

Launch posts tell you what the platform wants to become.

Migration guides tell you what the platform actually is.

the identity change is the tell

The most important line in this kind of migration is usually the identity line.

In the refreshed Foundry hosted-agent preview, each agent gets its own Entra identity at creation time, replacing the older shared project managed identity model. That is not a cosmetic change. It changes how access is granted, reviewed, debugged, and revoked.

This is exactly where agent platforms stop being toys.

If an agent can call tools, read files, reach services, write state, and keep a session alive across turns, then "what identity does it use?" is not an implementation detail. It is the control plane.

Shared identity is convenient early. It makes demos easier. It reduces setup friction. It lets the platform feel simple.

Dedicated identity is where the abstraction starts admitting that agents are actors.

They need least privilege. They need resource-specific access. They need ownership. They need audit trails that answer "which agent did this?" instead of "something under the project identity did this."

This is the same story we already saw with workloads, services, CI jobs, and Kubernetes controllers. At the beginning, everything runs with the big credential because getting started matters. Later, after the first few uncomfortable questions, the platform grows more precise identity boundaries.

AI agents are speedrunning that history.

protocols are product boundaries

Another useful signal is the move from framework-specific adapters toward protocol libraries.

Framework adapters are great for adoption. If you are using LangGraph, Agent Framework, Semantic Kernel, or something custom, the platform can meet you where you are. That is a good on-ramp.

But adapters are not always a durable platform boundary.

Protocols are.

Foundry's refreshed model talks about Responses, Invocations, Activity, and A2A protocols. A single agent can expose multiple protocols. Dedicated endpoints now matter more. Management APIs cover the lifecycle more completely.

This is the boring part that matters.

If agents are going to be called by portals, webhooks, schedulers, internal tools, other agents, customer workflows, and maybe boring old scripts, the stable contract cannot be "whatever this framework adapter happened to expose in April."

The stable contract has to be the protocol.

This is also where teams should slow down and think.

When you choose an agent platform, you are not only choosing a model host. You are choosing the shape of invocation. You are choosing how sessions are represented. You are choosing how files move in and out. You are choosing how cancellation works. You are choosing where tool access lives. You are choosing whether your workflow is portable enough to survive the next platform refresh.

The model is the least sticky part.

The runtime contract is the sticky part.

sessions are state, and state is where platforms get serious

The refreshed preview also introduces a session-based sandbox model, with a persistent home directory and file storage across turns and idle periods.

That sounds convenient. It is convenient.

It is also state.

State is where simple agent demos become production systems.

A stateless model call is easy to reason about. Input goes in. Output comes out. You log the request, maybe store the response, and move on.

A session-based agent is different. It can accumulate files. It can remember working context. It can do multi-turn work in an environment that has continuity. The platform can provision compute on demand and deprovision it after inactivity, but the session can still matter.

That creates better user experiences. It also creates better failure modes.

What happens when a session gets too large? What is retained? Who can inspect it? How does a user delete it? Does a later turn depend on a file written by an earlier one? Can the same agent handle concurrent work safely? Can a sensitive artifact survive longer than intended because it lives in the wrong sandbox path?

None of these questions are exotic. They are the normal questions we ask about stateful systems.

The point is that agent platforms do not exempt us from those questions. They just package them in a newer interface.

the migration is the architecture review

If your team built on the old hosted-agent preview, the practical work is obvious enough: update packages, change entry points, move to the new protocol libraries, update SDK and CLI calls, grant access to the dedicated agent identity, redeploy, verify the version is active, and test real workflows.

But I would not treat that as a checklist only.

I would treat it as an architecture review.

Ask what the old design assumed:

Did the agent rely on broad project-level identity?
Did any workflow assume a shared project endpoint?
Were tools configured as deployment-time metadata when they now belong behind runtime MCP access?
Did user sessions have implicit state that nobody documented?
Are logs and audits good enough to explain agent behavior after the migration?
Can the agent be redeployed without losing important operational context?

This is the useful pain of platform churn. It exposes which parts of your system were accidental.

Some teams will discover they only had a demo. Fine. Migrate it quickly and move on.

Other teams will discover they already have production dependency on an agent runtime they did not really model as production infrastructure. That is the more interesting case.

build agents like the platform will change

The lesson is not "avoid previews forever."

That would be too easy, and also unrealistic. The agent space is moving quickly. If you wait for every surface to become boring, you will learn late.

The lesson is to keep your own contracts small.

Put your domain logic somewhere you control. Keep tool definitions explicit. Treat platform sessions as useful runtime state, not as your only system of record. Do not let authorization live only in the agent instructions. Keep invocation boundaries narrow enough that another host could call the same workflow later. Write down which resources the agent identity needs and why.

Most importantly, separate the agent's job from the platform's job.

The agent's job is to reason, call tools, and produce useful work.

The platform's job is to provide identity, isolation, lifecycle, protocols, files, observability, and policy.

When those boundaries blur, every platform change becomes a product rewrite.

When they are clear, a migration is still annoying, but it is survivable.

this is what maturity looks like

I expect more of this, not less.

Agent platforms will keep changing because the industry is still discovering the right runtime shape. We will see more dedicated identities, more protocol work, more sandbox models, more managed tool registries, more audit surfaces, more session APIs, and more lifecycle controls.

That is not a failure of the agent idea.

That is the agent idea becoming infrastructure.

Infrastructure has versions. Infrastructure has deprecations. Infrastructure has migration guides that ruin your morning and improve your architecture if you read them carefully.

The teams that treat agents as magic assistants will experience this as chaos.

The teams that treat agents as workloads will recognize the pattern.

Your agent platform is not only a place where prompts run. It is a runtime with identity, state, isolation, protocols, and operational contracts.

And runtimes have migrations.