In Part 1 we made the case for an operations copilot that runs in your own tenant and reasons over live evidence through Azure’s own APIs. This post opens the first pillar — Converse — and goes inside the two features that make it real: a chat that actually queries your estate and shows its work, and the marquee act, a War Room of specialist agents that fan out in parallel to turn “why is the site throwing 5xx?” into a ranked, validated root cause. Let’s watch it work.

---

Every incident starts the same way: a question you can’t answer fast enough. The signal you need is almost always already in Azure — the metrics are in Azure Monitor, the topology is in Azure Resource Graph, the recent changes are in the activity log, the expiring secret is in Key Vault. The hard part at 2 a.m. is that the answer is spread across a dozen surfaces and one pair of hands. The Converse pillar is about collapsing that distance: you ask in plain English, and the agent does the querying, correlating and explaining for you — against your live estate, not a training-data guess about how Azure works.

First, a chat that reads your tenant

Before we get to the marquee demo, it’s worth being precise about what “chat” means here, because it is not a toy wrapped around a language model. When you ask “Why is the checkout API throwing 5xx?”, the agent answers by doing the work — it reaches into your subscription through the official Azure MCP server (and, when you’ve connected it, a Microsoft Graph / Entra ID MCP server), runs read-only queries against Azure Resource Graph, Monitor and the rest, and streams the whole thing back to you as it goes.

That streaming detail matters more than it sounds. Answers arrive over Server-Sent Events, so you don’t stare at a spinner — you watch a live timeline assemble: the model’s reasoning as it narrates its plan, then each tool call it makes (the query it ran, how long it took, and a one-line summary of what came back), step by step, until the final answer lands. When it’s done, that timeline doesn’t vanish. It’s persisted with the message, so if you reload the page a week later the reasoning, every tool call, and any screenshots you pasted in are all still there. Nothing about how the agent reached its conclusion is thrown away — which is exactly what you want when you have to defend that conclusion to a change board later.

A few things make it comfortable to live in day-to-day:

• Multiple sessions, isolated context. Keep three investigations open at once; each chat carries its own model choice, its own Azure connection, and its own optional workload scope.
• Vision input. Paste a screenshot of a failing blade or an error toast; it’s part of the question and it’s saved with the turn.
• Starter suggestions. Not sure how to phrase it? Curated prompts, grouped by domain — connectivity, identity, security, compute, performance, cost — get you moving with one click.
• Cancel-safe turns. This is the quietly brilliant part. Hit Stop, or just close the tab, and the work keeps running server-side. The turn is decoupled from your browser connection entirely: it finishes, saves its partial or full answer and its timeline, and is waiting for you when you come back. Reconnect and the stream replays what you missed and picks up live. Your investigation is never hostage to a flaky Wi-Fi connection or an accidental refresh. In Deep mode it goes one further: the investigation tree is checkpointed to the database as it builds, so even a mid-flight reconnect picks up every hypothesis already resolved.

That last point is the difference between a demo and a tool you’d actually trust mid-incident. The work is durable because the evidence is durable.

Then, when it’s genuinely hard: the War Room

A single model narrating one line of investigation is perfect for “which NSG is blocking this port?” But real incidents are rarely one line of investigation — they’re five plausible theories that each need chasing before you can rule them out. That’s more parallel work than one reasoning thread can do well, and it’s exactly where a single-threaded chatbot starts guessing.

So you flip on Deep mode, and a War Room convenes.

Instead of one generalist, the agent fields a bench of eight specialists, each with its own lens on the estate:

The point of the bench isn’t role-play — it’s parallelism with focus. Several specialists research at the same time, each pulling live evidence for its own domain, so a broad question gets broad coverage in the time a single thread would spend on one branch. Here’s what that looks like mid-flight — eight specialists working the estate at the same moment, each on its own lane:

You pick the bench — or let it pick for you

You’re not stuck with all eight specialists on every question. Before a Deep investigation runs you can hand-pick the bench — just Networking and Identity for a connectivity puzzle, say — or let the agent suggest the roster for you. The suggestion isn’t a black box: it proposes a recommended set with a one-line reason for each pick (“Identity — the error is a 403 and the app uses a managed identity”), and if the model is ever unsure it falls back to deterministic keyword matching, so you always get a sensible default. Pick none and it staffs the room itself.

Why bother narrowing it? Focus. A DNS question doesn’t need the Cost specialist spending tool calls on spend anomalies. A tighter bench means less noise in the tree, a faster answer and lower token cost — without giving up the parallelism that makes the War Room worth it in the first place.

How an investigation actually unfolds

Under the hood the War Room runs a disciplined, four-phase play — and because it streams the whole way, you watch each phase happen rather than waiting for a black-box verdict:

1. Incident research. The agent spends a bounded burst of read-only tool calls building context on the live estate, then proposes a short slate of two to three distinct hypotheses, each attributed to the specialist best suited to test it. No fishing expeditions — the work is time- and iteration-boxed so it converges instead of wandering.
2. Hypotheses formation. The candidate root causes are pinned down as a clean set — parallel theories, not a single lucky guess — ready to be tested independently.
3. Validating hypotheses. Now the specialists go to work, in parallel, each running its own read-only investigation to either confirm or kill its assigned theory. Every hypothesis gets a verdict — validated, invalidated, or inconclusive — backed by a paragraph of specific evidence. A theory that survives can spawn one deeper sub-hypothesis, so the investigation drills down where the evidence leads and drops the dead ends. The result is a compact hypothesis tree (a couple of levels deep, deliberately capped so it stays readable) that records not just what was true but what was checked and ruled out.
4. Conclusion. With the tree resolved, the agent streams a plain-English answer — the root cause, the evidence chain that proves it, a severity, and concrete next actions — and attaches a confidence score. That score is computed, not asserted: three quarters of it comes from how the strongest hypothesis resolved and one quarter from how the whole slate resolved, so one clean validation outranks three shrugs, and an invalidated theory contributes nothing. A single validated root cause reads very differently from three inconclusive maybes, and the number says so.

Two design choices keep that four-phase play fast and honest rather than open-ended:

It’s boxed, not boundless. Every phase carries both an iteration limit and a wall-clock budget, each agent’s tool calls fan out only so wide, and the hypothesis tree is hard-capped in depth, breadth and total nodes. That’s deliberate: an investigation that can run forever is one that runs up a bill and wanders. The budgets force it to spend its evidence-gathering where it counts and then converge — you get an answer in about a minute and a half, not a research project.

Those aren’t vibes; they’re constants. The guardrails, concretely:

Read that table as a cost control as much as a latency one. A wide parallel search across a live tenant is exactly the kind of thing that quietly burns tokens and API quota, so the ceilings are part of the product, not a tuning afterthought.

Fast where it’s cheap, strong where it counts. The broad research sweep and the parallel hypothesis validation can run on a fast, inexpensive model, while the final conclusion — the part you actually read and act on — is always written by your strongest configured model. You get the breadth of a wide parallel search without paying premium-model rates for every intermediate tool call. The fast tier is opt-in: name a cheaper provider and model for the intermediate phases and they’re used automatically; leave it unset and the whole investigation runs on your primary model.

Ninety seconds after you asked, you have a conclusion rather than a hunch. Here is that exact claim, unedited, against a live tenant: one in five requests is failing with a 5xx and nothing was deployed. The room convenes, eight specialists fan out, and the verdict comes back that nothing is broken at all — the 5xx responses are being minted by the Container Apps ingress in front of an app pinned to a single replica, while the loud suspects (crash loop, autoscale churn, database exhaustion, storage) are each cleared with a number attached. And the whole thing — every hypothesis, its verdict, its evidence, the specialist who tested it — is saved as a navigable hypothesis tree attached to the chat. The next person on call doesn’t start from zero; they start from your investigation.

The rest of this post is about how that happened — and there are three more recorded runs further down, including one with no incident at all.

Specialists don’t just read metrics — they run real diagnostics

It’s tempting to picture the bench as eight things running Resource Graph queries. They do that, but the more interesting part is that a specialist can reach for higher-order diagnostic tools mid-investigation — the same ones a senior engineer would open — all still strictly read-only:

• Performance Profiler. A specialist can launch an Azure Monitor-threshold performance profile on a workload and fold the resulting scorecard and ranked bottlenecks straight into the evidence, rather than eyeballing raw metric charts.
• Access and ownership lookups. “Who can actually reach this resource?” and “who owns it?” are answered from the workbench’s cached RBAC and ownership scans — real least-privilege evidence, without hammering live Azure mid-incident.
• In-guest sandbox checks. Where a workload has onboarded sandbox VMs and you have the permission, a specialist can run read-only in-guest diagnostics — resolve a DNS name from inside the subnet, test a connection — the checks you’d normally SSH in to run by hand.

The point is that the War Room investigates with the same toolbox you would, only in parallel and without the tab-hopping. And because Deep mode is read-only end to end, none of those tools can change a thing — a profiler runs, a VM command reads, but nothing mutates your estate.

Two investigations from the field

The single-replica case above is a clean one-liner once you see it. The real value of the War Room shows up when the obvious suspect is innocent and the truth is hiding one layer over. The next two cases are composites — teaching examples assembled from the shape of incidents I’ve worked, not transcripts of a single run — chosen because they show that pattern better than any one real investigation does. (If you want unedited runs, they’re in the section right after this one.) In both, notice the pattern: every signal was already in Azure. The win isn’t new data; it’s several specialists correlating across domains at once, and a tree that records what got ruled out, not just what was true.

Investigation 1 — “The database is slow” (that isn’t the database)

A checkout API starts returning intermittent 500s and stalling under peak load. On-call’s gut says the SQL database is maxed out — so that’s the first thing the War Room checks, and it’s the first thing it rules out. The symptom points at the data layer; the cause is one layer over, and it only shows itself under load, which is exactly why a quiet repro never reproduces it.

The conclusion streams back in plain English: the app is exhausting its SNAT ports because it opens a new outbound connection per request instead of pooling them — so under load it simply runs out of source ports and requests start failing. The database was never the problem. Fixes follow, ranked: enable connection pooling in the app, add a NAT Gateway for outbound scale, or move SQL behind a private endpoint so those calls don’t consume SNAT at all. Confidence: high — one cleanly validated chain, and the loud suspect explicitly cleared.

Here’s the part worth sitting with: every number in that table lived in Azure Monitor the whole time. What was missing at 2 a.m. wasn’t data — it was someone with the bandwidth to check the data, the compute and the networking layers simultaneously and notice that the SNAT ceiling, not the DB, lined up with the failures. That correlation is the whole job, and it’s what the War Room does in parallel.

Investigation 2 — “Random 403s after a harmless change”

Overnight, roughly 5% of requests to an internal API start returning 403 Forbidden. It’s intermittent, and it only hits some instances — the classic “works on my pod” ghost that resists every local repro. A 403 screams identity, so that’s where a single-thread chatbot would dig in and stay. The War Room checks identity too — and clears it in the first pass.

The root cause: a private-endpoint rollout the day before left one spoke VNet unlinked to the new Private DNS zone. Instances in that subnet keep resolving Key Vault and Storage to their public endpoints, and the resource firewall — correctly — denies them. Everyone else is fine, which is why it looked random. The fix is a single missing VNet link. Confidence: high — a change correlated to the onset, and subnet-precise evidence tying the 403s to the gap.

This is the investigation that takes a human an hour of cross-referencing an activity log against a network diagram. In the War Room the Monitoring specialist surfaced the suspicious change while the Networking specialist proved the DNS gap — at the same time — and the tree shows the two innocent identity and security theories that got cleared along the way, so nobody re-litigates them later.

It’s also a preview of where this series goes. That “intended topology: all spokes linked” is exactly the kind of fact the workbench remembers as Architecture Memory (Part 3), the missing link is the sort of thing drift detection flags before it pages anyone, and the “what changed last night” answer is Change Explorer doing in one query what used to be an hour of log archaeology (Part 5).

Four real investigations, recorded end to end

The two cases above are composites. These four are not — they are unedited screen recordings of the workbench running against a live Azure tenant, captured in one sitting. Each clip starts on an empty chat and runs the whole way through: scoping to a workload, switching the turn to Deep investigation, typing the question, the war room assembling, All Hands On Deck, the launch, the specialists working in parallel, and the written verdict at the end. Nothing is sped up beyond playback rate and nothing is cut.

You’ve already seen the first one — the 5xx run at the top of this post. Here’s what it actually concluded, and then three more.

1. “One in five requests is failing and nothing was deployed”

The question in the title of this post, asked verbatim: roughly one in five requests to the azsupagent app fails with a 5xx while other users see no problem at all; nothing was deployed.

The verdict is the interesting part, because the answer is nothing is broken. There is no server-side fault at all — the 5xx responses are generated at the Container Apps ingress, in front of the app, because the app is pinned to a single replica (min = max = 1, zero restarts all day). Concurrent requests beyond that one instance’s capacity get 502/503/504 while requests already in flight on the same replica finish normally — which is exactly the “one in five fails, the rest are fine at the same moment” shape. Crucially, the loud suspects are cleared with evidence, not skipped: no crash loop (replica count flat at 1.00, restart count 0), no autoscale churn, no Postgres exhaustion (8.88 active connections, 0 failed, CPU 8.7%), no storage dependency (100% availability across 24h).

(Recording at the top of this post.)

2. “It’s slow at peak but the database dashboards look fine”

Different symptom, different specialists leading, same underlying cause as the run above — which is a good demonstration that the conclusion follows the evidence rather than the phrasing of the question. Replica count is pinned at 1.00/1.00 across the full seven-day window, so at peak the requests queue in the ingress buffer. That queueing adds seconds of latency that never appears as CPU, memory or database pressure, which is precisely why the DB dashboards look clean and why nobody can reproduce it off-peak.

Note that the database is actively disproven rather than merely unexamined: disk_queue_depth is 0 in every one of 96 buckets, peak IOPS is 4 out of a provisioned 240, and active connections peak at 15 with zero failures. That distinction — invalidated vs. not checked — is the whole argument for the hypothesis tree.

3. “What changed in the last 48 hours, and could any of it hurt me?”

This one shows the War Room used as a change-risk tool rather than an incident tool, and it found something more uncomfortable than a bad deployment. The riskiest change in the window was not made by a human at all: a service principal holding Contributor at the tenant root management group created a new, undocumented action group. The object it created is benign in content — email and SMS only, no webhook — so alerting was never broken. The identity is the finding: an unowned, unattributed non-human principal with tenant-wide write authority and root-scope policy rights.

The secondary finding is independent and equally unglamorous: shared storage account keys were retrieved three times in the small hours on an account that still permits shared-key auth, accepts TLS 1.0, and has no network restrictions at all. Meanwhile the five human container app deployments in the same window are explicitly cleared of causing instability.

4. “No incident — just tell me what breaks first”

The last one is the proactive case, and it’s the one I’d actually run on a Friday afternoon. No symptom, no page, no incident: just audit this workload end to end and tell me what fails first, how bad the blast radius is, and the single highest-value fix this week.

The answer is the PostgreSQL flexible server, and the audit is specific about why: HA disabled, a single primary pinned to one availability zone, zero read replicas, geo-redundant backup disabled, seven-day retention, and storage auto-grow off. A zone outage — or an ordinary planned maintenance event — takes it fully offline with no failover target and nothing to geo-restore from, so the blast radius is a 100% workload outage with recovery bounded by manual restore time. It also flags something no single-resource check would catch: the database is the only resource in one region while the entire rest of the workload sits in another, so every data path already leaves the app’s region for zero resilience benefit.

Scoped to the workload, scoped to the tenant

A War Room investigation doesn’t have to boil the ocean. Point it at a Workload and it’s constrained to that application’s resources — its subscriptions, resource groups and resource IDs — so it reasons about the thing you care about instead of wandering the whole estate. And because the workbench is multi-tenant aware, every investigation carries its tenant and connection context, so each tool call targets the right subscription in the right directory. One operator can run investigations across several customers’ tenants from the same workbench without the signals ever crossing.

You don’t have to start in the chat

Most investigations don’t begin with someone typing a question — they begin somewhere else in the workbench noticing something is off. So the War Room is wired to be handed off to. When a proactive feature surfaces a risk, it can open a Deep investigation pre-loaded with the right workload and a ready-made prompt:

• Backup/DR coverage finds a resource with no protection → “investigate this gap.”
• Change Explorer flags a risky change → “investigate this change and its blast radius.”
• Performance Profiler spots a metric pressing against its Azure Monitor threshold → “why is this the binding bottleneck?”
• Retirement Radar finds a workload in the blast radius of an upcoming Azure retirement → “investigate this impacted workload.”
• Telemetry Intelligence sees a failure spike on an operation → “investigate this spike.”
• Architecture Memory opens the War Room with that architecture’s memory already attached.
• Identity findings and workload cards stage a scoped chat the same way — the workload card going straight into a deep reliability review.

Each one hands the War Room its context on a plate: deep mode on, the right workload selected, the prompt already written, the recommended bench loaded. What it deliberately does not do is start investigating. Every hand-off stops at the specialist-selection gate — nothing is dispatched until you click Launch. A dashboard can stage an investigation; only a person starts one.

There’s a durable twist worth stealing, too. A browser hand-off is one-shot — it dies on a refresh — so as the War Room opens it mirrors that context into a server-side Case File, reusing the workload’s already-open case (appending a note) instead of piling up duplicates. The investigation is a chat; the case is the record that outlives it.

A hand-off arrives fully staged — deep mode on, workload scoped, prompt written, bench loaded:

And then it stops, deliberately, at the gate and waits for a human:

From one workload to the whole fleet

The same machinery scales past a single incident. Select a handful of workloads in the fleet view, hit Deep review, and the workbench spins up one investigation per workload — its own chat, titled for the workload, the full eight-specialist bench, and a shared reliability brief: review this workload across networking, identity, compute, storage, security, monitoring and cost, and name the top risk. A whole portfolio gets swept for latent risk in one pass instead of you babysitting workloads one at a time.

It’s throttled on purpose. A batch is capped, and the launches go out through a small concurrency gate rather than all at once — twenty simultaneous eight-specialist investigations would stampede any model provider’s rate limits, and an ops tool that DDoSes your own AI quota isn’t much of an ops tool. Each workload comes back with its own tree, root cause and confidence, so you can triage the fleet by what the evidence actually says. It’s the difference between reacting to the workload that paged you and proactively asking all of them “is anything wrong?” — and it’s the bridge to Mission Control and scheduled automations later in the series (Part 5).

It starts where you’d expect — the fleet view, with the workloads you care about selected:

What comes out: severity, confidence, and next steps

An investigation isn’t just a wall of text — it resolves into a structured result you can route and reuse: a stated root cause and summary, a severity (info, warning, error or critical), the evidence chain behind the verdict, and a ranked list of next actions. Both lists are capped, so what you get is a shortlist to act on rather than a transcript to wade through. On top sits the confidence score from earlier — three parts strongest-hypothesis, one part whole-slate — so three inconclusive maybes score low and look exactly as shaky as they are. Because the shape is structured, the same result feeds a Case File, a ticket, or the next investigation without anyone re-typing it.

Those next actions can include the precise commands to fix the problem — but this is still the Converse pillar, so they stay proposal-first. The War Room tells you what it would do and why; actually doing it is the approval-gated territory of the Act pillar (Part 5). Nothing runs behind your back.

Grounded, not guessed

It’s worth saying plainly why this is trustworthy, because “AI incident response” can mean a lot of hand-wavy things. Every phase here runs against live Azure evidence through MCP tools that are read-only by default — the agent is investigating, not changing anything. Each tool call and its result is captured in the timeline, so the conclusion is backed by a visible trail of exactly which resources were queried and what they returned. Hypotheses that the evidence contradicts are marked invalidated and kept in the tree rather than quietly dropped — the record shows the roads not taken. That read-only discipline holds even for the heavier tools: the performance profiler reads, the sandbox-VM checks read, and any write-classified tool is filtered out of the toolset the moment Deep mode starts — an investigation is structurally incapable of mutating your estate. This is the same grounding discipline the whole product is built on, and Part 6 is devoted to it in full.

It gets smarter about your estate over time

There’s one more piece that turns a good investigation into an institutional one. Each architecture you’ve mapped can carry an Architecture Memory — the intended design, the security model, known gaps, diagnostic hints — and that context is injected into every phase of an investigation as expert background. So the War Room doesn’t just know generic Azure; it knows this workload’s quirks.

And the loop closes: when an investigation nails a root cause, you can save that RCA back into the architecture’s Memory with a click. The next time something goes sideways on the same workload, the agent recalls what happened last time. Your incidents stop being disposable and start compounding into knowledge — the tribal wisdom that usually lives in one senior engineer’s head, captured where the whole team can reuse it.

And a saved RCA isn’t a dead note. It carries its confidence, it’s de-duplicated against the exact investigation it came from (save it twice and you still have one entry), and it lands in the memory’s known-issues section — the section that gets injected first when context has to be trimmed to fit. Your estate quietly accumulates its own case law, and the most expensively-learned facts are the last ones to fall out of the prompt. When you want a finding to leave the workbench entirely, one click escalates an investigation into a tracked Case that back-references the exact chat and message. And every Deep investigation you’ve run is kept in a searchable history, each with a digest — root cause, hypothesis counts, confidence — and its full, pinnable tree one click away.

The whole learning loop is one button at the bottom of a finished investigation:

…and the finding reappears in the architecture’s known-issues section, ready to be injected into the next investigation on that workload:

Point it at almost anything

Root-causing a 5xx is the headline, but the same parallel-specialist machinery answers a much wider range of questions. A sampling of what people point the War Room at:

• Proactive audits — “check every NSG for 0.0.0.0/0 rules” (Security & Exposure).
• Change correlation — “did last night’s change cause this?” (Monitoring & Logs).
• Retirement impact — “which workloads does this upcoming retirement hit?” (Reliability).
• Cost spikes — “why did this subscription jump 30% this month?” (Cost & Governance).
• Performance — “what’s the binding bottleneck on this workload?” (Reliability & Performance).
• Security posture — “is any storage account publicly reachable?” (Security & Exposure).
• Connectivity — “why can’t this subnet reach that private endpoint?” (Networking).
• Governance — “is everything tagged to our taxonomy?” (Cost & Governance).

Same four phases, same read-only discipline, same navigable tree — pointed at whatever question you have this week.

How it’s judged

Every post in this series ends with the same honesty check — how you’d know the feature is actually doing its job, not just demoing well:

• Every answer shows its work. Each turn carries a visible reasoning + tool-call timeline; the conclusion is traceable to the exact Azure queries behind it.
• Hypotheses are validated against live evidence. The tree records what was checked, what was confirmed, and what was ruled out — each verdict tied to specific evidence.
• Confidence is earned, not asserted. The score is computed from how cleanly the hypotheses resolved — weighted toward the strongest one — so a shaky conclusion looks shaky.
• Read-only by default. The whole investigation runs against your estate without changing a thing; any write stays proposal-first and approval-gated.
• Nothing launches itself. Dashboards can stage an investigation with full context, but specialists are only ever dispatched when a human clicks Launch.
• Turns are durable. Cancel a turn or close the tab and the work continues server-side and is saved — evidence and all — so nothing is lost.
• You choose the bench, or the AI suggests it. A focused roster means less noise and lower cost without losing parallel coverage.
• Bounded by design. Published caps on iterations, wall-clock time, tree size and parallelism force convergence, so it lands an answer instead of wandering — and can’t quietly run up a bill.
• Real diagnostics, still read-only. Performance profiles, access lookups and in-guest checks all run without the power to change anything.
• Reusable output. Every investigation resolves to severity, confidence and next actions — escalatable to a Case and recalled on the next incident.

Try it yourself

If you deployed the workbench after Part 1, open a chat, ask it something real about your estate, and watch the timeline build. Then toggle Deep mode on a genuinely thorny question and let the War Room run — the hypothesis tree is the single best way to feel what an AI ops workbench does that a chatbot can’t. No live tenant yet? Demo mode runs the same experience on synthetic data, with nothing to risk.

Next time — Part 3: Map your estate — from proliferation to a living picture. The War Room is only as sharp as its understanding of what’s deployed, so next we turn resource proliferation into something you can reason about: Workloads with explainable health scores, Autopilot that proposes them for you, live architecture diagrams reverse-engineered from what’s actually running, the Architecture Memory you just saw feeding investigations, and the whole-tenant Estate Graph. Mapping is where “proactive” gets its eyes.