Episode Details

(00:00:00) The Power of Multi-Agent Systems
(00:00:32) The Limitations of Single-Agent Systems
(00:02:32) Introducing Multi-Agent Systems
(00:03:55) Roles and Responsibilities in Multi-Agent Systems
(00:04:47) Building with Azure AI Foundry and Semantic Kernel
(00:09:50) Demo Scenario 1: Device Cleanup in Intune
(00:13:38) Demo Scenario 2: Zero-Touch Onboarding
(00:17:17) Demo Scenario 3: Automated Security Hardening
(00:22:58) Best Practices for Multi-Agent Systems
(00:25:06) Closing Thoughts and Call to Action

You already know the meme: chatbots talk, agents act, multi-agent systems actually get stuff done.
If you’ve ever begged a bot to fix Intune and got a poem instead, this one’s for you. In this episode, we go full Netflix hands-on: you watch, you snack, I poke the dangerous Service Principal things so nobody nukes prod. We build a mini self-healing, governed multi-agent system using Azure AI Foundry + Semantic Kernel, wired into real enterprise surfaces:

• Intune
• Entra ID
• Microsoft Graph
• Azure Automation
• Log Analytics

We run one-agent vs multi-agent head-to-head on a real workflow: 12 minutes vs 3 minutes time-to-fix — with only my subscription credit on the line. You’ll see why one agent stalls while teams fly, and how to ship this pattern safely in your own tenant. 🔥 What You’ll Learn 1. Why a Single Agent Isn’t Enough in the Enterprise We start by tearing apart the “one giant agent” fantasy:

• Single agents are like gas-station Swiss Army knives: technically they have tools, practically they bend on the first real job.
• You stuff planning, reasoning, execution, approvals, and reporting into one prompt → context explodes, latency spikes, hallucinations creep in.
• One agent trying to:
  • Plan a change
  • Call Graph and Intune
  • Write remediation scripts
  • Request approvals
  • Verify results
  • Document everything

…is basically a help desk, change board, and postmortem crammed into one very tired intern. We break down what actually goes wrong:

• Context windows flooded with logs, policies, and MDM miscellany
• Important details get truncated or invented
• Token usage and costs balloon
• “Fix” attempts that quietly break other things (like deleting the resource instead of rotating a secret 😬)

Then we introduce the fix: Multi-agent = roles + boundaries + parallelism

• Planner focuses on intent & constraints
• Operator focuses on tools & execution
• Reviewer focuses on guardrails & approvals

Each agent gets a tight instruction set, minimal memory, and a focused toolset, passing around small structured messages, not a 50-page policy doc. 2. Multi-Agent Systems 101 (No Hype, Just The Pattern) We map out a clear, shippable mental model: think digital team, not one big brain. Roles:

• Planner — understands the goal, constraints, environment; outputs a stepwise plan with tool calls
• Operator — executes the plan via tools: Graph, Azure Automation, Functions, Logic Apps, etc.
• Reviewer — checks groundedness, scope, compliance, and safety before risky changes
• Messenger/Concierge — interacts with humans: approvals, status updates, and audit summaries

Core concepts:

• Tools = hands
  • REST APIs (Graph, internal services)
  • Azure Automation runbooks (device scripts, remediation)
  • Azure Functions & Logic Apps (glue & approvals)
  • RAG via Azure AI Search (curated knowledge, not random web junk)
• Memory = budget, not magic
  • Minimize per-agent context
  • Use external state (Search, state store, thread metadata)
  • Only pass what’s needed for the next decision
• Planning vs Execution
  • Planner decomposes → Operator calls tools → Reviewer checks