Microsoft’s latest Insider cumulative update, packaged as
KB5072043 and published for the Windows 11 Insider Preview (Build
26220.7523), formally introduces a developer- and platform-level feature called
Agent Launchers — a standardized framework that lets apps register interactive AI agents so they can be discovered and launched system‑wide (for example, from the taskbar Ask Copilot surface, Start, or Search). This change marks a deliberate step away from agents being sealed inside single applications and toward Windows acting as a shared surface and discovery hub for interactive, action-capable assistants.
Background / Overview
Microsoft has been reworking Windows into what it now calls an
agentic platform: an operating system that not only hosts apps but also surfaces and orchestrates AI agents that can hold multi‑turn conversations, retain context, and execute multi‑step tasks. The Agent Launchers framework is the registration and discovery piece of that architecture — it provides a single integration point so developers don’t need bespoke plumbing for every system surface that wants to invoke an agent. The feature is shipped in the 26220.x enablement flight for Windows 11, and the cumulative package for this preview is KB5072043. Agent Launchers are explicitly designed for
interactive, visible agents — not for silent background services. When a user invokes an Agent Launcher, Windows launches the registered agent and opens its interactive chat or task UI so the user can engage immediately. That behavioral contract (interactive UX + App Action invocation) is enforced by the platform registration requirements.
What Agent Launchers are and how they work
The technical primitives
Agent Launchers build on three existing Windows plumbing pieces:
- App Actions — the existing framework for apps to declare actionable commands that the OS or other apps can call.
- Agent definition JSON manifest — a small JSON file that outlines metadata for the agent (display name, icon, package identity, and the App Action to invoke).
- On‑Device Registry (ODR) — a system registry for discoverable agent registrations that supports both static (install-time) and dynamic (runtime) registration via the odr.exe tool.
Microsoft’s developer documentation spells out the minimal contract for an App Action to qualify as an Agent Launcher — it must accept at least two text entities named
agentName and
prompt, and invoking the App Action must present an interactive surface rather than silently performing work. This ensures agents are
visible and controllable when users engage them. Developers can register agents statically via their app package manifest or dynamically with
odr add-app-agent at runtime.
Typical registration and invocation flow
- Developer implements an App Action that accepts the required entities (agentName and prompt) and opens an interactive agent UI.
- Developer creates an agent definition JSON and either:
- Adds a com.microsoft.windows.ai.appAgent extension to the package manifest (static registration), or
- Calls
odr.exe add-app-agent "<path-to-agent.json>" to register dynamically.
- Windows surfaces registered agents to supporting experiences (Ask Copilot, Start, Search, or other apps).
- When invoked, Windows calls the App Action with the prompt and agentName entities; the agent’s chat window opens for multi‑turn interaction.
This design gives developers a single integration point to make agents available everywhere Agent Launchers are supported, improving discoverability and reducing integration complexity.
Why this matters: platform, developer, and user perspectives
For the platform
Agent Launchers push Windows farther into a role as a
shared runtime and discovery surface for agents. Rather than each app exposing its own “assistant” siloed inside the app, Windows can display a catalog of agents installed on the device; that catalog is queryable via the On‑Device Registry and usable by any supporting experience without bespoke integration work. This reduces fragmentation and lets the OS provide consistent invocation UX, telemetry boundaries, and (eventually) governance surfaces.
For developers
- Single registration, broader reach: register once and be available everywhere Agent Launchers are supported.
- Static + dynamic registration: ship agents with an app or enable them conditionally (for example, based on sign-in, subscription, or entitlement).
- Familiar APIs: App Actions and the Windows.AI.Actions APIs are used to invoke agents programmatically.
This lowers the barrier for third‑party agents to appear in system surfaces, potentially accelerating an ecosystem of specialized assistants (for finance, legal, HR, creative tools, etc..
For users
Agent Launchers promise a more consistent discovery experience: users will be able to find and launch the same agent regardless of which app installed it. Combined with taskbar integration via
Ask Copilot, this reduces friction for invoking help and makes agents feel like native desktop helpers rather than isolated app features. Microsoft’s Insider announcement calls out agents such as
Researcher and
Analyst (used by Microsoft 365 Copilot) as examples of agents surfaced through this framework.
Verified technical details (what’s grounded in Microsoft docs)
- The Microsoft Learn Agent Launchers overview documents the registration model, the agent definition JSON structure, and the requirement that an App Action accept
agentName and prompt entities. This page was updated in December 2025 and is the authoritative developer reference for building Agent Launchers.
- The Windows Insider Blog post announcing Build 26220.7523 (KB5072043) confirms the inclusion of Agent Launchers and the Ask Copilot taskbar surface in this preview flight, and names Researcher and Analyst as Microsoft agents using the system.
- The
odr (On‑Device Registry) tooling and commands for adding, listing, and removing app agents are documented in the Microsoft Learn get‑started guide, including examples for odr list-app-agents and odr add-app-agent.
These three points — the manifest-based registration, the App Action input contract, and the ODR commands — form the concrete technical core of Agent Launchers and are validated in Microsoft documentation and the Insider release notes.
Real-world implications, use cases, and early examples
Agent Launchers are explicitly designed for interactive, task‑oriented assistants rather than background daemons. That enables scenarios such as:
- Knowledge work agents: a Researcher agent that assembles a detailed report from multiple sources and notifies you when the synthesis is ready (visible on the taskbar during processing). Microsoft points to Researcher as an example now surfaced by Ask Copilot.
- Data analysis agents: an Analyst agent that ingests spreadsheets and generates insights or recommended next steps without manual aggregation. Microsoft lists Analyst as a registered Copilot agent using the framework.
- Third‑party specialist agents: industry vendors could register domain-specific assistants (legal research agents, creative writing agents, CAD assistants) that users find via system search and launch as needed.
From an enterprise perspective, dynamic registration means agents can be gated behind authentication and licensing checks: an app could register its agent only when the user is signed into a corporate tenant or has an appropriate Copilot subscription. That enables IT-friendly deployment models in managed environments.
Security, privacy, and governance: strengths and open risks
Agent Launchers make important design choices to address the unique risks of agents, but they also alter the Windows threat model in ways organizations must plan for.
Built‑in design strengths
- Visibility and interactivity: agents must present a UI and accept user input, which reduces the risk of fully autonomous background actions that a user cannot inspect. The App Action contract enforces this interactive surface.
- Single registration and discoverability: a centralized registry (ODR) makes it easier to list and audit what agents are present on a device, rather than hunting through multiple app manifests.
- Static vs dynamic registration: dynamic registration lets apps add or remove agents based on credentials or entitlements, helping organizations limit exposure.
- Tight invocation contract: requiring
agentName and prompt input entities ensures that launched agents receive explicit user intent and are less likely to run with opaque inputs.
Open risks and operational gaps
- Surface expansion: making agents discoverable system‑wide increases the attack surface. Any vulnerability in an agent or its hosting app could have broader visibility and potential for privilege escalation.
- Background automation ambiguity: although the Agent Launchers contract requires an interactive surface, Microsoft’s broader Agent Workspace and Copilot Actions work shows agents can perform multi‑step UI automation in a contained runtime — a capable agent could still execute many consequential changes once granted permissions. That capability increases the need for robust logging, audit trails, and admin controls. Some implementation details around containment, exact folder scopes, and enterprise policy surfaces were described in Insider communications and community reporting but are still evolving. Organizations should treat agent features as a new class of privileged automation that needs the same scrutiny as service accounts and scheduled services.
- Data flow and DLP: agents will commonly need to access local files or tenant data; when cloud-based Copilot services are involved, data flow patterns (local → cloud) and telemetry must be reviewed by security and compliance teams. Windows and Copilot provide permission flows, but enterprise DLP and SIEM teams should validate those flows in pilots before broad rollout.
- Supply chain and signing: Microsoft has indicated that agent signing and revocation will be part of the trust model to reduce risk from compromised agents. However, signing is a control that requires operational processes (certificate management, revocation checks, and EDR integration) to be effective in practice.
Cautionary notes on unverified or evolving claims
Some community reports and Insider previews describe the
default known folders agents may access (for example, Documents, Desktop, Downloads, Pictures, Music, Videos) and the broader Agent Workspace containment model. These behaviors are consistent across multiple previews and early documentation, but exact runtime permissions, and the final enterprise management surfaces (GPO/Intune policy nodes, audit log schemas, SIEM integration points) are still maturing and subject to change. Treat any specific folder lists or governance features described in early previews as provisional until confirmed in general‑availability documentation.
Practical guidance: how to evaluate and adopt Agent Launchers
For IT admins and power users considering testing or rolling out agentic features, a cautious, staged approach is recommended.
- Pilot in a controlled environment:
- Use non‑production devices and a narrow group of users.
- Enable the experimental toggles only on pilot devices.
- Validate DLP and telemetry:
- Test data flows when an agent accesses files or escalates content to cloud services.
- Ensure SIEM/EDR logs capture agent actions and provenance.
- Confirm identity and entitlement behavior:
- Verify dynamic registration scenarios (agents appearing/disappearing based on sign-in or subscriptions).
- Test revocation and incident playbooks:
- Simulate a compromised agent scenario and confirm certificate revocation and blocking via EDR/AV works as expected.
- Measure UX and performance:
- Record perceived latency, CPU/NPU utilization (on Copilot+ hardware), and any taskbar or shell regressions during testing.
A concise checklist for hands-on testing:
- Inventory devices that will participate.
- Capture baseline telemetry and restore points.
- Install Build 26220.7523 on pilot devices (Insider Dev/Beta).
- Enable Ask Copilot and Agent features where staged.
- Register a sample Agent Launcher statically and dynamically; exercise
odr list-app-agents.
- Run sample agent invocations and confirm UI, logging, and pause/takeover controls.
Developer primer: registering an Agent Launcher (summary)
- Implement an App Action that accepts
agentName and prompt entities.
- Create an agent definition JSON that references the App Action’s id.
- For static registration: add a com.microsoft.windows.ai.appAgent extension in the package manifest pointing to the JSON.
- For dynamic registration: call
odr.exe add-app-agent "<path-to-agent.json>" at runtime and verify with odr list-app-agents.
- Use the Windows.AI.Actions APIs to invoke the App Action programmatically from companion experiences.
This workflow is documented in step‑by‑step form on Microsoft Learn and provides code snippets for common languages and project types.
Strengths, limitations, and what to watch next
Agent Launchers are a sensible, technical improvement that reduces fragmentation for agent discovery and makes Windows a more coherent host for multi‑turn assistants. The framework’s reliance on App Actions and the ODR is elegant: it leverages existing OS mechanisms rather than inventing entirely new plumbing, and its static/dynamic registration model is flexible for commercial scenarios. However, the real impact will depend on:
- Ecosystem adoption: will third‑party ISVs build and publish compelling agents that users want to launch from the system surface?
- Management tooling: will Microsoft deliver enterprise-grade policy controls, reporting schemas, and SIEM/EDR integrations before broad production rollout?
- Operational trust: will signing, revocation, and supply‑chain protections be robust enough to reassure security teams?
Two concrete items to watch in upcoming releases:
- The expansion of Intune/GPO controls that specifically target agent behaviors and agent runtime permissions.
- The finalization of audit log schemas and recommended SIEM ingestion patterns that attribute actions to agent principals rather than human users.
Conclusion
KB5072043 (Build 26220.7523) formalizes the Agent Launchers framework and places a clear developer-first path for making interactive AI assistants discoverable and invokable across Windows. The feature is well-documented on Microsoft Learn and described in the Windows Insider release notes; it ties together App Actions, an agent definition manifest, and the On‑Device Registry to give agents a single, systemwide registration surface. For developers, Agent Launchers lower integration overhead and expand reach. For users, they promise consistent discovery and immediate interactivity. For IT and security teams, the change raises legitimate governance and DLP questions: agents change the trust model of the desktop and must be treated as a new class of privileged automation. Early adopters should pilot the build in controlled scenarios, validate telemetry and policy enforcement, and only then consider broader deployment.
Where Agent Launchers excel is in standardization; where they create the most work is in management and risk mitigation. The framework provides the building blocks, and the coming months will determine whether Microsoft and the ecosystem can operationalize those blocks into secure, manageable, and genuinely useful assistants on the desktop.
Source: Windows Report
Latest Windows 11 Update, KB5072043, Adds Agent Launchers for System-Wide AI Agents