Microsoft Smart DRI Agent: How Teams, Semantic Kernel and Azure AI Search Streamline Incident Response

To cut through that operational friction, engineers inside Microsoft Digital—the company's internal IT organization—and Microsoft HR teamed up to build an internal AI tool called the Smart DRI Agent. Detailed in an October 15, 2026 Microsoft Inside Track report by Alyse Maguire, the Microsoft Teams-based assistant uses Microsoft Semantic Kernel and Azure AI Search to pull telemetry, historical incident context, and troubleshooting steps into a single workspace for on-call engineers.

While the tool itself is an internal project rather than a commercial product external IT shops can download, its architecture—and the growing pains Microsoft hit while building it—offers a practical blueprint for enterprise engineering teams looking to build their own incident-response agents without automating bad habits.

The On-Call Bottleneck: Why Context Switching Kills MTTR​

At Microsoft, on-call production support revolves around the Designated Responsible Individual, or DRI. Rotating into the DRI seat means taking responsibility for investigating live-site incidents, monitoring service health, reviewing security tasks, and handling operational fires.

Before the Smart DRI Agent existed, Microsoft’s internal responders faced the exact same fragmentation that plagues most large enterprise IT departments. According to Payal Awasthi, a senior software engineer in Microsoft Digital, an engineer picking up a new ticket often had to elevate multiple production permissions before getting basic insight into what was broken.

At the same time, critical diagnostic material was scattered across disparate portals, dashboards, SharePoint sites, OneNote notebooks, and standalone troubleshooting guides. If an engineer was new to a service or rotating into an unfamiliar on-call shift, assembling that puzzle took even longer and often required tracking down a veteran engineer just to get oriented. In the scramble between browser tabs and permission prompts, important context routinely slipped through the cracks.

Section Summary:

• The Role: DRIs at Microsoft manage rotating 24/7 live-site monitoring, incident investigation, and security reviews.
• The Friction: Responders lost critical minutes elevating production permissions and hunting across SharePoint, OneNote, and multiple dashboards for basic context.
• The Goal: Consolidate incident data, telemetry, and runbooks into one interface so engineers can focus on remediation instead of search.

From Hackathon Prototype to 40+ Internal Teams​

Like many practical developer tools, the Smart DRI Agent started as a grassroots side project. Teams inside Microsoft Digital and Microsoft HR realized they were independently trying to solve the same on-call headaches and joined forces during a Microsoft hackathon. Engineers initially contributed to the prototype whenever they had spare capacity.

Once leadership saw the prototype's potential, the groups hit reset and formalized the effort. Sudhakar Sadasivuni, a principal group engineering manager in Microsoft Digital, noted that the team established formal goals and a 30-60-90-day plan to strip out service-specific assumptions and make the platform generic enough for any internal service team to onboard. Sadasivuni described the effort as an internal open-source project—meaning internal teams could contribute to and onboard the shared codebase, though Microsoft has not released an external repository or public software package.

An earlier Microsoft Inside Track report by Alex Fleck on the company's continuous improvement initiatives provides a snapshot of how the tool evolved on the Digital Workspace team. After conducting a Gemba walk—a structured process review to spot operational waste—that team ran a pilot of the Smart DRI Agent focusing on log summarization, error log correlation, automated status summaries, and AI-generated shift handover reports. During the first 30 days of that specific pilot, the agent provided insights on 101 out of 301 incidents, saving DRIs roughly 100 hours and correlating with a 40% improvement in a key network performance metric.

By October 2026, Microsoft reported much broader internal adoption across the company:

As a matter of journalistic transparency, it is worth noting that these figures come directly from Microsoft’s internal reporting rather than an independent third-party audit, and Microsoft does not publish the exact baseline calculations used to estimate the 600 monthly hours saved. Even so, the operational pattern is clear: shaving ten or fifteen minutes of log-gathering off thousands of tickets adds up quickly across forty engineering groups.

Section Summary:

• Origin: Merged from parallel efforts in Microsoft Digital and Microsoft HR during an internal hackathon.
• Growth: Transitioned via a 30-60-90-day plan into an internal open-source platform supporting more than 40 teams.
• Reported Impact: Microsoft estimates the agent saves 600 engineering hours per month across more than 7,800 interactions and nearly 6,000 proactive notifications.

Under the Hood: Semantic Kernel, Azure AI Search, and Teams​

For enterprise architects and Windows developers wondering how Microsoft wired this together, the technical stack relies on familiar Azure and Microsoft 365 building blocks rather than exotic custom infrastructure.

1. Microsoft Teams as the Single Pane of Glass​

Instead of building yet another web portal for engineers to bookmark and forget, the team embedded the Smart DRI Agent directly into Microsoft Teams. Because engineers already live in Teams during incident swarms, surfacing diagnostics and morning shift summaries inside the chat client eliminates portal switching.

2. Orchestration with Microsoft Semantic Kernel​

To handle diverse requests across different operational tools, the developers used Microsoft Semantic Kernel as the central orchestrator. Separate operational domains—such as incident management and Microsoft's internal Service 360 tool—are exposed as distinct sets of functions. When a DRI asks a question or an alert fires, Semantic Kernel evaluates the request and dynamically selects which domain functions to call. According to Lakshmi Kothamasu, a principal engineering manager in Microsoft Digital, this plugin-style architecture places no artificial limit on the number of backend services an engineer can query from a single prompt.

3. Azure AI Search Plus Custom Similarity Logic​

When a new incident lands, the agent checks whether the team has seen the problem before. It indexes historical incident records in Azure AI Search to retrieve similar past tickets. However, the engineering team hit a snag that will sound very familiar to anyone who has built a retrieval-augmented generation (RAG) pipeline: out-of-the-box search indexing didn't always return useful operational matches. Generic text similarity often struggles with noisy stack traces, terse ticket titles, and service-specific jargon. To fix this, Microsoft’s developers wrote custom similarity logic on top of Azure AI Search to evaluate incident patterns more accurately before handing the historical context to the DRI.

4. Automated Telemetry and Runbook Matching​

Alongside historical tickets, Bhupesh Guptha Muthiyalu, a principal engineering manager in Microsoft HR, explained that the agent connects directly to a service's telemetry to pull relevant traces, logs, and exceptions from the preceding few minutes. Using the incident's title, description, and telemetry data, the agent searches the team's troubleshooting guides, identifies matching failure patterns, and presents recommended diagnostic steps right alongside the raw data.

5. The Hard Lesson: Separating Configuration from Core Logic​

The biggest engineering hurdle wasn't the AI model—it was human organizational variety. Every service team at Microsoft ran its on-call rotation slightly differently and expected different formats for shift handoff reports.

In the first iteration, the developers hard-coded too much workflow behavior directly into the agent. When they interviewed prospective DRI teams to scale the tool, conflicting requirements piled up and stalled progress for two to three months. The breakthrough came when the developers refactored the system to strictly separate configuration from core orchestration logic. By allowing individual service teams to supply their own templates for workflows like DRI handoff reporting, the core agent stayed clean while accommodating dozens of different team cultures.

Section Summary:

• Interface: Delivered natively inside Microsoft Teams for both interactive chat queries and proactive morning summaries.
• Orchestration: Uses Microsoft Semantic Kernel to route queries across distinct function sets like incident management and Service 360.
• Retrieval: Combines Azure AI Search with custom similarity logic to match live incidents against historical tickets and runbooks, while pulling recent logs, traces, and exceptions.
• Architecture Lesson: Two to three months of scaling friction were solved by ripping out hard-coded workflows and letting teams onboard via customizable templates and configuration files.

What Comes Next—and What Remains Unanswered​

Currently, the Smart DRI Agent acts strictly as an advisor and context aggregator. In future iterations, Microsoft’s developers hope to give the agent active remediation capabilities so it can mitigate certain routine incidents—while keeping the human DRI in the loop to review and sign off on every action before execution. (In adjacent parts of Microsoft Digital, such as network operations, tools like the internal Falcon Agent already handle automated troubleshooting and remediation for known, repeatable scenarios like access-point-down tickets.)

At the same time, reading Microsoft's engineering account with a critical eye highlights a few important technical realities that enterprise IT leaders should keep in mind:

• Permission Boundaries and Security Governance: Awasthi noted that one major reason for building the agent was to spare DRIs from manually elevating production permissions just to gain initial insight into an incident. However, Microsoft’s post does not detail the underlying security architecture or identity model that governs how the agent itself accesses production telemetry, or how role-based access control (RBAC) prevents an unauthorized user in Teams from querying sensitive logs. Any enterprise replicating this pattern will need strict Entra ID governance and least-privilege service principals around those telemetry plugins.
• Culture Before Compute: As Sadasivuni bluntly put it in Microsoft's report, without a strong live-site culture where production reliability is already a priority, an AI agent is "an unnecessary use of computing and artificial intelligence." An AI assistant can summarize a troubleshooting guide in seconds, but if your team's OneNote runbooks are three years out of date, the agent will only deliver bad advice faster.

Actionable Playbook: Building Your Own Incident Assistant​

If your engineering or IT operations team is looking to build a similar assistant using Semantic Kernel, Azure AI Search, and Microsoft Teams, Microsoft’s internal rollout offers a clear, step-by-step roadmap:

1. Audit the Workflow Before Writing Code ("CI Before AI"): Conduct a walk-through of your on-call rotation. Identify exactly where responders burn time gathering context, where documentation is fragmented, and which repetitive steps happen on every ticket. Do not automate broken processes.
2. Unify Your Knowledge Sources: Connect the agent to the actual systems engineers rely on—ticketing platforms, recent telemetry logs/exceptions, and runbook repositories—so context arrives in one place.
3. Support Both Push and Pull Workflows: Design the agent to answer ad-hoc diagnostic questions in chat while also pushing proactive notifications when an incident triggers or when a morning shift handoff begins.
4. Template Everything: Never hard-code team-specific incident formats or handoff report structures into your core orchestrator. Keep your Semantic Kernel functions modular and let individual teams bring their own configuration templates.
5. Test Retrieval Against Real Outages: Do not trust default vector or keyword indexing on raw incident tickets. Test your Azure AI Search retrieval against real historical outages and layer on custom domain scoring when generic search misses the mark.
6. Keep Humans in Command: Treat the agent as a force multiplier for the on-call engineer, not a replacement for operational ownership. Even as you experiment with automated mitigation, require explicit human sign-off on production changes.

Have you started wiring AI agents into your live-site or helpdesk workflows, or are you still fighting to get your team's documentation out of scattered OneNote files first? Share your experiences in the WindowsForum community threads on Azure administration and enterprise IT operations.