Amplifier Bundle · Azure ZAP

Fail Closed

A safety-gated pipeline for Azure deployment

What ZAP is

Say “deploy my website to Azure” and ZAP turns plain English into a validated, safety-gated plan

The Azure ZAP bundle transforms natural-language requests into validated, executable Azure deployment plans — detecting dependencies, recommending tiers, estimating cost, and building a phased plan that waits for your approval.

But how risky is the surface it has to reason about? The numbers set the stakes.

6

Single-purpose ZAP agents (originally five)

5

Planning phases from intent to plan

The problem is real

Dozens of services — and calls that can wipe production data

The bundle’s own tools reference documents 43 Azure service namespaces and 127 unique azmcp_ tools. Among them are destructive operations whose names match patterns like these.

A surface this large, with irreversible actions in it, is what makes deployment genuinely dangerous.

43

Azure service namespaces documented

127

Unique azmcp_ tools documented

*_delete *_purge *_drop *_clear *_reset

The complication

One generalist “Azure agent” would be too shallow to choose safely — or to refuse a dangerous delete

Picking the right services across 43 namespaces, ordering dependencies, and catching a destructive call is deep, specialized work. A single all-purpose brain is spread too thin to do any of it reliably.

So ZAP does not use one brain. It uses a pipeline.

The core design move

ZAP hands the job down a fixed pipeline of single-purpose agents

Each agent does one thing well and hands off to the next in a fixed order — with a mandatory human approval gate before anything executes.

One of those links, the planner, does work a generalist never could.

1project-analyzerInfers requirements from the codebase

2azure-mcp-expertSelects Azure MCP tools and services

3azure-task-plannerBuilds the multi-phase plan

4azure-task-watchdogRequired fail-closed safety gate

✓User approval gateReview plan, approve cost, confirm services

5azure-task-executorRuns the approved plan phase-by-phase

Deep work, before Azure is touched

The planner turns intent into a phased plan with rollback and cost estimates

Across five planning phases the planner analyzes requirements, consults the MCP expert, designs a service topology as a dependency graph, builds a multi-phase plan with per-phase rollback, and generates verification steps.

Then the plan meets the one agent whose whole job is to say no.

1Analyze requirements

2Consult MCP expert

3Design service topologyDependency graph

4Build multi-phase planWith per-phase rollback steps

5Generate verification steps

The last line of defense

The watchdog doesn’t warn — in strict mode it BLOCKS

The watchdog is a required safety gate whose first principle is “Fail closed: when in doubt, BLOCK.” In strict mode (the default) it blocks rather than warns, across three graduated modes: strict, development, and production.

This is the pivot: safety stops being advice and becomes enforcement.

BLOCKAll destructive operations (delete / purge / drop / clear / reset)
BLOCKIf estimated cost exceeds budget
BLOCKIf there is insufficient quota

Fail closed

When in doubt, the pipeline BLOCKS — and a human must approve before anything runs.

A mandatory human approval gate stands between watchdog validation and execution. The executor never runs without watchdog approval — it executes only validated, approved plans, phase-by-phase with health checks and automatic rollback on failure.

Safety here is structural, not advisory. That’s the reusable idea.

The pattern to keep

Split a risky job into single-purpose agents behind a fail-closed gate

Decomposition plus a required, fail-closed safety gate and a mandatory human approval is the reusable pattern — and it’s honest about its stage: shipping today as an early-development alpha.

Young, single-author, and transparent about what still ships as illustrative examples.

v0.1.0

Alpha — status “Early Development”

5

Commits total, sole author Mark Licata

Sources

Research Methodology

STATUS: 0.1.0-ALPHA · EARLY DEVELOPMENT

Repo: git@github.com:marklicata/amplifier-bundle-azure-zap.git — branch main, HEAD 085accf, cloned to /tmp/azure-zap. Every claim independently re-derived via git log/show, ls, wc -l, grep and sed on the actual clone.

Commands run:

ls agents/*.md | wc -l and grep -n 'azure-zap:' bundle.md — 6 single-purpose agents
git show --stat ad1fc3e / git show --stat 6b7de86 — initial 5 agents; executor added and planner/watchdog renamed
grep -cE '^#### .*(`[a-z]+`)' context/azure-mcp-tools-reference.md and grep -oE 'azmcp_[a-z_]+' ... | sort -u | wc -l — 43 namespaces, 127 tools
grep -n -i 'BLOCK|Fail closed|destructive' agents/azure-task-watchdog.md and sed -n '238,270p' ... — block rules & destructive patterns
grep -n -i 'phase|rollback|cost|dependency' agents/azure-task-planner.md — 5 planning phases with rollback
sed -n '116,172p' bundle.md — orchestration flow with user approval gate
git rev-list --count HEAD / git shortlog -sne HEAD / grep -n 'Version:|Status:' bundle.md — 5 commits, Mark Licata, v0.1.0-alpha

Gaps: The 43 namespaces / 127 tools are grounded only in the bundle’s own documentation, not a live Azure MCP Server. Dollar and time figures in bundle/README examples are illustrative doc scenarios, not measured outcomes. Referenced recipe YAMLs and some docs were not found in the clone.

Primary contributor: Mark Licata (malicata@microsoft.com) — 5 of 5 commits (sole author).