Microsoft · Incident response
What would make an AI agent worth preparing, and safe to rely on?
Designing the path from service knowledge to trustworthy incident guidance.
- Role
- Lead designer for agent management, partner on agent onboarding
- Partners
- Product management, engineering, research
- Timeline
- 2026
- Status
- Version 1 shipped in 2026, version 2 in progress
An incident responder doesn’t need another answer just because an AI system can produce one. They need help that fits the problem in front of them, shows enough evidence to judge it, and makes the next step clearer.
Behind that help is a team doing a different job. Someone has to supply the service knowledge, decide where the agent applies, test changes and keep the guidance current. Before relying on an agent, that team needs answers to four questions:
I led design for the experience service teams use to manage agents and their skills, and partnered across teams on onboarding and testing for a built-in troubleshooting agent. I didn’t design the agent’s reasoning or the report responders see.
When AI help becomes another job
The risk wasn’t that the agent would be hard to find. It was that preparing and trusting it would cost more than it gave back, on both sides of the exchange.
For responders, service knowledge is spread across people, documentation and diagnostic tools. AI could assemble it, but it could also hand them one more thing to verify while the response is already moving. For service teams, the work happens before and between incidents, and it never really ends. They have to bring their expertise in, understand which situations it covers, and change it without accidentally affecting a live response.
That tension ran through every question. Knowledge brought in from elsewhere and a built-in agent needed different setups without turning into two systems. A change in progress could quietly reach responders, and a test that ran didn’t mean the advice was useful. Automatic runs shifted who decides the agent gets involved. And the wrong scope meant either missing help or more noise in an incident that was already crowded.
So the design question became: what would make preparing AI assistance worthwhile for the people who maintain it, and dependable for the people expected to use it?
What does it know?
Service teams needed one place to see every agent and skill they owned: what was registered, what was still a draft and what was live. I designed that shared view. Some capabilities were built elsewhere and brought in, so this wasn’t an authoring tool for every agent, and I challenged a setup label that would have implied a linked capability was registered and reusable when it wasn’t.
The built-in troubleshooting agent was different. It already existed, so instead of the registration flow for a new custom agent, it got a shorter path: a team could review the service context already found for them, correct it and add skills. We built that entry point first.
What has been tested?
I designed a draft, test, then publish flow. A team could save a draft and run the agent against selected past incidents before making the change live, so exploring a change never quietly changed what responders received.
Where I got it wrong
I underestimated a problem in my own test flow. We had one continuing draft. A team could change its guidance, run a test, change something else and test again, all under the same version label. Which configuration produced which result? Worse, an earlier passing test could appear to justify publishing a draft that had since changed.
I walked product and engineering through that scenario, and the discussion moved from the results table to the rule underneath it: once a draft changes, its earlier test no longer counts, and the experience has to tell the team to test again. The team carried that rule into the test-flow design, and engineering later showed a draft could be tested against an incident without publishing it.
It also exposed a limit. A required test can stop an untested change from going live, but a report that generates successfully can still leave a responder unsure what to do. Configuration failures and the quality of the guidance are different measures, and testing has to account for both.
When should it run?
The team wanted more responders to use troubleshooting reports, and considered a prominent first-run prompt that could lead toward turning on automatic runs. I pushed back on making that the starting point. Responders could already run a report themselves, and nothing showed that action was being missed. A modal in the first minutes of an incident would interrupt, and asking a team to automate reports before anyone had judged one put adoption ahead of value.
I recommended starting with a run the responder chooses, explaining what it does, and letting them judge the result before offering automation. When automation is on, publishing is the activation point, never a saved draft, and automatic runs can be switched off without losing manual use. The first-run prompt itself is still an open decision.
Who can change it?
Scope decides whether help shows up in a responder’s context. I designed how teams describe where an agent or skill applies, who can make a change live, and how skills can be reused without every team repeating the same setup. I also questioned whether one responder should be able to turn on behavior for an entire team. Discoverability, permission and trust turned out to be separate decisions, not one consent checkbox.
Maintenance was the part I couldn’t solve with a screen. Imported capabilities depended on people coming back to refresh what had changed elsewhere, and different capabilities ended up with different update paths. That left an open question: would teams know where to maintain each one, and keep doing it?
What happened
The shared foundation moved beyond a prototype: service teams used custom agents during real incidents. My most direct influence was the test-flow rule, where a gap I surfaced became an explicit part of the design.
What isn’t measured yet is whether this improves the guidance responders get, or how fast they mitigate. Success would look like teams coming back to correct stale context, and responders saying the guidance was relevant, checkable and worth the effort of reviewing.
What I took away
Trust has a cost. Good design makes that cost visible, puts it with the right people, and finds out whether the help gives back more than it asks.