From incident alerts
to informed action

Microsoft gave its agent a clear job

Microsoft recently described Smart DRI, a Teams-based agent that brings incident information, telemetry and troubleshooting guidance to on-call engineers—the designated responsible individuals, or DRIs.[1]

An incident is a disruption to a production service: requests fail, an application becomes unavailable, or performance deteriorates. The responsible engineer must establish what is affected and decide how to respond, often while colleagues and customers are waiting.

Results reported by Microsoft Inside Track · October 15, 2026. The time-saving figure is Microsoft’s monthly estimate.

This is a compelling deployment because it gives assistance a clear place in an existing responsibility. The engineer has a problem to resolve, a working environment and a reason to return. Our reading is that this combination makes operational context a valuable starting point for enterprise agents.

The first report is only part of the problem

Microsoft describes context scattered across portals and documents, with production permissions adding friction to investigation.[1] The engineering question is how to assemble enough relevant evidence for the next decision.

Consider an illustrative incident used throughout this article: an employee cannot submit an order because the application times out. They know the task and the symptom. A service engineer needs the request path, dependency health and recent changes; an operations owner needs the extent of the disruption.

A useful briefing distinguishes observations from hypotheses. A release just before the timeout suggests a line of investigation. Comparing affected requests with unchanged instances helps test it. That distinction matters: a confident explanation can send a response team in the wrong direction if its evidence is weak.

Reuse needs domain judgment and team configuration

Smart DRI uses Semantic Kernel to orchestrate functions across operational domains.[1]

That orchestration sits between two engineering responsibilities: finding evidence that applies to this situation and fitting the response to the team’s operating process. A useful result depends on both.

For the timeout example, matching the error message is a starting point. The service version, dependency and environment determine whether a previous remedy is applicable. Search ranking supplies candidates; the workflow must establish what they justify. Azure AI Search supports keyword and vector retrieval with additional ranking options.[2]

Tool boundaries matter too. Semantic Kernel plugins expose operational functions, and invocation filters can inspect or control calls.[3][5] We would require a telemetry query to return its scope and time window, and distinguish no matching records from denied access or retrieval failure. Each result changes what the engineer can conclude.

Humani OS applies the same context-first principle to a broader unit of work: the managed task. The following sections connect three lessons from Microsoft’s case to our approach to execution, enterprise customization and ongoing improvement.

Give every enterprise its own operating rules

Microsoft made Smart DRI reusable by separating configuration from core logic and letting teams supply reporting templates.[1] Our reading is that enterprise fit belongs in the product’s configuration model.

Humani takes that principle into the customer’s operating process. In our proposed deployment, a team would configure its evidence sources and report views, alongside its permitted actions, decision owners and completion rules. The aim is a workflow that fits how this enterprise actually gets work done.

For an internal order-entry service, closure might require a successful test submission and operations review. A payment service could need transaction reconciliation and a separate financial approver. Those differences belong in connectors, decision rules and verification steps as well as report templates.

These views illustrate the presentation layer of that customization. Underneath, one versioned task record links the evidence, decisions and current state. Templates select permitted fields for their audience, so a technical investigation and a business update can stay aligned as work changes.

The implementation scope stays concrete: begin with one service and one permitted response, agree its escalation path, and test its exceptions. A second team can reuse the task structure while supplying its own systems, authority and outcome checks.

Turn case-specific tuning into an operating discipline

Microsoft improved incident retrieval with custom similarity logic after indexing alone produced inadequate matches.[1] That is a useful example of improving the component responsible for a failure.

Humani’s configure–deploy–observe–improve lifecycle extends that discipline across the workflow. In this application, task records would help distinguish a retrieval problem from a decision error or an incomplete recovery check, then direct the next version toward the right change.

Version the change and evaluate it against cases with known expected decisions, using only evidence available at that point in the incident. Keep the acceptance criteria stable for the comparison. A revised evaluator needs its own review; a higher score should reflect better work under the same standard.

For a first rollout, track verified completion, human handling time and time from detection to verified recovery. Include escalated and unfinished cases, and compare similar service scope and severity. These measures help the owner decide which response to expand next.

Smart DRI gives this direction a concrete operational reference; Humani’s proposition is to make the approach reusable across business work. A supplier exception or invoice discrepancy needs its own evidence, authority and completion rules. The shared task structure provides a foundation for adding those workflows to an AI workforce the enterprise can operate and improve.