AzureFeeds

In Part 1 we made the case for an operations copilot that runs inside your own tenant. In Part 2, the Azure Support Agent‘s war room of specialist agents root-caused a live 5xx in about ninety seconds. But every one of those specialists had to be pointed at something first — and defining that “something” is the problem this post solves. Welcome to the second pillar: Map.

---

Here’s a question that sounds trivial and almost never is: which resources make up your application?

Azure knows. It exposes the answer generously, too — Azure Resource Graph will return every resource in the tenant, with full properties, from a single KQL query. The Portal shows every relationship if you click far enough down. Azure Monitor holds the metrics, Microsoft Entra ID holds the identities. Very little about your estate is genuinely hidden.

What’s scarce isn’t data. It’s time. Nobody has a spare afternoon each week to re-derive which forty of your eleven hundred resources constitute “the checkout app,” redraw the diagram, and write down why the private endpoint is there. So the map drifts out of date — not because the information went missing, but because keeping it current is work that never wins against a sprint. That’s a bandwidth problem, and bandwidth problems are exactly the kind of thing you can hand to an agent that never gets bored.

So the Azure Support Agent builds the map for you and keeps it alive. Five pieces, each feeding the next: Workloads that mean something, a live architecture diagram reverse-engineered from what’s actually deployed, an Architecture Memory that remembers design intent, a Know-Me doc your on-call can read at 3 a.m., and an Estate Graph that renders the whole tenant as one navigable picture.

One promise up front, because it shapes every design decision below: mapping your estate never changes it. Every feature in this post is read-only against Azure.

 

 

Part one — Workloads

A unit of scope that actually means something

A subscription is an accounting boundary. A resource group is a lifecycle boundary. Neither one reliably equals “an application.” So the workbench introduces one that does: the Workload.

A workload is a named set of scopes, and it can mix all four levels Azure gives you — a management group, a subscription, a resource group, or an individual resource ID. Real estates are untidy, so membership is subtractive as well as additive: every scope carries an excludes list, which lets you express “this entire resource group except that one legacy VM” without hand-listing thirty-nine resource IDs and re-listing them next month.

Alongside its scopes, a workload carries the metadata that everything downstream reasons about: workload type, environment, business criticality, data classification and free-form tags. That metadata isn’t decoration — the fleet views pivot on it, and the assessments in Part 4 weight their findings by it.

This layer matters more than it first appears, because the workload is the unit of scope for the entire product. Every assessment, every coverage report, every architecture diagram in this post, and every deep investigation from Part 2 is scoped to one. Get this right and everything downstream inherits it. Get it wrong and you’re running beautiful analysis on the wrong set of resources.

Autopilot: let the AI propose the boundaries

Defining workloads by hand is perfectly fine for five of them. It does not survive eleven hundred resources, and it really doesn’t survive an estate somebody else built.

Autopilot reads the estate and proposes the groupings, reasoning over exactly the signals an experienced engineer would use: tag values, naming conventions, resource-group boundaries, and which resources actually sit together. It’s built for real tenants rather than demos — a discovery pass handles up to 5,000 resources (and tells you when it truncated rather than silently sampling), feeding the model in batches of 500 in a map-reduce pattern so a large estate never has to fit inside one context window.

The important part is what happens next: nothing is saved behind your back. Autopilot streams out candidate workloads, each with its reasoning, a confidence level, and a breakdown of what’s inside it — and then it stops. Those candidates are proposals until you explicitly save them. You can rename, merge, split, or bin them. This is the same posture as the Launch gate in Part 2: the AI proposes, a human disposes.

Each Autopilot-born workload also remembers its origin — the management group or subscription it was discovered from — which powers a one-click Refresh when the estate moves on, instead of making you re-run discovery from scratch and reconcile by hand.

 

 

Groups, for when one app is really five

Most real applications exist several times over: CRM PROD, CRM DEV, CRM DR. Treating those as three unrelated workloads is technically correct and practically useless.

Groups are a non-destructive association on top of workloads — members keep their own identity, their own scopes and their own health score, but you can see them as one family. And because the naming pattern is so consistent in practice, the workbench will suggest the groupings for you: the suggestion pass strips environment tokens (prod, dev, stg, test, dr, shared, sandbox) from workload names and groups whatever stems match. CRM PROD and CRM DEV both stem to CRM, so they’re offered as a group.

It’s a small feature that does something disproportionately useful: it lets you ask “is this application healthy?” rather than “is this one environment of it healthy?”

A health score you’re allowed to argue with

Each workload the Azure Support Agent tracks carries a composite health score out of 100. The interesting part isn’t the number — it’s that you can take the number apart.

The score is a weighted average of seven signals, and they are deliberately not weighted equally:

Bands are plain: 80 and above is good, 50 and above is a warning, below 50 is poor, and a workload with no analyzed signals at all reads unknown rather than zero.

Three design decisions are worth pulling out, because they’re what make the number usable rather than decorative.

First, it explains itself. The API doesn’t return a bare score; it returns the contributing signals, the missing ones, and the weights actually applied. “Why is this 62?” has a real answer you can put on a slide, not a shrug.

Second, unmeasured never masquerades as bad. Signals you haven’t analyzed yet are excluded from the denominator entirely — a workload is never punished for a backup assessment nobody has run yet. It’s marked unknown and the score is computed from what’s actually known. A score that quietly conflates “bad” with “not yet measured” is a score people learn, correctly, to ignore.

Third, you can disagree. The weights are an admin setting. If your organisation’s risk appetite says tags matter more than that, change it — the score is a tool for your judgement, not a replacement for it.

 

 

The board, the table and the cockpit

Fleet views tend to fail in one of two directions: a wall of rows nobody reads, or a dashboard so abstract it says nothing. The workbench offers three deliberately different lenses.

The table is the working view — one row per workload with environment pills, the score badge, the individual health signals broken out, resource counts and a risk column that folds in retirements and critical findings. It’s what you scan on a Monday.

The board is a Kanban-style swimlane view grouped by environment — production, staging, development, test, DR, shared, unknown — which is the fastest way to spot the thing everyone dreads: something sitting in production with a health score in the reds.

The cockpit is the strip across the top: health distribution across the fleet, a composition treemap, an environment × criticality matrix, and a risk ticker. Four small pictures, each answering “where should I be looking?”

Underneath the visuals sits a shared resource taxonomy — every Azure resource type is classified into a category (compute, web, containers, data, storage, networking, security, integration, AI/ML, analytics, monitoring, management) and an architectural layer (edge, presentation, application, integration, data, networking, security, monitoring, shared). That single classification is what lets a donut chart, a treemap and an architecture diagram all speak the same language about the same estate.

And the charts themselves are honest little things: a composition donut by category, a seven-axis health radar (one axis per signal, so a lopsided workload looks lopsided), a sparkline of score trend, and a treemap of resource categories by weight. Click into a single workload and you get an Overview tab — at-a-glance, health and coverage, watchers, security, lifecycle — plus a full resource table, with chips that jump you straight to that workload’s architecture, its retirement radar, its policy view.

 

 

 

 

 

 

 

Part two — The Azure Support Agent’s Architecture Designer

Now draw it, from what’s actually deployed

This is the part that tends to make people sit up in a demo, so it’s worth going through properly.

Point the workbench at a workload, press Generate, and it reverse-engineers an interactive architecture diagram from live Azure data. What follows isn’t one big AI call — it’s a pipeline with a deliberate division of labour: Azure supplies the facts, the model supplies the reading of them, and code enforces the truth. That split is the whole reason the output is worth trusting.

Step one: read the estate, twice

The workbench resolves the workload’s scopes into a set of subscriptions, resource groups and resource IDs, then queries Azure Resource Graph in two passes.

The first pass is deliberately cheap — a lightweight inventory projecting only what it needs to identify things: id, name, type, kind, location, resourceGroup, subscriptionId, sku, identity, zones and tags, plus the resource groups themselves.

The second pass goes back for the interesting part: properties, fetched in chunks of 30 resources at a time. Properties are where the actual topology hides — but they’re also enormous and mostly irrelevant, so they’re filtered before they ever reach the model. The filter keeps keys that carry relationships and drops the rest:

networkProfile · ipConfigurations · subnet · privateLinkServiceConnections · serverFarmId · storageProfile · agentPoolProfiles · vnetSubnetID · backendPools · routingRules · keyVaultProperties · connectionStrings · siteConfig · hostNames · primaryEndpoints

Two budgets bound the whole thing: roughly 6,000 characters per resource against a 120,000-character total. When the budget runs out, the remaining resources are explicitly marked as omitted rather than silently dropped — the pipeline would rather tell you it ran out of room than quietly draw you an incomplete picture. A sprawling workload degrades gracefully instead of blowing the context window, which is the difference between a feature that works on your estate and one that only works in a screenshot.

 

 

Step two: what the model is actually asked to do

The model receives the workload name, the resource count, and a compact JSON array of resources with their trimmed properties. The instruction that matters most is this one: infer relationships from the properties, not from what you know about Azure in general. A model asked “how do App Services usually connect to SQL?” will confabulate a plausible architecture. A model asked “here is serverFarmId and here is privateLinkServiceConnections[], what do they tell you?” is doing evidence-based reading.

It’s asked to return a strict JSON contract — a name, a description, nodes[], edges[], groups[], a short rationale, and a confidence value. Nodes carry an arm_id tying them to a real resource. It’s permitted at most a couple of conceptual nodes without an ARM ID — “Users”, “Internet” — because a diagram with no origin for the traffic is harder to read, and that’s a bounded, honest exception rather than a licence to invent.

The call is given generous headroom (16,000 tokens) so a large estate doesn’t produce a diagram truncated mid-JSON, and if the model returns nothing it retries once before reporting failure rather than showing you an empty canvas.

Step three: the validation pass, where trust is actually won

This is the least glamorous stage and the most important one. Everything the model returns is treated as a proposal and put through normalization before it’s allowed near your screen:

• Groups are de-duplicated, and their kind is clamped to the permitted set — subscription, resource group, VNet, tier, custom.


• Nodes are de-duplicated, and each arm_id is cross-referenced against the real inventory. Category and layer are re-derived from the actual ARM type rather than trusted from the model. Node metadata is capped at six key–value pairs with length limits, so nobody can stuff an essay into a diagram label. Group references that point at a group that doesn’t exist are cleared.


• Edges get the strictest treatment: any edge pointing at a node that doesn’t exist is dropped, self-edges are dropped, duplicate source→target pairs collapse, and kind is clamped to the six permitted values. Logical relationships (identity, monitoring, dependency) are automatically drawn dashed so you can tell a network path from a conceptual one at a glance.


• Layout is applied automatically when the model hasn’t produced usable coordinates — if fewer than half the nodes have real positions, the diagram is laid out by tier.

The net effect is a rule that’s easy to state and easy to audit: a model can suggest a relationship, but it cannot invent a resource. If a node doesn’t correspond to something that genuinely exists in your tenant, it doesn’t survive to the canvas.

It’s a graph, not a picture

What lands is a typed model, not an image.

Edges carry meaning — six kinds, so the diagram expresses how two things relate rather than merely that they do:

Nodes are classified into twelve categories — Web & API, Compute, Containers, Databases, Storage, Integration, Networking, Security & Identity, AI & ML, Monitoring, Analytics, Other — each with its own colour, and into nine architectural layers that run edge → presentation → application → integration → data → networking → security → monitoring → shared. That layering is what lets the canvas arrange itself in tiers like a diagram a human would draw, instead of a hairball.

Groups wrap nodes by subscription, resource group, VNet or tier, which is what makes forty resources legible at all.

Reading the estate back to you

Each node renders as a card that carries rather more than a label. Alongside the name and a category-coloured Azure icon, it can show the hosting model (IaaS / PaaS / SaaS), a rough monthly cost estimate derived from type and SKU, and whether the resource is publicly or privately reachable — three questions an architect asks about every box on a whiteboard, answered on the box itself.

Nodes can also carry badges from two other systems: best-practice lint (single points of failure, missing redundancy) and assessment findings with their severity, so once you’ve run the Part 4 assessments the diagram becomes a heat map of where your problems physically live. Treat the cost figure as a sizing hint that tells you which corner of the diagram is expensive — not as a bill. Reconciled cost, against Cost Management, belongs to a later post.

 

The same diagram, six different questions

Because the diagram is a typed model rather than an image, it can be re-read without being redrawn. This is the part that surprises people in a demo, and it’s where a live canvas pulls decisively ahead of a Visio file.

Azure view turns on the shared-responsibility lens: every node picks up an IaaS / PaaS / SaaS / Net badge, a globe or padlock for whether it’s publicly or privately reachable, its indicative cost, and peering and private-link edges. Anything publicly reachable gains a red ring. It answers “what’s exposed here?” in one toggle, on a diagram you didn’t have to annotate.

WAF tint recolours the diagram by a failing Well-Architected pillar — Security, Reliability, Cost, Operations, Performance. Switch pillar and the highlight moves. Combined with the live assessment badge in the toolbar, the diagram becomes a map of where your findings physically live rather than a list of resource IDs in a report.

Boundary boxes regroup the whole diagram on demand: no boundaries, or by resource group, subscription, VNet, subnet or region. Watching the same twenty-odd resources rearrange from a flat application view into a subnet view is the fastest way to explain a network design to someone who’s never seen it — and it’s the clearest possible proof that this is a model, not a picture.

Hosting filter narrows to just IaaS, PaaS, SaaS or network plumbing, which is how you find the three VMs hiding in an otherwise serverless estate.

Impact is blast radius on the diagram: select a node and everything connected upstream and downstream lights up while the rest dims. Path traces the directed request path north-to-south through the system. Between them they answer the two questions every incident starts with — what does this depend on, and what breaks if it goes.

Review collects the best-practice lint into a numbered panel, and the findings also render on the nodes themselves — a Cosmos account with no private endpoint gets flagged in place, next to the resource, not in a spreadsheet.

None of these change the diagram. They’re lenses over the same validated model, which is exactly why they’re cheap to switch between.

 

 

 

 

 

 

 

A canvas you can actually work with

The diagram renders on a real graph canvas, so it behaves the way you’d expect rather than like a static export. Pan, zoom, drag nodes into a shape that matches how you think about the system, multi-select, and use the minimap when a diagram outgrows the viewport.

It’s a genuine editor, not a read-only render:

• Add resources by dragging from a categorised palette of Azure types.


• Draw edges by dragging from one node’s handle to another.


• Edit anything in the inspector — a node’s name, type, category, layer and metadata; an edge’s label, kind and dashed/solid style; a group’s name and kind.


• Add groups to carve the diagram into subscriptions, resource groups or tiers.


• Add sticky notes for the annotations every real diagram accumulates.

And when your manual dragging has made a mess, six layout algorithms are one click away: top-down hierarchical, left-right hierarchical, tier-layered, grid, radial and force-directed. Watching a diagram reorganise itself between them is genuinely the fastest way to find the view that makes a given system make sense.

 

 

 

 

 

Enhance, rebuild, and check for drift

Three buttons keep a diagram alive after the first generation.

Enhance is goal-directed AI refinement: tell it what to improve — “group these by tier”, “show the data flows more clearly” — and it revises the existing diagram while preserving what’s already correct, running through the same validation pass as a fresh generation.

Rebuild re-reads the live estate and regenerates. Generation runs as a background job, not a frozen browser tab: you get a phase and a percentage — scope → query → ai → save → done — so a big workload taking a couple of minutes looks like progress rather than a hang. Jobs are capped at three concurrent so a bulk rebuild can’t stampede your model provider.

Drift compares the diagram against live Azure on demand — the mechanics are in the next section, but it’s worth noting it’s right there in the toolbar, one click from the picture it’s checking.

Two more keep the diagram connected to the rest of the workbench. Ask AI puts a question box against this specific diagram, so “why is this Cosmos account reachable from the internet?” is answered with the architecture already in context. And Investigate hands the whole thing — diagram and its memory — straight into a Part 2 deep investigation, which is the loop this series has been building toward: the map you generated in ninety seconds becomes the context a war room reasons over.

Everything is undoable, and each diagram keeps an Activity log and a History of revisions, so an edit made in a hurry is never a one-way door.

 

 

Getting it back out again

A diagram trapped in a tool is a diagram that won’t be used, so export is deliberately broad:

• PNG and SVG for design docs, change requests and slide decks.


• Mermaid to paste straight into a README or a wiki — and it round-trips: you can import an existing Mermaid flowchart back onto the canvas.


• JSON for the full model, if you want to do something else with it entirely.


• Bicep and Terraform skeletons — scaffolding derived from the diagram. They’re a starting point, not a deployable module, and the product says so.

There’s also a Present mode that takes the diagram fullscreen, which turns out to be what people actually reach for in an architecture review.

Diagrams have a lifecycle — draft → in review → ready, plus archive — and can be organised into collections, so a tenant with sixty diagrams doesn’t become its own navigation problem. Every save snapshots a revision, and deletion is a recoverable Trash rather than an ending.

 

 

 

Honest about what it is

Two caveats the product is upfront about, and so should this post be.

The confidence value is declared by the model, not computed by the system. It’s a useful signal about how sure the model was, not an independent measurement of correctness. The thing you should actually trust is the structural guarantee underneath it: every node maps to a real ARM ID, because that part is enforced in code rather than requested in a prompt.

A first pass is a first draft. Inference from properties is very good at the relationships Azure records explicitly — network paths, hosting plans, private endpoints, disks — and weaker at the ones that only exist at runtime, like an app calling an external API by URL. That’s exactly why the canvas is editable and why Architecture Memory exists: the generated diagram gets you ninety percent of the way in ninety seconds, and you spend ten minutes adding what only your team knows.

Part three — Memory, drift, and the doc your on-call reads

Architecture Memory — the intent behind the diagram

A diagram tells you what is deployed. What it can’t carry is what your team intended — that the second region is deliberately warm-standby rather than half-finished, that the public IP is a known and accepted risk, that when this app misbehaves you check Front Door before you touch the database. Historically that knowledge lives in one senior engineer’s head and leaves when they do.

Architecture Memory is a structured document attached to each architecture, spanning 20 sections across six groups:

A brand-new memory is pre-seeded with the seven highest-signal sections rather than twenty empty boxes, and the AI will draft them from the live architecture for you to correct — which is a much easier job than writing from nothing. Every save snapshots a revision (capped at 50 per document, de-duplicated by content signature), so the design history is recoverable.

 

 

Where the two pillars snap together

Here’s the payoff, and it’s the reason Map is worth doing before Assess.

Architecture Memory is injected into the Part 2 War Room as expert context. When a deep investigation has to fit inside a prompt budget, the memory is trimmed by an explicit priority order — expected flow first, then diagnostic hints, known gaps, critical thresholds, security model, resiliency targets, dependencies, components, network topology, observability, known issues. Eleven sections, ranked by operational value, so the most useful knowledge is the last thing to fall out of the prompt rather than the first.

Which means the note you wrote in a calm Tuesday afternoon — “check Front Door health before you look at the database” — is what a specialist agent reads at 2 a.m. while you’re asleep. Documenting your architecture stops being a chore you do for auditors and becomes something that measurably improves the next incident.

Drift: when reality wanders off

Once you have a documented design and live inventory, comparing them costs almost nothing — so the workbench does it continuously.

Drift detection matches documented resources against live ones by ARM ID and sorts every resource into one of four states:

It produces a drift score — simply the share of resources that reconcile — and if a workload has no architecture at all, the score is null and everything live is flagged uncontrolled, which is itself a finding worth acting on.

live_uncontrolled is usually the column people stare at. That’s the resource somebody spun up in a hurry during an incident eight months ago that nobody has thought about since.

 

 

 

The Know-Me doc — and a refusal to make things up

Diagrams serve architects. On-call needs prose: what is this thing, who owns it, what’s the SLA, who do I wake up, and what usually breaks.

The workbench generates that Know-Me doc from the architecture and its memory — 13 sections covering the workload overview, the solution architecture, the Azure services and subscriptions in scope, diagnostics and first-look triage, critical thresholds and SLIs, resiliency and DR posture, known issues and proactive callouts, security posture, support and escalation handling, contacts, and data/compliance/cost notes.

The thirteenth section is the one I’d point a sceptic at, because it’s a list of everything the AI refused to invent.

The generator is explicitly forbidden from fabricating the facts that matter most: people, SLAs, RTO and RPO values, on-call rotations, customer names, subscription GUIDs, contract and schedule IDs. It doesn’t guess and it doesn’t produce a plausible-looking placeholder that reads like a fact. It emits a typed marker in the literal form ⟦TODO: | key=⟧, and every one of those markers is collected into that final checklist section for a human to complete. What Azure does know — subscriptions, regions, real scope — is auto-filled and labelled as platform-sourced, so you can see at a glance which facts came from the platform, which were AI-suggested and editable, and which are waiting on you.

Filling them in is deliberately low-friction. Fields render as the right control for their type — segmented buttons for small strict sets like Critical/High/Medium/Low, a typeahead combobox for larger sets like subscriptions or regions, a plain input for free text — and a Guided Fill mode walks you through every incomplete field one at a time, keyboard-driven, so completing a doc is a five-minute pass rather than an afternoon of hunting.

And the refusal is enforced at the door. A doc moves through draft → in review → published, and publishing is blocked until all five required groups have at least one real answer: escalation, resiliency, SLA, contract, and contacts. You cannot publish a runbook whose escalation path is still a placeholder. An on-call document that confidently states a fabricated RTO is worse than no document at all — it’s a document someone will believe at 3 a.m. The gate exists so nobody discovers the gap during an incident.

Finished docs export to Markdown or a branded PDF, support inline images, keep revisions, and go to a recoverable Trash rather than vanishing.

 

 

Part four — The Estate Graph

Zoom all the way out

Per-workload diagrams answer “how does this application hang together?” The Estate Graph answers the larger question: how does all of it hang together?

It assembles the whole tenant into one interactive graph — 15 node kinds and 14 edge kinds. Nodes run from the tenant connection through management groups, subscriptions and resource groups, down to resources, and across to the artifacts you’ve built: workloads, architectures, memories and assessment findings. Edges carry the structure (contains, member_of, belongs_to), the modelling relationships (models, documents, has_finding) and the dependency relationships (depends_on, connects_to, data_flow).

It’s workload-first by design. You navigate applications, with raw resources underneath, which is the opposite of how most inventory tools present a tenant and much closer to how teams actually think.

Five overlays, one map

Switch on an overlay and the same map answers a different question:

That’s the argument for a single graph over five separate dashboards: the cost hotspot and the coverage gap and the privileged principal are all the same node, and seeing them on one map is how you notice they’re related.

Because a tenant-wide graph can get genuinely enormous, everything is capped on purpose rather than allowed to melt the browser: findings collapse into a single “⚠ N findings” super-node past 18 per workload, expanding a group loads at most 400 resources, and the overlays are bounded too (12 privileged principals, 20 retirement items, 40 change events). You choose a layout — organic, hierarchy, breadthfirst or concentric — and it persists for your tenant.

Every node is a doorway

Select a node and the inspector opens a dossier: for a workload, its environment, criticality, resource count, linked architecture, risk score and findings; for a resource, its type, SKU, location, owner, cost and the workloads it belongs to; for an architecture, its state, AI confidence and how much of its memory is filled.

From there you can trace rather than just look — expand a node’s neighbours, highlight a blast radius, or ask for the path between two nodes. And the “open in” actions carry the workload context with you into Inventory, the architecture, its memory, an assessment run, Change Explorer, RBAC, Telemetry, Backup & DR — or straight into a Part 2 war-room investigation. You land somewhere useful, already scoped, instead of at the top of another dashboard.

 

 

 

Read-only, and why that’s a design constraint rather than a limitation

Everything in this post is a read path. Workloads, architectures, memories, Know-Me docs and the Estate Graph all write to the Azure Support Agent’s own storage — never to Azure. The reads themselves go straight to Azure Resource Graph and the ARM APIs.

That’s a deliberate boundary. Mapping is the activity you want to be able to run against production on a Friday afternoon without a change request, without a second pair of eyes, and without thinking twice. The moment mapping can mutate, it acquires a blast radius and people stop running it — which defeats the point. Writes exist elsewhere in the workbench (applying owner tags, for instance), and they’re approval-gated and audited when they do. They’re a later post.

And if you haven’t connected a tenant yet, demo mode seeds the whole pillar with realistic synthetic workloads, architectures and inventory, so you can walk the entire flow before pointing it at anything real.

How it’s judged

• Health scores are composite and explainable. Seven weighted signals, published bands, and an API that returns which signals contributed, which are missing, and the exact weights used.


• Unmeasured never masquerades as bad. Signals that haven’t been analyzed are excluded from the denominator rather than scored as zero, and the weights are yours to tune.


• Autopilot is review-before-apply. Proposals carry reasoning and confidence, and are never persisted without an explicit human save.


• Every node maps to a real resource. Model-emitted ARM IDs are validated against live inventory; duplicates collapse and orphaned edges are dropped before anything renders.


• Large estates degrade gracefully. Discovery caps, property budgets and graph caps are explicit and disclosed rather than silently sampling.


• The generator declines to invent. People, SLAs, RTO/RPO, contacts, GUIDs and contract IDs become explicit ⟦TODO⟧ markers, and publishing is blocked until all five required groups are genuinely complete.


• Drift is measured, not asserted. Documented and live inventory reconcile by ARM ID into four named states with a score you can track over time.


• Overlays reflect real data and deep links resolve. Cost, retirement, coverage, RBAC and change all read live sources, and every node opens the artifact behind it.


• Read-only throughout. Mapping your estate never changes it, and the Azure Support Agent runs in your own Azure Container App against Azure’s own APIs.

Try it yourself

If you’ve already deployed the Azure Support Agent, this is the fastest way to feel the difference — about ten minutes:

1. Run Autopilot against one subscription and accept a single proposed workload.


2. Hit Generate architecture and watch it assemble. Seeing a correct diagram of something you own build itself out of Azure Resource Graph is the moment this stops being abstract.


3. Open its Architecture Memory and write three honest sentences about how it’s supposed to work — the expected flow, one known gap, one diagnostic hint.


4. Now run a Part 2 deep investigation against that workload.

The difference between the answer you get in step 4 and the answer you’d have got before step 3 is the entire argument for this pillar. The map isn’t documentation you produce for someone else’s benefit; it’s context that makes every other answer better.

No tenant connected yet? Demo mode runs the same flow on synthetic data, with nothing to risk.

Next time — Part 4: Assess — coverage and your real posture. With the map in place, we go looking for trouble on purpose: Azure Monitor baseline alert coverage and whether the alerts you already have would actually fire, telemetry gaps, backup and DR posture with real costs attached, Well-Architected reviews at scale, FMEA risk registers, and who can do what across your estate — each judged against a versioned baseline, and each arriving with the infrastructure-as-code to close the gap.

It’s open source and free to run. Three ways to start, in rising order of commitment:

1. Explore demo mode — synthetic data, no connection required, nothing to risk.


2. Deploy to your tenant — one click to Azure Container Apps; private networking; your data never leaves.

 

 

Or main repository https://github.com/zmustafa/AzureSupportAgent