The Evolution: Static vs. Agentic
In Lab 1, we focused on the "Secure Foundation" (M365 Hardening). Now, we build the "Intelligent Engine."
Last verified: May 14, 2026. Model names and agent features change quickly. Treat this as an architecture pattern: use your organization’s approved LLM provider, log every tool call, and require human approval before high-risk identity or mailbox actions.
Most automation is Static:
If A happens, do B.
But enterprise operations are messy. A user ticket saying "I can't get into my email" could mean a forgotten password, a locked account, a conditional access block, or a deleted mailbox. A static bot fails here.
Agentic Automation is different:
If A happens, let the Bot analyze the context and decide if it needs to do B, C, or D.
The Architecture: The "Brain" and the "Hands"
To build an agent, you need two components:
- The Brain (Reasoning): An approved LLM or AI service that can understand complex instructions and propose decisions.
- The Hands (Tools): A set of APIs or scripts (via Power Automate or Python) that the brain can call to interact with the real world.
Phase 1: The Decision Logic (The Prompt)
The core of this lab is the System Prompt. We give the agent a "persona" and a set of "available tools."
You are an IT Operations Agent. Your goal is to triage incoming support tickets.
Tools available:
- [Check_Account_Status]: Checks if a user is locked in Entra ID.
- [Trigger_Password_Reset]: Sends a reset link to the user's secondary email.
- [Escalate_To_Human]: Creates a high-priority ticket for a technician.
Logic:
1. Analyze the user's message.
2. If they mention being "locked out," use [Check_Account_Status] first.
3. If the account is healthy but they forgot the password, use [Trigger_Password_Reset].Phase 2: Connecting the "Hands" (Power Automate)
We use Power Automate as the orchestration layer.
- Trigger: New email or ticket arrives.
- Action: Send the ticket text to the AI Agent (the Brain).
- The Decision: The AI returns a JSON object specifying which tool to use.
- The Execution: A switch case in Power Automate executes the specific sub-flow (the Hands), with guardrails for anything sensitive.
Safety Guardrails
Before letting an agent touch operations, add these controls:
- Human approval for sensitive actions: Password resets, mailbox changes, license changes, group membership changes, and account disablement should not be fully autonomous by default.
- Least-privilege tools: Each sub-flow should only have the permissions needed for that task.
- Audit logging: Store the ticket, model decision, selected tool, user approval, and execution result.
- Prompt-injection resistance: Treat user-submitted tickets as untrusted input. Do not let the ticket text override system instructions.
- Fallback path: If confidence is low or the account looks risky, escalate to a human.
Why This Matters for Operations
In my role as an Operations & Automation Specialist, I look for ways to scale human expertise. An agentic bot doesn't just "save time"—it reduces the cognitive load on the IT team.
Instead of a technician spending 10 minutes triaging a "I can't log in" ticket, the bot has already checked the logs, verified the account status, and either fixed it or provided the technician with a full diagnostic report.
Next Steps: Companion Walkthrough
If I publish a companion video for Lab 2, I’ll update this post with the current flow and the guardrails used in the demo. Until then, treat this article as the architecture blueprint rather than a copy/paste production runbook.
