A model dropdown does not prove you can leave the platform
Microsoft’s model-diverse pitch makes a good architectural point. Test portability at the workflow boundary, including context, policy and the release evidence.
My test for model independence now includes a second move: change the system around the model. The first move proves that a dropdown works. The second reveals which parts of the application the platform owns.
In a June statement on enterprise AI, Microsoft’s Judson Althoff argues for model diversity and against dependence on a single model or harness. The same statement positions Microsoft IQ and Agent 365 as important parts of the surrounding system. That combination is commercially coherent. A platform can promote choice among models while competing to become the place where customers manage them.
The advice can be correct and the sales pitch can still deserve examination. I do not read that statement as evidence of concealed lock-in. I read it as a reason to define which layer we mean when we say portable.
Name the thing that has to move
For a simple text transformation, moving may require little more than changing a request format and checking the result. A workflow with retrieved context, tool permissions, stored state and release tests presents a larger migration problem. Supporting several model providers does not automatically make those surrounding assets transferable.
I would ask a platform evaluation to name one complete task the team intends to retain through a migration. “Summarise this support case using the permitted records and propose a reply” is more useful than “support multiple models.” It gives the exercise a boundary and a result to assess.
Then separate what travels unchanged from what must be translated or rebuilt. A prompt file may export cleanly while its retrieval rules depend on platform services. A trace may be downloadable while the evaluation that interprets it is harder to reproduce. These are possibilities to investigate, not findings about Microsoft’s implementation.
Price one small exit rehearsal
Consider a hypothetical team evaluating two agent platforms. I would have it reproduce one accepted workflow on the second platform using an approved sample dataset. Keep the user task, permissions and acceptance criteria fixed. Let the implementation differ where it needs to.
Record the work required to move context, reconnect tools, reconstruct policy and rerun the tests. If a feature cannot be reproduced, describe the resulting loss in user terms. “The export lacks this field” matters less than “we can no longer explain which record supported the answer.”
The result is an estimated switching cost grounded in an actual small move. It will not predict the cost of moving an entire organisation, but it is more informative than counting supported providers. I would repeat the exercise only when a material dependency changes, rather than turn portability into a permanent parallel implementation project.
There is a reasonable counterargument: integration is part of what a platform sells. Rebuilding identity, monitoring and governance merely to avoid dependency can waste substantial effort. A product that solves those problems well may deserve the commitment. The exercise should make that trade visible, not assume every dependency is a mistake.
Nor does an open component automatically make the whole workflow easy to move. Conversely, a managed platform can offer usable exports and well-defined interfaces. The relevant evidence is what the customer can carry across and keep operating.
The earlier harness argument concerned how an agent becomes testable and releasable. This adds a procurement question: how much of that release capability survives a move?
Buy model choice for the flexibility it delivers, and measure platform portability with one complete workflow you can actually move.
