Agents as a Managed System

Admins used to manually investigate and coordinate remediation across disconnected consoles — spending more time coordinating than solving problems.

Bringing agents into Intune raised a foundational design question: what does it mean to design agents as a category of Intune functionality — not one-off features, but a system that needs to be introduced, permissioned, governed, and managed at scale?

Multiple agents were all in motion at once, built by different teams at different speeds. The real risk wasn’t any single agent shipping badly; it was multiple teams each answering the same questions differently: how an admin grants an agent access, how the agent reaches admins where they already work, and how every action gets logged and approved before it runs.

Before any one agent could be designed well, the category itself needed a shared framework to design against — role-based access, human-in-the-loop approval, and transparent logging as the default for every agent action, plus consistent delivery through the Intune console and Teams. Every agent after that built on the same foundation instead of each team inventing its own.

I joined regular MVP calls as the UX representative to hear this from customers directly, not just infer it internally — admins wanted the same answer to those three questions every time, not a different one depending on which agent they were looking at: one way to grant access, one place to be reached, one way to see what happened and why.

This was also Intune’s first introduction of agents, with no existing precedent to build on. Those same conversations made clear that trust would be the hardest part to earn, not the technology — admins needed to see an agent behave predictably and transparently before they’d extend it any real autonomy. That shaped a deliberately methodical approach: transparency, trust-building, and keeping a human in the loop before adding more automated capability, rather than rushing toward autonomy.

Two models for how much agents should do on their own were on the table early.

Approval gates set the oversight bar — but that bar could move as trust was earned. The framework staged that explicitly:

Which stage an agent reaches, and when, depends on more than the interaction model — funding and technical scope shape that as much as anything. What the framework provides is the design language for each stage, so admins already have the pattern for what more trust looks like whenever an agent is ready to move.

Multiple agents, sharing one interaction model and one set of components — not separate UIs stitched together after the fact. Individual agent screens live on their own chapter pages; what shipped here is the framework underneath all of them. All shipped to public preview on schedule for Ignite, under embargo, with quality validated through Microsoft Digital and CxE (Customer Experience Engineering) testing before enterprise rollout.

Every agent follows the same shape, whatever it’s watching for: it’s triggered by a schedule or an event, investigates the relevant state, builds a plan, and presents that plan for review before it does anything. Trust but review, not trust and hope — the plan is always visible before it becomes an action.

I designed “managed” to mean an ongoing lifecycle each agent plugs into, not a one-time action to watch run — starting with identity and permissions: every agent runs under its own chosen identity rather than a shared one, scoped access, authentication that expires after 90 days. I reused that same settings pattern for configuration and scope across every agent, rather than redesigning a bespoke screen each time a new one shipped.

Both of these took longer to build than the simpler version would have — deliberately.

I designed for a fuller operational surface than what shipped. Cut for v1 to ship the core loop faster — not because the rest wouldn’t add value, but because sequencing mattered more than completeness at launch.

The fuller operational surface I designed for, not a shipped inventory — Teams/email delivery and suggestion dismissal didn’t make v1.