This project began outside my formal scope. While Security Copilot's platform team was building agents for a standalone portal, I believed AI agents belonged in the first-party security experiences customers already used: Purview, Defender, Entra, and Intune. I spent two days prototyping that vision, then partnered with my PM to pitch it internally. The idea ultimately reached Security leadership and sparked investment across all four portals.

Because alert fatigue is undoubtedly the clearest customer pain point, we made it the focus for Purview's first agent. We also knew that processing and classifying content was one of the most reliable capabilities of LLMs at the time, so our data science team got started on a proof of concept.

To avoid designing an agent nobody trusted, we needed real analysts to shape it.

I partnered with engineering and data science to define what the agent should surface, including not just alert severity but the context analysts needed to make remediation decisions. In parallel, I worked with researchers to validate early concepts with users.

That research surfaced five things that shaped our MVP:

• Analysts needed transparency into the agent's coverage and decisions in order to trust it.
• "Critical" risk varies by organization, requiring the agent to be personalizable.
• Customers wanted broader user activity context beyond a single alert.
• Timeline visualization and page structure validated well in testing.
• Revising the agent’s finding wasn’t something they anticipated spending time doing unless it shaped the agent's future decisions.

Designing Purview's first agentic workflow

Based on learnings from our concept tests, I designed an end-to-end triage experience from discovering the agent to giving it feedback. At this point I partnered very closely with my product team to ensure what I was designing was feasible.

This included making several tradeoffs, such as:

• Changing the agent feedback from natural language to structured data so that the agent's interpretation was more reliable.
• Creating a way for the agent to triage alerts on demand rather than automatically for organizations who were worried about compute costs.
• Deferring the agent performance metrics until a new API could be built to calculate certain measurements.

The queue architecture decision

The central MVP tradeoff was balancing clarity with integration: should agent insights augment existing alerts or live separately? Embedding agent decisions into the existing queue risked creating conflicting signals (ie. the agent determined the alert "needs attention" while its policy severity remained "low.") A dedicated queue preserved clarity but introduced the risk of hiding signals an analyst was relying on.

We shipped the dedicated queue due to technical constraints and performance benefits, then validated the decision through comparative research. Four of six participants preferred a unified experience. It was a meaningful signal, but not strong enough to justify an immediate pivot.

Shipping as One Microsoft Security

Alongside the MVP build, I worked horizontally with designers across all four first-party products to build a shared library of agent interaction patterns encompassing: promotion, deployment, management, agent output, and feedback to the agent. I led the working group responsible for agent output and feedback-to-agent patterns.

To close the gap between what tested well and what analysts actually adopted, we had to rebuild around real-world behavior.

In a matter of weeks, Alert Triage Agent was live in Data Loss Prevention and Insider Risk Management, analyzing, validating, and aggregating risk factors on real alerts.

After a few months released to the public, the agent was quoted by Satya in the Fiscal Year 2026 Q3 Earnings Call as handling "over 2 million unique alerts this quarter alone."

Rapid iteration until we got it right

Over time, telemetry and direct customer feedback told a different story than our testing had. Customers weren't deploying it at the rate we expected, and we heard directly that they wanted the old queue back.

I worked with a PM and content designer to analyze the telemetry and rebuild the entry points and deployment flow, and with a user researcher on a combined-queue usability study. Together, that work targeted three specific problems the launch had exposed:

The rebuild raised deployment completion from 23% to 44%, and entry-point exposure 2.5x week-over-week, and feedback on the combined queue has been consistently positive.