Azure Advisor

This work is in private preview. Visuals are drawn from Microsoft's public Build 2026 materials and abstracted diagrams.

Challenge: advice without context is noise

Azure Advisor evaluates your cloud footprint and tells you how to improve it. Cut costs, improve reliability, prepare for service retirements. The recommendations are technically sound. And for years, customers largely ignored them.

Companies organize resources in Azure a dozen different ways, across tags, resource groups, and subscriptions, with no standardized approach. Advisor generates recommendations at the individual resource level. For a large enterprise, that's thousands of resources, each producing its own advice.

The system can see everything and understands almost nothing. It knows you have a VM that isn't zone-redundant. It has no idea whether that VM runs your ecommerce platform or your company dodgeball team's stats page. Both get the same recommendation, with the same urgency, in the same endless list.

The classic experience: 8,483 impacted resources under a single category, hundreds of recommendations across five pillars. Technically correct advice with no way to know which of it matters to your business.

Faced with a wall of context-free advice, customers made a rational choice: they did nothing. Ignoring it was the sensible move, which made it our problem to solve.

The system sees everything and understands nothing. The customer holds the missing context. The experience bridges the gap by asking.

Approach: ask before you rank

The tempting fix is a smarter ranking algorithm. But no model can rank its way out of missing information. The criticality of a workload lives in the customer's head, not in the resource metadata. The only way to get it is to ask.

So we inverted the problem. Instead of Advisor broadcasting everything it knows, the new experience, an AI-powered chat unveiled at Microsoft Build 2026, starts by asking the customer what matters:

Scope: Which subscriptions and resource groups map to your mission-critical applications? Up to 10 of each, an intentional constraint.
Intent: What are you actually here to do? We launched with two jobs: improving resiliency (raising your nines of availability) and navigating service retirements (what your resources depend on that's going away, and by when).

From there, the experience returns a curated list: the top five recommendations per category.

The GA Advisor experience: thousands of active resources, recommendations organized by category, and the new AI-powered entry point.

The conversation starts with a question: which subscriptions matter. Then it shows its five steps of work before it says anything about what to fix.

The two decisions I drove

Capping recommendations at five per category. The wall of recommendations was the original sin of the old experience. Every additional item past a handful reduces the odds that any get acted on. Five is enough to matter and few enough to finish.

Designing what each recommendation shows. The old model was a dense table where most columns were noise most of the time. I reframed the question: what is the minimum information that tips someone into a decision? For retirements, it's two things: when the retirement happens and how many resources are affected. For resiliency, it's the number of resources involved and cost impact, deliberately abstracted to high, medium, or low. Showing false precision the underlying estimate can't support would manufacture confidence we hadn't earned. Everything else is available on demand, not by default.

Five recommendations matched to the chosen scope, each with its impact, affected resources, progress, benefit, and the reason it ranks where it does.

The action plan: next 30 days, one to three months, and three months out, with Word and PDF export, feedback, and suggested follow-up prompts.

Showing the work

An AI system that tells an enterprise what to fix first has to earn that. A few things in the preview exist for that reason, and they're visible in the public Build demo:

The steps are on screen. While it works, the experience lists what it's doing (loading context, resolving the Azure scope, analyzing intent, planning tasks) instead of a spinner. People can see that it read the scope they picked.
Every row says why. The recommendation table carries a Prioritization reason column, such as "30-day deadline on production storage accounts still running legacy tiers." A customer who disagrees with the ranking can see exactly what to push back on.
It summarizes, then hands over. A short paragraph says what to do first and why. The detail exports to CSV, because the people who act on this work in their own tools, not in a chat window.
It says what it is. Responses are labeled as AI-generated with a prompt to verify, and every answer takes a thumbs up or down.

One recommendation opened up: why these resources were prioritized, the retirement date, remediation guidance, and every impacted storage account.

The whole conversation exported to PDF, with the insights and the five recommendations in a table someone can forward.

What we shipped without

The chat experience shipped under real constraints. Build and Ignite are immovable dates, and the durable infrastructure wasn't ready. So what we launched is deliberately scoped: each conversation is point-in-time, the context a customer provides isn't yet captured back into the system, and it happens at the individual user level rather than the organization level.

That last one matters. Resource management is a team sport. If one engineer has a great conversation with Advisor and the resulting priorities aren't visible to anyone else at the company, we've created communication churn. The tool got smarter for one person and the organization stayed exactly as confused. I pushed hard on this tension internally, and it shaped what came next.

From asking to knowing

Running behind the preview is the real answer: Service Groups, which went live at Ignite 2025. Service Groups let organizations formally capture which resources belong together as an application or service, the context Advisor always lacked, and attach goals to them. Today that's resiliency intent: should this group be zonally resilient? The trajectory is goals across the Well-Architected pillars: performance, cost, security, reliability.

The chat experience and Service Groups are two halves of one strategy. The conversation captures intent now, one session at a time. Service Groups make intent durable, shared, and organizational, so the system eventually stops interviewing you and starts knowing you.

Two tracks, one strategy: the conversation captures intent now, and Service Groups make it durable and organizational.

Impact

Shipped to private preview at Microsoft Build 2026, with scope and intent as the entry point instead of the full recommendation list.
Five recommendations per category instead of hundreds, each with the minimum information needed to decide and a stated reason for its rank.
Service Groups generally available since Ignite 2025, giving Advisor a durable, organization-level place to store the context customers provide.

The hardest calls were about what the AI should ask, when it had earned the right to recommend, and how to keep it from sounding more confident than the data allowed.

Leading the team

I led a team of six designers and UX researchers across Azure Advisor, CX Observe, and the customer-health products. I gave people whole workstreams rather than pieces of mine, so decisions didn't all route through me. Most of my own time went upstream: turning priorities from several organizations, sometimes contradictory, into a direction the team could execute, and making the team's work visible to executives so it got funded. Microsoft recognized that stretch with Azure X Manager of the Year for delivery results and people leadership.

Role & status

I led design across the Azure Advisor, Resiliency, and Customer Health teams through this work, and I personally own the recommendation experience design described above. The AI experience is in private preview as of Build 2026; Service Groups are generally available. This is in-flight work, and some of what's described will evolve before general availability.

Learn more

Public sources on the work described here:

Product images from Microsoft's public Build 2026 session BRK228 and public Azure Advisor videos.