The promise in Microsoft's latest agent announcements is a familiar one dressed in new clothes: swap the model, keep the application. Azure's framing is that the best model for your business will keep changing and adopting a new one shouldn't send your team back to redesign the architecture around it. That's a reasonable goal. It's also a goal that platforms have promised about databases, message buses and hypervisors for thirty years, with mixed results.

Portability is a property you build, not a feature you purchase

A model endpoint being pluggable at the API layer is the easy part. The hard part sits above it: the prompts tuned to one model's quirks, the tool-calling schemas that one family handles cleanly and another fumbles, the context window assumptions baked into how you chunk documents, the latency budget your UX was designed around. Change the model and all of that moves. The platform can keep the interface stable; it cannot keep your behaviour stable.

So treat "expanded model choice" as an invitation to design for substitution rather than a guarantee of it. In practice that means the model is a configuration value, prompts are versioned artefacts in source control rather than strings in a portal, and you have a regression suite that tells you whether swapping produced an improvement or a quiet degradation. If you can't answer "did that change make it better?" with evidence, model choice is just churn with a procurement story attached.

Continuous optimisation needs a definition of "better"

Optimisation loops are only as good as the signal feeding them. For a classic workload you have SLOs — latency, error rate, throughput — and everyone agrees what good looks like. For an agent, "better" is contested. Fewer tokens? Fewer escalations to a human? Higher task completion? Fewer hallucinated tool calls? Those pull in different directions, and the one you optimise for is the one you'll get.

My view is that the evaluation harness should exist before the agent ships, not after the first complaint. That means a golden set of representative tasks with expected outcomes, a scoring method you can defend to someone outside the team, and the discipline to run it on every model change. It's unglamorous work and it is the only thing that makes model agility real rather than rhetorical.

[AUTHOR: add a real example from your own work here — an evaluation or acceptance approach you've actually used.]

Voice raises the stakes on everything you got away with in text

Voice agents are the headline feature that most changes the risk profile. Text gives a user time to read, hesitate and correct. Voice is synchronous, it's latency-intolerant, and callers tend to accept what they're told because the interaction sounds like a conversation with a person. A wrong answer delivered confidently at conversational speed is harder to catch than the same wrong answer on a screen.

There's a compliance dimension too. Voice interactions are recordings. Recordings have retention rules, subject access implications and — in regulated sectors — specific handling requirements. If your organisation already has a call recording policy, the agent falls under it; if it doesn't, deploying a voice agent is the moment you discover you needed one. Check where the audio is stored, how long for, whether it's used for training, and who can retrieve it. Those answers should come from your own tenant configuration and contractual terms, not from a blog post.

  • Identity: how does the agent authenticate the caller, and what happens when it can't?
  • Authorisation: what identity does the agent act under when it calls a downstream system, and is that identity scoped to the caller's rights or to the agent's?
  • Escalation: what is the path to a human, how quickly does it trigger, and does context carry across?
  • Record-keeping: what is retained, where, and under which retention policy?

The agent identity problem has not gone away

Every one of these announcements assumes the agent can act. Acting means credentials, and credentials mean the same blast-radius questions that apply to any service principal. An agent with broad standing permissions over a line-of-business system is a privileged account that happens to speak English. The usual controls apply: least privilege, scoped permissions, credential rotation, logging of every action to somewhere the agent itself cannot edit.

The failure mode I'd watch for is permission creep by convenience. An agent is built, a tool call fails for lack of rights, someone grants a broader role to unblock the demo, and nobody revisits it. That pattern predates agents by decades — it's how service accounts end up as domain admins — and nothing about an AI runtime makes it less likely. If anything, the speed of iteration makes it more so.

What to ask before you commit

If you're being asked to greenlight agent work on this platform, the useful questions are not about the models. They're about what happens when something goes wrong at three in the morning.

Who is on call for an agent that is confidently wrong? How do you roll back — is there a pinned model version you can revert to, or does a provider-side update change your behaviour without a deployment on your side? What does the telemetry actually capture: just the inputs and outputs, or the intermediate tool calls and reasoning steps you'd need to reconstruct a decision? Can you reproduce a specific interaction from last Tuesday for a customer complaint or a regulator? Those are operational requirements, and they should appear in your design before the first prompt is written.

The sensible position

None of this is an argument against building agents. Model choice and optimisation loops are genuinely useful if your architecture can exploit them, and voice will matter in contact-centre and field scenarios where typing isn't practical. The point is that the platform removes one category of work — wiring up and hosting models — and leaves every other category untouched. Identity hygiene, data classification, evaluation discipline, change control and incident response are still yours.

Ship agents faster, by all means. Just make sure the thing you've made faster is delivery, not the rate at which an unreviewed decision reaches a customer.

Source: Ship agents faster with expanded model choice, voice agents, and continuous optimization