The pitch is an admin console that reads for you and a set of agents that work for you. The reality in the middle of 2026 is narrower, more useful, and more fragile than the pitch: one assistant that is genuinely generally available, three agents that are all still in preview, and one agent that has already been retired less than a year after it was announced. Day-two operations is exactly where this belongs, and exactly where you should be precise about what to trust.
This article is a status map, not a tutorial. The question it answers is the operational one: which of these capabilities can carry weight in a production tenant today, under what licensing, and with what governance. Where the agents touch controls covered earlier in this series, the second-signature workflow and the delegation model, I will point across rather than repeat.
The assistant in the console
Copilot in Intune, the embedded assistant, has been generally available since mid-2025 and is the part I treat as production. It does natural-language exploration of your own Intune data, devices, users, apps, policies, compliance, and can carry the result into an action like building a report or adding devices to a group. It explains individual settings in context, summarizes what a policy actually does, and flags where a setting is configured elsewhere, which quietly addresses one of the oldest failure modes in Intune administration: nobody reading the fine print of a settings catalog entry. On a device record it will summarize state for troubleshooting, and it will generate KQL for device query from a plain-language question, with the caveat that device query itself is an Advanced Analytics capability and therefore rides the Suite licensing rather than the base plan.
Its boundaries are as instructive as its features. The chat box accepts natural language from anywhere in the console, but it matches your words against the scoped experiences Microsoft built rather than behaving like an open-ended prompt. It sees Intune, not your Defender or Entra or Purview estate, so it cannot answer the cross-product questions an operations person actually asks at 9 a.m. And it only generates device queries for properties device query supports. It is a reading assistant with deep knowledge of one console, and used as that, it earns its place.
The agents, counted honestly
Microsoft announced a slate of Intune agents in late 2025, and the portfolio has already changed shape once, so let me count it as it stands in July 2026. Three agents are active, and every one of them is public preview, not general availability. The Change Review Agent reads pending Multi-Admin Approval requests for Windows PowerShell scripts, up to ten per run, and recommends approve, reject, or needs-more-information with its reasoning; since spring its recommendations appear inline in the approval queue itself. The decision stays with a human approver, which is the posture the second-signature article assumed and the right one. The Policy Configuration Agent translates requirements documents, security benchmarks, internal standards, plain-language asks, into draft settings catalog configuration for Windows, which an administrator reviews and edits before anything is created. The Vulnerability Remediation Agent uses Defender Vulnerability Management data to surface CVEs on managed devices and propose prioritized, Intune-specific remediation steps; it opened to all customers in preview this June and now runs under a dedicated Entra agent identity rather than borrowing its operator’s, which is the same first-class-identity-for-agents direction the Entra series described.
The fourth agent is the cautionary tale. The Device Offboarding Agent, which identified stale devices for cleanup, was announced in November, closed to new setups at the end of April, and removed from the product entirely on the first of June. Nothing about it was bad; Microsoft simply changed its mind inside seven months. That is the fact to carry into planning.
One of the four agents announced in November was retired by June. The portfolio is fluid. Your operations should not be.
What it costs, and what governs it
The licensing model is refreshingly unlike the rest of Intune. There is no Copilot-in-Intune SKU: the whole surface is included with Security Copilot, which is bought as provisioned capacity in Security Compute Units, a minimum of one unit per tenant, with optional overage capacity for bursts. Since late 2025 that purchase is no longer the only path in, because Microsoft now includes Security Copilot with Microsoft 365 E5 and E7, granting a monthly allocation of four hundred compute units for every thousand paid licenses, capped at ten thousand, which for many enterprises means the capacity question is already answered by the license they hold. The agents each add their own prerequisites on top: all of them want Intune Plan 1, the Change Review Agent additionally requires Entra ID P2 and Defender Vulnerability Management, the Vulnerability Remediation Agent requires the Defender Vulnerability Management data it reasons over, and the entire estate is public cloud only, with no government cloud support. What Microsoft does not publish is per-run consumption; agents draw from the same compute pool as everything else, and preview or not, their usage is billed. So the honest budgeting method is empirical: provision small, watch the usage dashboard for a month with the category filter on agents, and size from evidence rather than from a rate card that does not exist.
Governance landed properly this May and it is better than the preview era deserved. Intune’s own RBAC now projects into Security Copilot: the Intune Administrator role inherits the Copilot owner role, every other built-in and custom Intune role inherits contributor, and Copilot honors your existing Intune role assignments and scope tags, so an administrator can only explore the data their delegation already allows. That makes the delegation design from earlier in this series load-bearing here too, with one preview-era gap worth noting: the Vulnerability Remediation Agent does not yet respect scope tags, which in a partitioned tenant is a real reason to keep its operator circle small. Operationally, each agent runs as a single instance per tenant, is started manually, and its authentication expires after ninety days without a run, which is exactly the kind of quiet dependency that turns into a mystery outage in month four. Put the re-run on someone’s calendar.
What I would actually do today
Adopt the assistant without ceremony; it is generally available, it reads your tenant through your own permissions, and its worst failure mode is an unhelpful answer. Adopt the agents in an advisory posture only, and pick them by the queue they shorten. If you run Multi-Admin Approval on scripts, the Change Review Agent is the natural first: it attacks the control’s weakest point, the tired approver, without touching the control’s authority. If you carry a vulnerability backlog, the remediation agent turns Defender findings into Intune-shaped work items faster than a human triage pass. The policy agent is the one I hold loosest, useful for a first draft from a benchmark document, never for unreviewed policy. In every case the agent recommends and a named human decides, both because that is the documented behavior and because preview features with a demonstrated seven-month half-life should not sit inside your change-control loop as anything but advisors. The day the first of these goes generally available, revisit. Until then, let them read, let them draft, let them recommend, and keep the stamp in a human hand.
Intune Deployment Guide · Phase 10: Day-Two Operations
‹ Previous: [10.5] Change Management: Making Changes Safely at Scale
