Three months of usage data shape Azure Architecture Diagram Builder's four-stage workflow and integrity checks

Tool overview

Microsoft architect Arturo Quiroga's open-source Azure Architecture Diagram Builder was designed to move from a natural-language prompt to an Azure architecture diagram, cost estimate, and Well-Architected assessment. About three months of usage has turned it from a set of generation capabilities into a four-stage workflow: Create, Refine, Validate & Improve, and Share or Build.

Usage statistics

Telemetry through August 13 recorded 5,023 architecture generation and refinement events, 960 Well-Architected validations, 2,020 diagram exports, and 212 deployment guides generated. Daily activity after a second blog post in July ran roughly 5.6 to 7.0 times higher than the May-July baseline. The author is careful to note that article views, anonymous telemetry identifiers, and GitHub rolling traffic measure different populations and cannot be combined into a single user count. The usage shows people were not stopping at the first diagram: they tested alternatives, validated designs, applied recommendations, and exported artifacts.

Feedback-driven changes

The feedback themes shaped specific product changes. A central design principle: AI acceleration should preserve deliberate human work by default. Refinement now retains node positions, group geometry, sizes, and viewport context when possible, so a model can change service selection without redrawing a carefully arranged one-page review layout. Previous validation results are kept but marked "Revalidate Needed" when architecture changes, so a stale score cannot masquerade as current. The distinction between the authoring canvas and the presentation deliverable is now explicit in Plain, Dots, and Grid export backgrounds that omit editing chrome. Cost estimates state their exclusions rather than treating missing usage-based items as zero, and generated Bicep or Terraform files are expected to report what they implement, what remains conceptual, and whether Azure Resource Manager validation passed.

Integrity checks and MCP server

The tool also gained deterministic integrity checks: connection endpoints are resolved across service identifiers and type aliases, invalid or self-referential edges are dropped, and orphan nodes are detected. That gives diagram quality something testable, rather than relying on visual polish alone.

The MCP server that makes the tool agent-ready exposes 12 tools, three resources, and three reusable prompts for normalization, validation, cost estimation, rendering, and starter IaC generation. It is intended as a deterministic architecture capability, not a second hidden agent; orchestration stays with the calling agent. Hosted MCP endpoints now require a bearer token, though the author flags Entra ID/OAuth, per-client authorization, rotation, and revocation as remaining hardening work.

Next steps

The next technical direction is an evidence-aware Physical Architecture view that would reconstruct deployment detail from Terraform plan/state, ARM, or live Azure inventory, labeling fields as observed or resolved and explicitly marking AI suggestions as proposed. It is not shipped. The author plans to first measure whether the workflow improves completion rates, particularly recommendation-to-revalidation and artifact generation, using aggregate signals rather than individual journey reconstruction.

Availability

The tool remains available as a live app with source code on GitHub.