Azure News - 2026-08-14

In May, I introduced the open-source Azure Architecture Diagram Builder as a way to move from a natural-language prompt to an Azure architecture diagram, cost estimate, Well-Architected assessment, and deployment guidance. In July, I shared how the project had become agent-ready through Model Context Protocol (MCP).

Those posts described what the tool could do. The more interesting story came next: what happened when people actually used it.

As adoption grew, the central product question changed. It was no longer simply, Can AI generate an Azure architecture? It became:

How do we help an architect choose how to begin, improve a result without losing their work, validate it responsibly, and turn it into something another person can use?

That question reshaped the Azure Architecture Diagram Builder from a collection of capabilities into a guided workflow:

Create → Refine → Validate & Improve → Share or Build

This post explains what we learned, what changed in the product, and why the hardest part of AI-assisted architecture is not the first diagram. It is everything that comes after it.

TL;DR. Growing adoption created a feedback loop. Aggregate usage showed that people moved beyond generation into validation, recommendations, exports, and deployment guidance. Privacy-safe feedback revealed recurring problems with diagram integrity, preservation of human edits, cost credibility, export quality, and validation continuity. Those signals led to a four-stage architecture journey that keeps human judgment and professional review at the center. The same lesson now shapes agent access and the next product boundary: distinguish logical proposals from evidence-backed physical architecture.

Adoption created a product feedback loop

As of August 5, 2026, the first two Azure Architecture Blog articles had accumulated approximately 12,100 combined views. A refreshed view of deduplicated application telemetry through August 13 recorded:

As of August 13, the public repository had reached 45 stars and 14 forks. In GitHub’s current rolling 14-day window, the repository recorded 277 unique visitors and 67 unique cloners.

These numbers measure different things and should not be added together. Article views are not unique readers. Application activity uses anonymous telemetry identifiers, not verified people. GitHub traffic is a rolling aggregate window. The signals are useful because of the pattern they reveal, not because they can be combined into one headline user count.

Activity also accelerated during the period following the second article. Compared with the May 19–July 9 baseline, daily activity from July 10 through August 13 was approximately 7.0 times higher for architecture generation and refinement, 5.6 times higher for Well-Architected validation, and 5.9 times higher for recommendation application. The timing coincided with publication; it does not prove that the article alone caused the growth.

The important product lesson was simpler: people were not stopping after the first diagram.

They were testing alternatives, validating designs, applying recommendations, exporting artifacts, and asking how to move toward implementation. Generation was the entry point, not the complete job.

The first guided-journey signals reinforce the need for more than one starting path. Through August 13, the new journey instrumentation recorded 880 interactions from 174 anonymous identifiers across 241 sessions. At first start, structured brief/image generation and Guided Chat were selected at almost the same frequency (158 and 156 events), while template and live-Azure import added another 68 selections. These are interaction counts, not unique people or conversion rates, and the window is still too early to claim that the journey improves completion. They are enough to show that architecture work does not begin in one uniform way.

Figure 1. The in-product Start Here panel explains one complete architecture loop. The stages are recommendations, not gates, and direct access to every tool remains available.

Stage 1: Create — make the starting choice explicit

As capabilities accumulated, the first screen became harder to interpret. Architecture Chat and structured generation were both useful, but they competed for attention. Importing an existing architecture was available, yet easy to miss.

The new starting experience makes three paths explicit:

This is not a marketing landing page placed in front of the tool. It is a small decision point inside the authoring experience. Once a path is selected, the user lands on the real canvas.

The distinction matters because different architecture tasks begin with different levels of certainty. Sometimes the architect knows the target services. Sometimes the problem needs discovery. Sometimes the architecture already exists and the work is to understand or improve it.

The product should acknowledge those differences instead of pretending every design starts with a perfect prompt.

Figure 2. Three starting paths reflect three different architecture situations: discovery, structured generation, and analysis of an existing design.

Stage 2: Refine — preserve human work

One of the clearest feedback themes was not about adding another AI capability. It was about preventing AI from casually undoing human effort.

An architect might spend time arranging a one-page diagram for a review, resizing groups, moving labels, or emphasizing a specific boundary. A subsequent AI refinement could improve the service selection while disrupting that carefully prepared layout.

The design principle that emerged was straightforward:

AI acceleration should preserve deliberate human work by default.

Refinement now retains existing node positions, group geometry, sizes, and viewport context whenever possible. The model can change the architecture without treating every turn as permission to redraw the entire document.

The same principle applies beyond geometry:

• Preserve the prior validation result when recommendations change the architecture.
• Preserve the active light or dark theme in exported artifacts.
• Preserve the distinction between the authoring canvas and the presentation deliverable.
• Preserve user-configured pricing assumptions rather than replacing them with one fixed estimate.

This is a broader lesson for AI-assisted tools. A generated result is not the only source of value. The edits, judgments, and communication choices a person adds afterward are part of the artifact too.

Figure 3. In this controlled synthetic refinement, all eight existing service positions and four group anchors remained unchanged. The containing Application group expanded to accommodate the new edge tier, so preservation does not imply that every group dimension stays fixed.

Quality is structural, not only visual

A diagram can look polished while still being architecturally confusing. Early feedback exposed cases where a generated service appeared disconnected because a model referenced a display name instead of the service identifier used by the canvas.

The correction was not another prompt instruction alone. The application now resolves connection endpoints across identifiers, normalized service names, and service-type aliases. It repairs valid edges, drops invalid or self-referential edges, detects remaining orphan nodes, and records aggregate integrity signals.

That creates a more useful definition of diagram quality:

• Are the services connected as intended?
• Were any generated edges repaired or dropped?
• Are there orphaned nodes?
• Did refinement preserve the existing layout?
• Did an architecture change receive a fresh validation?

Visual polish still matters, especially when an artifact leaves the editor. But structural integrity gives the product something deterministic to test and monitor.

Stage 3: Validate & Improve — treat validation as a lifecycle

The Azure Well-Architected Framework is most useful when validation becomes iterative rather than ceremonial.

The Diagram Builder can assess a proposed design across the five Well-Architected pillars, surface findings, and apply selected recommendations. But that workflow exposed an important state-management problem: when the architecture changed, the prior validation result disappeared along with the obvious route back to revalidation.

The updated experience keeps the previous report, marks it Revalidate Needed, and makes clear that the score describes an earlier state of the architecture. A new validation replaces it only after the updated design has been assessed.

This distinction prevents a stale score from looking current.

It also clarifies what an architecture-level assessment can and cannot prove. A diagram may show that a WAF, cache, backup service, or secondary region exists. It usually cannot prove that purge protection, diagnostic routing, encryption settings, role assignments, health probes, or failover policies are configured correctly.

That is why validation findings need to distinguish between:

• Pattern-level gaps — missing or misplaced architectural components
• Configuration-level gaps — required settings that must be verified in Infrastructure as Code or the deployed environment

Generated scores and recommendations help architects review a design; they do not replace an Azure Well-Architected Review, security review, deployment validation, or professional judgment.

Figure 4. Architecture changes make a previous validation historical, not useless. The result remains available while the interface clearly asks for a fresh validation.

Stage 4: Share or Build — design for the artifact’s destination

The editing canvas and the final deliverable serve different purposes.

Canvas dots, handles, navigation controls, and selection states help during authoring. They can make an exported diagram feel unfinished. The Diagram Builder now separates those concerns with Plain, Dots, and Grid export backgrounds while preserving the active light or dark theme.

Figure 5. Authoring and delivery are different contexts. The upper view shows the editable canvas and its real export controls; the lower view is the Plain PNG produced from that same canvas, without editing chrome.

Cost language is deliberately qualified. Azure services often combine fixed, usage-based, and configuration-dependent charges. A baseline that includes six numerically priced services but excludes 20 usage-based items is not the total cost of the architecture. The output identifies those exclusions rather than treating missing values as zero.

The final stage also includes deployment guides and Infrastructure as Code. Here, honesty about artifact coverage is essential. A generated Bicep file may be a useful starter while still omitting private endpoints, diagnostic settings, failover configuration, or service-specific resources. The artifact should state what it implements, what remains conceptual, and whether Azure Resource Manager validation passed.

AI-generated diagrams, costs, validation results, deployment guides, and Infrastructure as Code should all be reviewed and validated before production use.

The same journey now extends to agents

The MCP server introduced in the previous article makes the Diagram Builder available to agent experiences such as Microsoft Scout. The four-stage journey provides a useful way to think about agent orchestration too:

1. Import or create one canonical architecture.
2. Refine it without silently changing the intended topology.
3. Validate it, apply supported improvements, and revalidate.
4. Render or generate artifacts with explicit coverage and limitations.

The current MCP surface exposes 12 tools, three resources, and three reusable prompts. It can normalize an existing architecture, validate and harden it deterministically, estimate regional costs from a dated pricing snapshot, render presentation/technical/cost views, and generate Bicep, Terraform, and deployment guidance. The calling agent still owns orchestration and reasoning; the MCP server is intended to remain a deterministic architecture capability, not a second hidden agent.

The native MCP renderer can project one canonical architecture into three communication profiles:

• Presentation emphasizes the primary request path, reduces supporting labels, and removes pricing.
• Technical preserves complete connection detail for engineering inspection.
• Cost retains the focused composition while adding service-level pricing assumptions, a fixed-priced baseline, and explicit exclusions.

These are MCP-generated SVG views, not Blueprint diagrams or screenshots of the editable web canvas. The services, connections, and groups remain the same; only the information treatment changes.

Figure 6. Native AADB MCP output from one 8-service, 9-connection, 4-group architecture. Presentation prioritizes the story, Technical exposes connection detail, and Cost foregrounds pricing assumptions and exclusions.

Recent work on the MCP renderer added purpose-built presentation, technical, and cost profiles. More importantly, testing agent-generated artifacts reinforced an accountability principle: a polished diagram and a compiled Bicep file do not prove deployability.

An agent workflow should report whether topology changed, whether validation improved, which services are represented only conceptually, and whether the generated IaC passed Azure preflight. That is more useful than an unsupported claim that a design is production-ready.

Trust also includes the tool boundary itself. The hosted MCP endpoints now require a bearer token for real session operations; missing or incorrect credentials are rejected. A shared token is appropriate for the current controlled integration, but it is not the end state for enterprise multi-user access. Entra ID/OAuth, per-client authorization, rotation, and revocation remain future hardening work.

Figure 7. The guided lifecycle extends beyond the web application. In this synthetic Scout run with GPT-5.6 Sol, the agent used authenticated AADB MCP tools to validate, harden, cost, render, and generate starter artifacts while explicitly reporting coverage gaps and that nothing was deployed.

Learning from adoption without identifying people

Product learning does not require reconstructing individual identities.

The findings behind this article use aggregate, deduplicated application telemetry, public article counters, public repository totals, and paraphrased feedback themes. They do not correlate Application Insights identifiers, feedback records, GitHub accounts, or email addresses.

Written feedback remains submittable without contact information. When someone explicitly opts into follow-up, the email address is stored with the feedback record in Cosmos DB and is not sent to normal product telemetry. The current 180-day expiry field is a retention marker; automated deletion must be implemented and verified before describing that retention period as enforced.

Those boundaries matter for both product design and public writing:

• Aggregate activity rather than profiling individuals.
• Paraphrase themes rather than publishing comments without permission.
• Keep optional contact consent separate from telemetry.
• Avoid presenting anonymous identifiers as confirmed people.
• Avoid claiming that publication timing proves acquisition causality.

This is not a claim of legal compliance. It is a product discipline: collect less, preserve user agency, and make only the claims the evidence supports.

What changed

The guided journey is the visible result, but the deeper change is how the project now evaluates progress.

The model portfolio continued to evolve as well. The production selector now contains 15 configured entries, including MAI-Thinking-1 (Public Preview). But the more consequential changes in this article are deliberately model-independent: preserve human work, keep state and provenance explicit, qualify generated artifacts, and authenticate the tools agents can call.

The goal is not to remove flexibility. Architects can still open any tool directly, rearrange the canvas, reject recommendations, change pricing assumptions, or export at any point.

The goal is to make the workflow coherent without pretending architecture itself is linear.

The next boundary: logical versus physical architecture

Recent feedback points to a harder problem than adding another model or export format. Architects working with private Azure AI landing zones need to distinguish shared platform resources from project-owned resources, preserve VNet and subnet boundaries, and reason about CIDRs, NSGs, route tables, private endpoints, DNS, and managed identities.

The current Topology mode can show services and relationships, but it should not imply exact physical fidelity when those facts are absent. A useful logical diagram answers what exists and how it interacts. A physical or low-level design must answer where it is deployed, how it is isolated, and which values came from evidence.

That is the next technical direction I am exploring: an evidence-aware Physical Architecture view backed by deterministic reconstruction from Terraform plan/state, ARM, or a live Azure inventory. Exact fields would be labeled as observed or resolved; AI suggestions would remain explicitly proposed; unsupported or missing inputs would be reported instead of silently invented.

This capability is not shipped today, and it will require its own schema, validation rules, layout, security review, and evaluation set. That distinction matters. The lesson from adoption is not to put every architecture concern into one crowded canvas. It is to make each artifact’s purpose and evidence boundary clear.

Try it, challenge it, help shape what comes next

The Azure Architecture Diagram Builder remains open source, and the live experience is available today:

• Live app: https://aka.ms/diagram-builder
• Source code: github.com/Arturo-Quiroga-MSFT/azure-architecture-diagram-builder
• Getting started: Documentation and deployment guidance

The next phase is to measure whether the guided journey helps people complete the full loop, especially recommendation-to-revalidation and artifact-generation success. In parallel, I am beginning the narrower physical-architecture investigation described above. Both efforts will use aggregate signals, reviewed fixtures, and sufficiently large cohorts rather than individual journey reconstruction.

Try the workflow with a real architecture problem. Tell me where the handoffs are unclear, where the diagram loses intent, or where an artifact claims more than it implements. Those are the gaps worth fixing next.

Measurement note: Article views are rounded public counters observed August 5, 2026. Application figures use deduplicated retained telemetry through August 13 and anonymous identifiers. GitHub totals and rolling 14-day traffic were observed August 13. The comparison windows are May 19–July 9 and July 10–August 13. These signals have different populations and must not be added together. Timing comparisons show concurrent activity, not causal attribution.

The next era of AI infrastructure will be defined not by a single breakthrough, but by how well we co-design every layer—from models and software to silicon, servers, racks and datacenters. At the Open Compute Project Asia Pacific Summit, we are proud to share the latest community innovations that exist to solve the variety of infrastructure demands up and down the stack that have been brought forth by the diverse workloads powering agentic AI today.

That same full-stack philosophy guides how Microsoft builds purpose-built AI infrastructure for cloud scale: co-optimizing silicon, software and systems to improve efficiency, performance and security. In our Maia 200 accelerator, we applied this approach to Microsoft’s production inference workloads, co-designing chip, model, and system to improve performance per dollar and performance per watt. The Azure Cobalt 200 CPU extends it to cloud-native and agentic computing, with an architecture designed for concurrency, orchestration and faster agent call patterns. The Azure Boost DPU brings the same discipline to storage and networking by offloading infrastructure services from host CPUs to purpose-built silicon, improving performance consistency and efficiency while reducing power, thermal footprint, and overall cost. Together, these platforms show the value of engineering hardware and software as one system—and establish the foundation for innovation that extends beyond the chip to the rack and datacenter.

Innovation beyond the chip

Across Azure, we are advancing rack-level architectures, liquid cooling and highly optimized compute and storage services alongside silicon. In our Fairwater datacenter, infrastructure is designed around the density and operating characteristics of modern AI systems. At the component level, next-generation heat exchanger units help transfer heat efficiently from high-density racks, while microfluidics points toward more direct cooling at the chip itself. Across the power path, Mt. Diablo disaggregates rack-scale power from compute, solid-state transformers simplify conversion, high-temperature superconductors offer a path to move greater amounts of power with lower resistive loss, and high-temperature fuel cells create opportunities to generate power aligned with future 800 VDC datacenter designs. These efforts are complementary: each removes a different system bottleneck, and together they create room for denser, more reliable and more sustainable AI infrastructure.

Rearchitecting power from grid to chip

Power architecture is one of the clearest examples of why open, system-level collaboration matters. Microsoft, NVIDIA and Meta are contributing to the industry’s transition toward 800 VDC through OCP work that helps connect facility power, conversion, distribution and rack design into a practical roadmap. Moving to higher-voltage direct current can reduce conversion stages between the grid and the accelerator, helping more available power reach compute as rack densities rise. The broader architecture also supports multiple adoption paths: hybrid-compatible power racks can bring 800 VDC into facilities built around existing AC infrastructure; row-level systems can distribute power across multiple racks; and future native designs can convert medium-voltage power directly to 800 VDC. Alongside the evolving Diablo specification and the solid state transformer specification providing a medium voltage to 800VDC power conversion platform, these joint contributions give equipment providers common interfaces around which to design, test and build. Alongside the evolving Diablo specification and the LVDC solid-state transformer specification, these joint contributions give equipment providers common interfaces around which to design, test and build. That openness is essential to creating a resilient supply chain and giving operators a credible path from today’s facilities to the AI factories of the next decade.

Cooling innovation is equally important because the traditional tradeoff between density and thermals has reached its limits. Rather than treating cooling as a facility afterthought, we are co-designing it with chips, modules, servers and racks. Closed-loop liquid systems can support sustained performance while minimizing water use. Heat exchanger units can improve the efficiency and serviceability of rack-level cooling. Microfluidic approaches can bring coolant closer to where heat is generated, opening a path to lower peak temperatures and higher density. The goal is not a collection of disconnected technologies; it is an end-to-end thermal architecture that can evolve with successive generations of compute.

Architecting the next generation of AI networks

Networking must evolve with the same end-to-end discipline. Within a scale-up domain, AI systems need high bandwidth, low latency, low power and predictable reliability across tightly coupled accelerators. Our work to drive Ethernet Scale-Up Networking, or ESUN, advances open Ethernet as a common scale-up fabric, incorporating input from a broad ecosystem so designs can scale without locking the industry into a closed approach. Beyond the pod, scale-out fabrics must connect massive clusters while maintaining real-time visibility, path-level resilience and efficient utilization. Multipath Reliable Connection, or MRC, is designed for that environment: it enables traffic to use multiple paths, adapt automatically at machine timescales and support resilient, predictable training across systems exceeding 100,000 GPUs. Optics completes this story by extending scale efficiently. Through work such as the OCI-MSA, tighter integration between optical connectivity, compute and networking silicon can increase bandwidth density and system scalability. Together, MRC, Ethernet scale-up networking and scale-out optics form a continuum—from accelerator to pod, from pod to datacenter, and from datacenter to a distributed AI supercomputer.

The value of this full-stack approach compounds. Better silicon raises system efficiency. Better system design increases infrastructure utilization. Better power, cooling and networking lower the cost and complexity of training and serving models. And improvements at every layer translate into more capable, reliable and accessible AI services for customers. This is how the industry can move beyond incremental optimization and begin bending the cost, power and complexity curves together.

Accelerating together as one community

No company can solve these challenges alone. Progress depends on earlier collaboration across silicon providers, packaging partners, manufacturers, networking companies, cloud providers, datacenter operators, researchers and standards organizations. We’re proud to be part of the broader Open Compute Project Global Foundation community, driving progress in an open forum to turn individual breakthroughs into shared progress. Microsoft welcomes deeper partnership across power, cooling, networking, security, sustainability and systems design—especially within the APAC ecosystem, where so much of the world's advanced computing infrastructure comes to life.