az prototype — Scaffold Enterprise Azure Solutions with Copilot

A Four-Command Path From Idea to Azure

I've spent a lot of time writing about context engineering, agentic DevOps, and multi-agent systems. The pattern I keep coming back to: the teams moving fastest aren't the ones with the best prompts — they're the ones who've wired AI directly into their toolchains so it acts at the right level of abstraction.

az prototype is one of the most direct expressions of that idea I've seen come out of Microsoft. It's a new Azure CLI extension — currently in public preview, targeting a stable release in March 2026 — that lets you go from a napkin idea to a deployed Azure prototype in four commands:

az prototype init --name my-prototype --location eastus
az prototype design
az prototype build
az prototype deploy

That's not a toy demo. Behind those four commands is an 11-agent AI team, support for three AI providers (GitHub Copilot, GitHub Models, Azure OpenAI), enterprise-grade naming conventions, Infrastructure as Code generation in Terraform or Bicep, and policy-enforced security scanning before anything touches your subscription. If you work in enterprise cloud or partner solution delivery, this matters.

What's Actually Happening Under the Hood

The extension was created by Joshua Davis, and it comes directly from an internal Microsoft program called the Innovation Factory — a solution engineering initiative for rapidly delivering Azure prototypes to enterprise customers. That lineage is important. This isn't a side project. It's a production tool that was battle-tested inside Microsoft's own field sales and architecture teams before it shipped publicly.

The GitHub repository describes it plainly: "rapid Azure prototype generation powered by AI agent teams." The key phrase is agent teams. This isn't a single model being asked to write Terraform. It's a multi-agent workflow where specialized agents collaborate across distinct phases of the prototyping lifecycle.

The 11 Built-In Agents

Each agent has a defined role and operates as a specialized persona within the pipeline:

Agent	Role	What It Does
cloud-architect	Architecture	Cross-service coordination and solution design
terraform-agent	IaC	Terraform module generation
bicep-agent	IaC	Bicep template generation
app-developer	Development	Application code (APIs, Functions, containers)
doc-agent	Documentation	Project and deployment docs
qa-engineer	QA	Error diagnosis from logs, strings, or screenshots
biz-analyst	Analysis	Requirements gap analysis and design dialogue
cost-analyst	Finance	Azure cost estimation at S/M/L t-shirt sizes
project-manager	Coordination	Scope management and task assignment
security-reviewer	Security	Pre-deployment IaC security scanning
monitoring-agent	Observability	Monitoring and alerting configuration

This is the architecture that makes the tool genuinely useful for enterprise teams rather than just demos. A single model asked "build me a secure Azure data pipeline" will produce something that looks right but misses governance, skips cost analysis, and leaves monitoring as an afterthought. An agent team that routes design through an architect, security through a dedicated reviewer, and cost through an analyst produces something you can actually defend in an architecture review board.

The Four Stages in Practice

Stage 1: az prototype init

Scaffolds the project — creates a prototype.yaml configuration file, sets up authentication, and establishes the project structure. This stage is not re-entrant; run it once at the start.

Your prototype.yaml captures the full project configuration:

project:
  name: my-prototype
  location: eastus
  environment: dev
  iac_tool: terraform  # or bicep

naming:
  strategy: microsoft-alz
  org: contoso
  env: dev
  zone_id: zd

ai:
  provider: copilot
  model: claude-sonnet-4

agents:
  custom_dir: ./.prototype/agents/

Stage 2: az prototype design

This is the requirements and architecture stage — where the biz-analyst and cloud-architect agents take the wheel. Run it interactively to answer questions about your requirements, or provide artifacts upfront:

# Interactive discovery
az prototype design

# Provide context artifacts
az prototype design --artifacts ./requirements/ --context "Build a multi-tenant SaaS API with RBAC"

The design stage is re-entrant. If requirements change mid-project, re-run it and the agents will update the architecture accordingly. This is one of the most practically important features — most prototyping tools force you to start over when requirements shift. az prototype doesn't.

Stage 3: az prototype build

Generates infrastructure code and application code based on the design. You can build both or target a specific scope:

# Full build (IaC + application code)
az prototype build

# Infrastructure only
az prototype build --scope infra

# Application code only
az prototype build --scope apps

The security reviewer scans IaC output before it's finalized. Cost estimation runs automatically. Documentation is generated alongside the code. By the time build completes, you have a fully documented, security-scanned, cost-estimated prototype package — not just a pile of Terraform files.

Stage 4: az prototype deploy

Incremental deployment with change tracking. Only deploys what's changed since the last run:

az prototype deploy

Preflight checks run before any resource is created. If something would fail or violate policy, you find out before spending money on a botched deployment.

Enterprise Naming Conventions Built In

One of the details I find most impressive is the built-in naming resolver. Every agent uses it, so all generated resource names follow a consistent, enterprise-grade convention. Four strategies are supported out of the box:

Strategy	Pattern	Example
microsoft-alz (default)	{zoneid}-{type}-{service}-{env}-{region}	zd-rg-api-dev-eus
microsoft-caf	{type}-{org}-{service}-{env}-{region}-{instance}	rg-contoso-api-dev-eus-001
simple	{org}-{service}-{type}-{env}	contoso-api-rg-dev
enterprise	{type}-{bu}-{org}-{service}-{env}-{region}-{instance}	rg-it-contoso-api-dev-eus-001

The microsoft-alz strategy maps directly to Azure Landing Zone zones — dev (zd), test (zt), staging (zs), production (zp), plus platform zones for connectivity, identity, and management. If your organization uses ALZ (and most serious enterprise Azure deployments do), your prototypes will produce names that slot cleanly into your existing governance structure.

This matters more than it sounds. I've seen enterprise engagements collapse into week-long naming convention debates before a single resource was provisioned. Having a compliant naming strategy baked into every output removes that blocker entirely.

AI Provider Flexibility

az prototype supports three AI providers:

• GitHub Copilot — Requires a Business or Enterprise license. Backed by Copilot's multi-model selection, including Claude Sonnet 4, GPT-4.1, and Gemini 2.5 Pro.
• GitHub Models — Uses the GitHub Models inference API. Lower barrier to entry; no Copilot license required, just a GitHub account.
• Azure OpenAI — Your own Azure OpenAI deployment. For enterprises with compliance requirements that prevent using external AI services.

The provider is set in prototype.yaml. Switching providers is a config change — the rest of the workflow is identical. This is the right design. Enterprise environments have wildly different AI policy landscapes, and a tool that only works with one provider will stall at procurement.

Custom Agents and Extensibility

The built-in agent roster covers the common case well. But real enterprise architectures have domain-specific requirements. az prototype handles this with a YAML-based custom agent system:

# List available agents
az prototype agent list

# Add a custom agent from YAML
az prototype agent add --file ./my-agent.yaml

# Override a built-in agent with your own
az prototype agent override --name cloud-architect --file ./my-architect.yaml

A custom agent definition looks like this:

name: compliance-agent
description: Validates generated IaC against corporate compliance policies
role: reviewer
system_prompt: |
  You are a compliance reviewer specializing in financial services cloud governance.
  Review all generated infrastructure for SOC 2, PCI-DSS, and FINRA compliance gaps.
constraints:
  - Must use private endpoints for all data services
  - Must enable diagnostic logging on all resources
  - Must enforce encryption at rest using customer-managed keys
tools:
  - terraform
  - bicep

This is where I see the most interesting enterprise applications. A financial services team can override the default security-reviewer with one that knows their specific regulatory requirements. A healthcare organization can add a HIPAA compliance agent that runs alongside the standard security scan. The core pipeline stays the same; the domain expertise gets layered in via configuration.

Building custom agents for az prototype is exactly the same mental model as building custom agents for GitHub Copilot — define the persona, define the constraints, and let the orchestration handle routing.

Who This Is Built For

The honest answer: Partner Solution Architects and enterprise field teams. That's the explicit origin story. Joshua Davis built this inside Microsoft to accelerate customer engagements. The tool's vocabulary — ALZ zones, t-shirt sizing, preflight checks, backlog generation — maps directly to how enterprise cloud adoption actually works.

But I think it's valuable for a wider audience:

• Platform engineering teams who want a repeatable, AI-assisted way to scaffold new workloads while enforcing their organization's naming and governance standards
• Independent solution architects who spend too much time writing boilerplate IaC for each new engagement
• DevOps engineers who want to reduce the time from architecture decision to first deployable artifact

If you've ever spent three days creating the scaffolding for a "quick prototype" — writing Bicep modules, wiring up naming conventions, adding monitoring, documenting the architecture, generating cost estimates — az prototype is aiming directly at that problem.

Getting Started

Prerequisites: Azure CLI 2.50+, an Azure subscription, GitHub CLI (gh), and a GitHub Copilot Business/Enterprise license (if using the Copilot provider).

# Install the extension
az extension add --name prototype

# Initialize your first prototype
az prototype init --name my-app --location eastus

# Run design analysis
az prototype design --context "Build a containerized API with Azure Container Apps and Cosmos DB"

# Generate IaC and application code
az prototype build

# Deploy
az prototype deploy

The command reference is in the COMMANDS.md file in the repo. The lab repository from Arturo Quiroga has hands-on examples and additional scenarios including a VS Code integration and an MCP server wrapper that exposes 16 CLI tools for programmatic access.

The Bottom Line

az prototype is what happens when you take multi-agent AI seriously and point it at a real enterprise workflow instead of a toy demo. The four-stage pipeline, 11-agent team, built-in naming strategies, and provider flexibility aren't complexity for its own sake — they're the direct result of running this workflow with actual enterprise customers and learning what matters.

I've written about how agentic DevOps changes the engineering process and why context engineering is the foundational skill for AI-assisted work. az prototype is a concrete answer to the question: what does that look like in practice, for Azure, at enterprise scale? The answer is four commands and eleven agents. Try it.