Schlagwort: cloud computing

GPT-6 Astra, Sol, and Luna: For production agents in Microsoft Foundry

Today, we are expanding our GPT-6 series by welcoming GPT-6 Sol and GPT-6 Luna to our generally available lineup in Microsoft Foundry. Building on the exceptional customer momentum of GPT-5.6 Sol and GPT-6 Astra, this launch continues our work to deliver transformative capabilities in Microsoft Foundry that produce less noise and are more capable at completing full tasks with agents.

Explore GPT models in Foundry today

Astra brings advanced reasoning, software engineering and computer use to demanding work that requires both judgment and action. Azure customers report a step-change in capabilities, and strong cost-to-performance with the model using fewer, higher-value tokens to drive agents.

Completing the lineup, GPT-6 Sol is excellent for general-purpose use, while Luna brings efficient intelligence to high-volume data and preparatory work.

Put the right intelligence behind every agent

The right model for a job should be determined through evaluations: an agent handling a complex business decision and one routing routine requests have different needs. Microsoft recommends customers start with GPT-6 Astra for demanding work. For higher-volume workloads, GPT-6 Sol and Luna carry that progress forward, giving you a complementary choice built for production and scale.

GPT-6 Sol for production AI agents and complex workflows

GPT-6 Sol, and its proven predecessor—GPT-5.6 Sol—offer slightly more cost-effective intelligence with frontier efficiency. They support enterprise agents, coding and complex knowledge work, including reasoning across multiple steps, long-context analysis, and workflows that use tools. For teams evaluating their next production workload or migrating off a legacy model, Sol is a strong starting point.

GPT-6 Luna for efficient, high-volume AI workloads

GPT-6 Luna is Sol’s smaller, faster sibling, built for high-volume work. Use it for extraction, summarization, request routing, and routine customer interactions. Reserve deeper reasoning for the steps that need it, rather than applying the same model to every task.

As the GPT-6 lineup expands, the opportunity is not simply to choose a newer model, but to improve what your agents can accomplish while saving money. Customers should look beyond pricing per token and seek to understand cost per task, which is a better measure for understanding the ROI of AI.

The accompanying chart illustrates why enterprise customers on Microsoft Foundry are switching to GPT-5.6 Sol and the latest GPT-6 offerings.

Foundry brings evaluation and monitoring together so teams can make those decisions with evidence. The real measure of that progress is what customers can do in production, which is why Foundry has always encouraged model choice and an open, interoperable stack.

The Foundry advantage, in customers’ words

Access to frontier models is only the starting point. Foundry pairs GPT-6 intelligence with the breadth of deployment options enterprise production demands. Today, Standard deployment is available for Astra, Sol and Luna across all 28 Global regions, and US and EU Data Zones; Provisioned Throughput for Astra and Sol across Global regions and US and EU Data Zones; and Priority Processing for Sol across Global regions and US Data Zones. The breadth and performance of Azure is why OpenAI continues to launch first on Azure, and why sophisticated customers like Manus choose Foundry.

Azure OpenAI models provide a core layer of intelligence powering Manus. Through Azure, we reliably integrate advanced models into our agentic workflows, enabling Manus to understand user intent, plan tasks, and execute complex work. Responsive Microsoft technical support and rapid access to new model capabilities help us iterate quickly and deliver a leading, reliable AI experience for our users.
—Tao Zhang, Co-Founder & Product Partner, Manus

For customers getting started with AI on Azure: choose Global for flexible, pay-per-token capacity, or supported Data Zone deployments for processing-location requirements. Priority Processing is a priority lane for responsive, pay-as-you-go experiences, with Provisioned Throughput providing reserved capacity and superior latency for critical production demand. Match the serving option to the workload, from interactive agents to high-throughput business processes.

That is the Foundry advantage: not just frontier intelligence, but the platform to put it to work. Teams can match each workload to the right model, deployment option, and controls, balancing capability, responsiveness, and cost as adoption grows. By bringing these choices together on Azure, Foundry helps customers focus on delivering business value, with the operational foundation to move from a promising agent to production at scale.

Our customers work in domains where getting an answer isn’t enough, it has to be the right answer, and it has to hold up to scrutiny. The latest Azure OpenAI frontier models reason through a problem in steps we can follow, which is what makes it viable for the research and compliance workflows our professionals depend on. Building on Microsoft Foundry lets us take those agentic workflows into production on infrastructure and services that already meet our governance, data residency, and security obligations.
—Brian Diffin, CTO of Wolters Kluwer Tax & Accounting

GPT-6 pricing and deployment options**

ModelDeploymentContext LengthPricing (USD $/million tokens)InputCached InputCached WritesOutputGPT-6 AstraGlobal StandardShort context$10.00$1.00$12.50$50.00Long context$20.00$2.00$25.00$75.00Data Zone Standard (US)Short context$11.00$1.10$13.75$55.00Long context$22.00$2.20$27.50$82.50Data Zone Standard (EU)Short context$12.00$1.20$15.00$60.00Long context$24.00$2.40$30.00$90.00GPT-6 SolGlobal StandardShort context$2.00$0.20$2.50$10.00Long context$4.00$0.40$5.00$15.00Data Zone Standard (US)Short context$2.20$0.22$2.75$11.00Long context$4.40$0.44$5.50$16.50Data Zone Standard (EU)Short context$2.40$0.24$3.00$12.00Long context$4.80$0.48$6.00$18.00GPT-6 LunaGlobal StandardShort context$0.10$0.01$0.125$0.50Long context$0.20$0.02$0.25$0.75Data Zone Standard (US)Short context$0.11$0.011$0.1375$0.55Long context$0.22$0.022$0.275$0.825Data Zone Standard (EU)Short context$0.12$0.012$0.15$0.60Long context$0.24$0.024$0.30$0.90

**Pricing for both Provisioned Throughput and Priority Processing varies by deployment type. For each offer, U.S. Data Zone is priced at a 10% premium to Global. For current rates and terms, see the Azure OpenAI pricing page.

Build safer AI agents with Microsoft Foundry

GPT-6 models running on Azure have multiple layers of safety and security built directly into the model and around it. At the core, the model itself carries the alignment and safety training built in, while the prompts and outputs around it are protected by content filters and guardrails that govern what the agent can say. Beyond that, tool calls and responses are protected by controls and prompt injection mitigation that govern what the agent can do, and identity and access are protected by enterprise policies that govern what it can reach.

Foundry helps teams continuously strengthen safety layers as risks evolve. It applies guardrails at key checkpoints, including prompts, outputs, tool calls, and tool responses. Identity and access controls govern what agents can do and reach. Microsoft Purview applies enterprise data policies. Evaluation, tracing, and monitoring give teams the evidence to optimize those controls over time, with human checkpoints at every phase.

Move to GPT-6. Build your next generation of agents.

Build your next agentic workloads in Microsoft Foundry. Start with GPT-6 Astra for demanding reasoning, Sol for general production use, and scale high-volume tasks with GPT-6 Luna. For customers of legacy models, we recommend evaluating an upgrade to GPT-5.6 Sol and above.

Your next agent needs more than a powerful model. Foundry brings an open intelligence stack, deployment flexibility, and Azure enterprise controls together so you can build with confidence and scale from your first workload to production.

Start building in Foundry today

Access GPT-6 models, evaluate the right fit for your workload, and scale from experimentation to production.

Begin here

The post GPT-6 Astra, Sol, and Luna: For production agents in Microsoft Foundry appeared first on Microsoft Azure Blog.
Quelle: Azure

Designing agent-first platforms: What changes when agents do the work

For decades, applications have been designed to wait. A user clicks, a request arrives, code runs, a response goes back. And we got very good at this. We learned to forecast traffic, scale on demand, wrap everything in enterprise controls, and run it all with the operational discipline that keeps critical business systems available around the clock.

That model is being turned on its head, and being asked to serve apps that continuously act, and wait for no one.

What changed is not the infrastructure underneath, but the software being written on top of it. The work we used to capture as deterministic code, where every branch was defined in advance and every step was known before the first line ran, is now being rewritten as multi-agent applications that work out the steps at runtime. A developer used to encode the path, and now a developer describes the outcome and lets a set of agents reason their way toward it.

Agents work differently. Given an outcome, an agent reasons through the problem, breaks it into steps, writes code to solve it, runs that code, looks at the result, and goes again. The work happens in a loop that no human is standing inside. That change puts pressure on assumptions our platforms were built on, because an application that responds and an agent that acts need very different things underneath them.

The organizations pulling ahead right now are the ones who understood this early. They are not simply adding AI to what they already have. They are designing for a different kind of software.

What it takes to run an agent you can depend on

Getting an agent working is no longer the hard part. A team can connect a capable model to a few tools, ground it in company data, and have something genuinely useful inside a week. That is real progress, and it is why so many organizations now have a pilot that impressed the room.

The distance between that pilot and an agent the business depends on around the clock is where the real challenge is.

An agent operating continuously on behalf of a company gets held to the same bar as everything else in production. It needs its own identity, with permissions scoped to what it is allowed to see. It needs to be watched while it works, so a team can trace every step it took, evaluate whether the outcome was right, and catch the drift that shows up quietly weeks after launch. It needs guardrails that are enforced at runtime. And it has to clear the same security and compliance standards as the rest of the estate. No one is going to grant an agent an exemption.

None of that is work a team should be doing for itself. That is the job of an agent platform. Microsoft Foundry is where agents are built, grounded in enterprise knowledge, given a first-class identity through Entra Agent ID, and traced and evaluated once they are live. The Foundry Control Plane governs the agent, but it does not dictate where the agent’s work actually runs. That is a separate decision, and a separate layer.

Get started with Microsoft Foundry

Where the work actually runs

The moment an agent stops answering questions and starts completing tasks, it has to execute code. It clones a repository. It installs a package. It runs an analysis against live data and calls into a system of record. That execution needs a runtime environment. In most cases, it simply inherits the one the host application is already running on, because that is the path of least resistance.

Run the agent on shared infrastructure and every workload inherits the blast radius of every other one. Give it broad access so it can be useful and you have handed an autonomous process far more reach than you intended. Lock it down until it is safe and the agent can no longer do the job you built it for. Teams get stuck in this trade-off, and it is where most promising agents usually stall before they reach production.

The answer is not to limit what the agent can do. It is to give it a dedicated environment, with its own identity and guardrails for execution.

Azure Container Apps Sandboxes provides exactly that. Every agent execution gets a fully isolated environment of its own, created in seconds and gone when the work is finished. It runs as an identity you control, can access only the systems you have allowed it to reach, and never stores the credentials it uses to get there. And when a task spans hours or days, the environment can be paused and resumed with its full working context intact, so the agent picks up precisely where it left off.

There is real engineering behind this. Each environment runs inside its own hardware-isolated microVM, which is what makes strong separation and sub-second startup possible at the same time. But the mechanism is not the point. Isolation is built into the runtime rather than wrapped around it, so teams stop choosing between a capable agent and a controlled one.

Nothing disappears into the sandbox. The agent is still governed by Foundry, so what it sent into the sandbox and what came back stay on the record with every other step it took.

The architecture pattern emerging across the enterprise

Put the two together and a clear design pattern appears, one we are now seeing repeatedly across industries.

Build and govern the agent on Foundry. Extend its execution into an isolated sandbox on Azure Container Apps. The agent keeps its identity, its permissions, and its oversight. The agent does not change when its work moves. Only the ground it runs on does. The work it performs happens in an environment that is purpose-built for agent tasks with ultra-fast executions, scoped to what it needs, and dissolved afterward.

This is what allows an organization to move from a handful of supervised agents to thousands running concurrently, without asking security and platform teams to accept risk they should never be asked to accept.

What this looks like in practice

Regulated client work, delivered at scale. Digital Gateway Powered by Claude brings Claude’s capabilities into KPMG’s connected tax platform on Microsoft Azure, giving professionals a secure, trusted environment to work alongside AI. Within the platform, DG Cowork serves as the AI-powered workspace where professionals can analyze information, generate content, and advance complex work. Because client data must remain separated by engagement, the platform was built with engagement-specific workspaces and controls at its foundation. DG Cowork is designed for a global scale, with more than 30,000 Azure Container Apps Sandboxes running concurrently.

Delivering answers to the questions nobody had time to ask. Cognite serves industrial operators who face a common challenge: their most valuable questions—like which assets are underperforming and why— are often too time-consuming to answer. Because traditional analysis took days, these investigations were rarely commissioned, leaving teams to rely on experience alone. Cognite Atlas AI changes that. Each agent gets its own governed workspace grounded in live customer data in Cognite Data Fusion, turning days-long investigations into traceable answers delivered in minutes. And for more complex problems, agents can pause and resume investigations without losing context, allowing them to work through a problem over time much like an engineer would.

Atlas AI agents are powered by Azure OpenAI models in Microsoft Foundry, but to handle complex work in Cognite Data Fusion they needed to execute arbitrary code and work with files directly – which meant sandboxes that truly isolate each user’s agent, environment, and data. With Azure Container Apps Sandboxes we had a prototype running in hours and were testing with customers within weeks, because Azure handles the hard part: per-user isolation, egress policies, sub-second execution. For our industrial customers, that’s the difference between a days-long manual investigation into “which wells are underperforming and why?” and a cited draft in minutes.
—Christian Flasshoff, Architect, Atlas AI, Cognite

A safe place for every learner. The Department for Education in South Australia runs EdChat so students can learn by writing code and exploring data alongside AI, across 60,000 students and more than 40,000 staff. That model only works if every student gets an environment of their own, with clear guardrails, and can come back later to find their work exactly as they left it. Building that in house meant owning the machinery behind it. The department estimates that moving to Azure Container Apps Sandboxes lets them retire close to 50,000 lines of code written to manage custom code interpreter state themselves. It is a per-user execution model at the scale of a school system, and a maintenance burden the department no longer has to carry.

Three very different organizations. One common story. None of them were held back by what the models could do. They were held back by not having anywhere to run the work at their scale, against their real data, with economics that made sense.

Learn more about Azure Container Apps Sandboxes

We built this because we needed it

More than a million sandboxes per day run in production across Microsoft, powering GitHub Copilot, Copilot Studio, Security Copilot, Foundry Agent Service, Azure SRE Agent, and other Azure services.

Every one of those sandboxes has someone on the other end of it. A developer expecting a pull request to come back finished. An analyst chasing an alert before the shift ends. A support team working down a queue that has to be empty by morning. Their day moves at the speed this layer runs, and it either holds or it doesn’t. That is a sterner test than anything we could design internally, and it is the one this infrastructure has been passing at scale for a long while now.

One architecture sits beneath both our developer tools and our AI platform. That is the same architecture we are making generally available to you.

The decision in front of you

Every major platform shift eventually comes down to a design choice made early, by people who could see where things were heading.

The teams who will scale agents successfully over the next few years are making that choice now. They are separating the platform that governs the agent from the environment that runs its work, and they are treating that separation as a foundational decision rather than something to retrofit once a pilot succeeds.

The agents are ready. The question worth asking is whether your platform is designed for software that acts.

Azure Container Apps Sandboxes

Learn more about designing agent-first platforms with Azure.

Get started

The post Designing agent-first platforms: What changes when agents do the work appeared first on Microsoft Azure Blog.
Quelle: Azure

Your architecture diagram is not your resilience

This first article in our resilience series draws on a conversation with Mark Russinovich about how resilience is changing in the AI era and what it takes to continuously validate it at scale.

What surprises me most about resilience failures is how ordinary the drift is. A workload is deployed across availability zones, but a health probe still points to a single dependency. A database supports failover, but the application’s connection string is pinned to one region. Nothing looks broken. The architecture diagram still shows a resilient design even as the operational reality underneath it changes.

For years, resilience was something you set up once: configure disaster recovery, write a runbook, run the occasional failover test. That kept the lights on, but it treated resilience as a project with an end date rather than a property you maintain.

So, when an availability zone or a region has a bad day, the question is not whether a recovery plan exists on paper. It is whether resilience is still true today, and whether the team can prove it.

The dependency that breaks a workload is also changing. On Microsoft’s FY26 Q4 earnings call, Satya Nadella put it plainly: “For whatever reason, if a given model goes away, then you can’t be left high and dry. You need to be able to still continue your cyber operations.”

Traditional disaster recovery planning assumes the critical dependency is infrastructure. Increasingly it is an AI model, an inference endpoint, a retrieval pipeline, or a service operating under capacity constraints. A workload can be perfectly healthy from an infrastructure perspective and still fail its users because that dependency is unavailable, throttled, or economically impractical to run. That dependency rarely appears on the diagram at all.

There is a second shift underneath the first. An architecture diagram assumes a human drew it and a human will read it. Both of those assumptions are ending, and the dependencies it describes are no longer all deterministic. That changes what it means to know your estate is resilient.

This is the first in a series on how we are helping customers move to resilience that is designed in, measured as the estate changes, and improved over time. We have written before about how to design a resilient workload. This is a different problem: knowing whether hundreds of workloads still match their design today and being able to prove it. It is where a large share of our roadmap investment is now going.

Why resilience drifts

Resilience has always been a shared responsibility. We provide the availability zones, a secondary region of choice, and the replication primitives needed to support resiliency, and those do not drift. What drifts is the other half of the bargain: whether a given workload still uses them the way it was designed to, after a year of changes nobody flagged as risky. Change is where this concentrates. Across the industry, roughly 70 percent of cloud outages are related to change in some way—not dramatic failures, but ordinary modifications whose blast radius nobody re-evaluated.

That is why change discipline matters as much as design. Internally, a change rolls out to a canary region first, then a pilot region, with bake times where health signals are watched before it goes any further. That practice came out of an incident of our own, and it is the same discipline the Well-Architected Framework describes as safe deployment practices.

Learn more about the Azure Well-Architected Framework

Disaster recovery is reactive by design. Teams set recovery objectives when a project ships, stand up replication, and then move on, with little ongoing visibility into whether those objectives still hold as the workload changes. Resilience is designed once and rarely revisited. Across a growing estate of availability zones and regions, the distance between the resilience that was designed and the resilience that actually exists widens quietly, and it usually surfaces only during an incident.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/1117657-resilience-drift_tbmnl_en-us?wid=1280″,”title”:”Resilience drift”,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-resilience-drift-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-resilience-drift-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-resilience-drift-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-resilience-drift-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F1117657-resilience-drift%2F1117657-resilience-drift_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-resilience-drift_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6ab4e1548fa53″, options);
});

We learned this the hard way. Mark tells the story of the storage change that came close to taking Azure down, and what it permanently changed about how we deploy.

What a diagram can’t tell you

A diagram is a claim about a system, made once, by someone reasoning about the system as they believed it to be. It is useful, and it is not evidence. There are four things it structurally cannot tell you.

Whether the goal is being met right now. A diagram has no timestamp. Health modeling does: described in the Well-Architected Framework and now available through health models in Azure Monitor, it represents an application as a hierarchy of its components and the signals underneath them, so health is expressed in terms the business recognizes rather than as a wall of resource-level metrics. Paired with service level indicators, it answers the only question that matters during an incident: is this application meeting its objective right now? The standard that matters is not our own. A service is only healthy if the customer thinks it is healthy—we can believe it is fine, but if the customer is not seeing a healthy service, we have a problem.

What “resilient” even means for this application. On a diagram, resilient is an adjective. A resiliency goal makes it a threshold you either meet or miss and defining it at the level of the application rather than resource by resource is what makes the answer meaningful.

Whether the failover path actually works. Every diagram draws the arrow. Only a test proves it.

The resources nobody drew. A diagram shows what someone remembered. Generated Infrastructure-as-Code covers every resource in the application. The difference between those two sets is where drift begins—and increasingly the reader on the other end is an agent rather than a person, working from the outcome you asked for instead of the picture you drew.

This is how we run Azure. Rather than asking each team to declare what healthy means for their service, we standardized on service level indicators, then applied machine learning to observed behavior so that healthy is defined by what the service actually does rather than by what someone assumed it would do.

This is the part I find most interesting. We wrote our documentation, our schemas, and our templates for people. Increasingly the thing reading them is an agent, working from the outcome you asked for rather than the picture you drew, and generating the resources itself. When the author and the reader are both machines, a diagram is no longer even the medium the decision is made in.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/1117657-proving-resilience_tbmnl_en-us?wid=1280″,”title”:”Proving resilience”,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F1117657-proving-resilience%2F1117657-proving-resilience_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”},{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-proving-resilience_audio_en-us”,”locale”:”en-us”,”mediaType”:”audio”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6ab4e1548ff32″, options);
});

Mark on why we break our own services on purpose, what a game day actually tests, and why every failure mode we simulate is one that has really happened.

When the dependency is probabilistic

A model that disappears is the obvious risk. The subtler one is a model that answers, differently each time. It is a newer source of drift, and it does not behave like the old ones. Ask the same question of a model twice and you can get two different answers. That makes correctness harder to define, and it makes change harder to reason about: if you change the prompt, change the model, or change the harness and the skills around it, you have changed the software, and it deserves the same discipline as any other change.

Most teams smoke-test instead. It looks fine, so it ships. Evaluation is the step that gets skipped, and it is the one that matters: measuring the system against what you actually consider valuable, not simply whether it responded.

The first question is whether the system needs to be probabilistic at all. Stay as deterministic as you can and use AI where it earns its place, not everywhere. And where you can wrap a non-deterministic system in a deterministic check, do it. If an agent is only supposed to update dependency versions, have a second system verify that versions are the only thing that changed. Where a deterministic check is not possible, use adversarial review: a second agent whose whole job is to find what is wrong with the first one’s work.

And accountability does not transfer. When someone deploys an agent, someone remains answerable for what it does.

That applies to us as well. Our own incident triage system uses language models to answer which service is responsible for an incident—work that used to mean waking people up to argue over logs. It is genuinely faster, and it is still trust but verify.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/1117657-ai-uncertainty_tbmnl_en-us?wid=1280″,”title”:”AI uncertainty”,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F1117657-ai-uncertainty%2F1117657-ai-uncertainty_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”},{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-ai-uncertainty_audio_en-us”,”locale”:”en-us”,”mediaType”:”audio”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6ab4e154902b2″, options);
});

Mark on why guardrails around AI should be deterministic wherever possible, and why the agent is never the one accountable.

What this looks like in practice

That discipline has to hold wherever a workload runs, and the foundations are familiar. The reliability guidance in the Well-Architected Framework already says to design resilience in from the start, and the Cloud Adoption Framework describes the operating half: carrying that intent into how the estate is actually run and reviewed month after month. Where an estate spans global, national, and sovereign or regulated environments, the word resilient has to mean the same thing in each rather than being redefined at every boundary; our guidance on reliability and sovereignty covers where those constraints intersect.

Your diagram shows three zones. It does not show that the health probe behind the load balancer resolves to one of them. Availability zones protect a workload from datacenter-level failures within a region, but only if compute, storage, and data tiers are genuinely spread across them.

Plan region resiliency for disaster recovery. Set explicit recovery objectives, an RTO and RPO, for each workload. Availability zones give you high availability inside a region, while a secondary region of choice provides a failover location when an entire region is affected. They answer different risks, and a resilient design is deliberate about both. In a regulated estate the choice narrows further, because a recovery region has to sit inside the same jurisdiction as the workload it protects.

Decide how much resilience is worth buying. Resilience is a cost decision as much as a design one. An application carrying 100 million dollars of revenue on a single day justifies an active-active topology across regions for that day; the same application may run in a single region with active-passive failover for the rest of the year. The right answer is deliberate, not maximal.

Know your blast radius. Understand what each workload depends on and where its hidden single points of failure are, then keep that picture current as the application changes. Internally we do this as reliability threat modeling: the same discipline as security threat modeling, asking of each component what would happen if it failed, and what we would do about it.

Check the dependencies your recovery path itself relies on. A workload can be replicated correctly and still be unrecoverable: if its encryption keys live only in the primary region, they are gone precisely when a region outage means you need them. Recovery paths have dependencies too, and they are rarely on the diagram.

Your diagram probably has no box for the AI dependency your application now relies on. Design for your application, workload, AI model, and service dependencies, not just infrastructure. Plan for graceful degradation and fallback so that if a critical dependency is deprecated, throttled, unavailable, or capacity-constrained, the workload continues to operate through an alternative path rather than failing outright.

This is not theoretical. Carne Group, one of Europe’s largest independent third-party asset managers with one trillion dollars under management, rebuilt its estate on Azure with infrastructure-as-code landing zones precisely so resilience would be reproducible rather than remembered. Because the definition lives in code, their team can stand up a duplicate site in another region and, as Carne Group’s global technology lead Stéphane Bebrone puts it, “even in the event of a worst-case scenario, we could be back up and running more or less in the same day.” They are working toward an active-passive topology across regions and plan to use Chaos Studio to verify those failover paths on a schedule rather than on an incident. Under DORA, they have to be able to prove it, not assert it.

Learn more about how Carne Group used Azure Site Recovery and Backup

Closing the gap between intent and reality

An architecture diagram is a statement of intent, not proof. It may show zone redundancy, regional failover, and protected dependencies, but only a test can determine whether those assumptions still hold. Assembling the underlying data into a clear view of application resiliency takes real effort and expertise. That is the customer’s half of the shared responsibility, and it is the gap Azure Infrastructure Resiliency Manager is built to help close. In public preview, its agentic-first experience helps teams start resilient, get resilient, and stay resilient.

Start resilient. Define what resilient means for an application, set explicit resiliency goals, and use the Resiliency Agent to generate resiliency-aware Infrastructure-as-Code up front, so a new workload starts resilient instead of being corrected months later. Service Groups help teams represent an application as a logical group of Azure resources in the portal, making it easier to manage resiliency posture at the application level rather than resource by resource.

Get resilient. See where the estate stands against the intended design, identify resources that were never zone resilient or stopped being so after a change, and prioritize the gaps that matter first. Rather than correlating findings across several tools, teams get recommendations and generated Infrastructure-as-Code for supported fixes, so remediation can move through a pull request instead of becoming a separate project.

Stay resilient. Validate the assumptions behind the recovery path before a real outage does it for you. For workloads where the customer manages the compute, such as virtual machines, a zone-down drill can simulate the loss of an availability zone and show what actually happens to the application. For other services, teams can use failover validation, product-specific recovery capabilities, and fault injection through Azure Chaos Studio to test the right failure modes.

We will be candid about the gaps too. Consistent, self-service resiliency assessment across every workload and environment is not finished work, and saying so matters. Resiliency improves when teams can see the gaps, measure them, and systematically close them over time. It is also work that never quite ends. As services harden the failure rate drops, but the failures that remain get rarer and stranger; you approach perfection asymptotically without ever arriving.

The bottom line: a diagram is not proof

Resilience is not a project you finish; it is a posture you maintain. The work is to design it in from the first architecture decision, then keep proving it as the estate changes, so drift is caught by a test rather than by an incident. All of it is anchored in the Azure Essentials frameworks, the Well-Architected Framework, and the Cloud Adoption Framework, so that resilient and sovereign carry the same meaning across every environment instead of being reinvented team by team.

None of this is a new framework. A diagram tells you what you intended; only a test tells you what you have. That was true when people drew the diagrams and read them. It matters more now that neither is reliably the case, and that some of what you depend on answers differently every time you ask. If resilience cannot be tested, it cannot be trusted.

In the next part of this series, we will look at how to measure that posture at scale.

const currentTheme =
localStorage.getItem(‘blogInABoxCurrentTheme’) ||
(window.matchMedia(‘(prefers-color-scheme: dark)’).matches ? ‘dark’ : ‘light’);

// Modify player theme based on localStorage value.
let options = {“autoplay”:false,”hideControls”:null,”language”:”en-us”,”loop”:false,”partnerName”:”cloud-blogs”,”poster”:”https://cdn-dynmedia-1.microsoft.com/is/image/microsoftcorp/1117657-full-interview_tbmnl_en-us?wid=1280″,”title”:”Full interview”,”sources”:[{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview-0x1080-6439k”,”type”:”video/mp4″,”quality”:”HQ”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview-0x720-3266k”,”type”:”video/mp4″,”quality”:”HD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview-0x540-2160k”,”type”:”video/mp4″,”quality”:”SD”},{“src”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview-0x360-958k”,”type”:”video/mp4″,”quality”:”LO”}],”ccFiles”:[{“url”:”https://azure.microsoft.com/en-us/blog/wp-json/bloginabox/v1/get-captions?url=https%3A%2F%2Fwww.microsoft.com%2Fcontent%2Fdam%2Fmicrosoft%2Fbade%2Fvideos%2Fproducts-and-services%2Fen-us%2Fazure%2F1117657-full-interview%2F1117657-full-interview_cc_en-us.ttml”,”locale”:”en-us”,”ccType”:”TTML”}],”downloadableFiles”:[{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview_transcript_en-us”,”locale”:”en-us”,”mediaType”:”transcript”},{“url”:”https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/1117657-full-interview_audio_en-us”,”locale”:”en-us”,”mediaType”:”audio”}]};

if (currentTheme) {
options.playButtonTheme = currentTheme;
}

document.addEventListener(‘DOMContentLoaded’, () => {
ump(“ump-6ab4e15490faf”, options);
});

The three clips above are drawn from a longer conversation covering the 2014 change that came close to taking Azure down, how we learned to measure health from the customer’s point of view, what breaks differently when a dependency is an AI model, and why the hardware in a datacenter fails every single day. Check out the full interview on the Azure Essentials YouTube channel.

Azure Essentials

Check out the full interview on the Azure Essentials YouTube channel.

Watch now

Resources

Cloud Resiliency

Azure Essentials

Azure Infrastructure Resiliency Manager

Reliability design principles—Azure Well-Architected Framework

Health modeling for workloads—Azure Well-Architected Framework

Health models in Azure Monitor (preview)

Cloud Adoption Framework for Azure

Azure Architecture Center

Reliability and Sovereignty in Azure

What’s new in the Resiliency service

Enable Zone Resiliency for Azure Workloads

Azure Chaos Studio documentation

Azure Site Recovery documentation

Azure Backup documentation

Carne Group boosts infrastructure and cyber resilience with Azure Site Recovery and Backup

Safe deployment practices—Azure Well-Architected Framework

Meet Brain: The AI system behind Azure reliability

Optimizing incident management with AIOps using the Triangle System

Proving application resilience on Azure with Chaos Studio

Advancing reliability—Azure Blog series

The post Your architecture diagram is not your resilience appeared first on Microsoft Azure Blog.
Quelle: Azure