The roadmap says preview availability began in April 2026 and general availability followed in June 2026 for worldwide standard multi-tenant tenants. Its terse wording leaves out the endpoint contract, supported agent types, and pricing details, but Microsoft Learn documentation published since June fills in an important part of the picture: Work IQ is a permission-aware service layer for agents and applications working with Microsoft 365 data, exposed through REST, Model Context Protocol, and Agent-to-Agent interfaces.
For developers, the practical change is that a declarative agent can become a reusable capability inside an application workflow. For administrators, it creates a new integration surface that needs tenant enablement, delegated authorization, consent review, billing controls, and a clear inventory of which agents are available to which users.
Roadmap item 559019 moves agent access beyond Copilot Chat
Microsoft’s roadmap describes the feature as access to “first-party and tenant-defined declarative agents” through a Work IQ endpoint. Declarative agents are customized Microsoft 365 Copilot experiences configured with instructions, knowledge sources, and actions. They can use organizational content such as SharePoint, OneDrive, Teams, and Copilot connectors, while potentially calling approved external API plugins.
Until now, the most visible way to use those agents has been within Microsoft 365 Copilot and its embedded app experiences. Programmatic invocation changes the placement of the experience: a line-of-business app, an internal portal, or another AI agent can hand a task to a specialized Copilot agent and incorporate its response into a larger user-facing process.
That does not turn declarative agents into general-purpose unattended automation. Microsoft’s Work IQ permission reference says the agent-query permission, WorkIQAgent.Ask, is delegated only. An application can ask Work IQ agents and receive responses on behalf of a signed-in user, but Microsoft does not document an application-only permission for the capability. A background service cannot simply run a tenant-wide batch of agent requests without a user context under the currently documented model.
This is a material boundary for IT teams. The feature suits interactive workflows such as an employee portal asking an HR policy agent to interpret benefits guidance for the current user, or a sales application passing a user’s request to a tenant-built account-research agent. It is a weaker fit for overnight processing, mailbox-wide analysis, and other workflows commonly built around app-only Microsoft Graph permissions.
The Work IQ API has a larger surface than the roadmap entry suggests
Microsoft’s Work IQ documentation describes three ways for software to interact with its service: REST for web applications, MCP for agent and tool integrations, and A2A for one agent delegating work to another. The declarative-agent roadmap item sits within that wider push to make Microsoft 365 Copilot’s grounding and reasoning infrastructure callable from outside its standard chat interface.
The MCP documentation is especially revealing about how Microsoft intends this to work. It lists a list_agents capability for discovering available agents and an ask capability for invoking Microsoft 365 Copilot intelligence. That is a more usable pattern than hard-coding every agent into an application: software can discover which agents the current user can access, select an appropriate one, and send the task with the user’s permissions applied.
Microsoft has also documented a REST Chat API that can create and continue Copilot conversations. Its conversation resource includes an agentId property, indicating that the API model has a mechanism for associating a conversation with an agent. But Microsoft’s currently published REST material is not yet a clean, standalone reference for the roadmap’s “Declarative Agent Access” wording. Administrators and developers should not infer that every existing declarative agent is automatically callable from every Work IQ protocol, or that all client experiences have feature parity.
The distinction is important because Microsoft labels protocols and endpoints differently. A team evaluating the feature needs to establish whether its target integration will use REST, an MCP client, or A2A; whether the desired tenant agent is discoverable through that protocol; and whether the release is production-supported for the intended path.
“Launched” does not erase preview limitations
There is a timeline discrepancy worth noting. The current Microsoft 365 Roadmap entry shows the feature as Launched, with general availability in June 2026. Merill’s Message Center Archive and Cloudscout’s historical roadmap tracking both preserve an earlier version of item 559019 that described it as “In development” with the same projected June general-availability date.
That is consistent with a roadmap status update rather than evidence of a different product release. Still, the public documentation requires a closer reading than the status badge alone. Microsoft’s REST Chat API documentation offers both a standard path and a /beta path, while warning that APIs under /beta can change and are not supported for production applications. The warning applies to beta APIs, not necessarily the non-beta REST route, but it means developers must check each specific API version and method rather than treating “Work IQ” as uniformly GA.
Microsoft’s Foundry guidance adds another caution: its Work IQ connection walkthrough remains explicitly labeled preview and says preview features are not recommended for production workloads. That documentation uses A2A to connect a Foundry agent to Work IQ. In other words, the roadmap item’s GA status confirms a release milestone for declarative-agent access, but it does not certify every related Work IQ integration, protocol, SDK, or Azure Foundry workflow as production-ready.
The safe operational reading is straightforward: validate the exact endpoint and protocol in Microsoft’s current documentation, avoid /beta for production where a supported equivalent exists, and build fallback handling for agent discovery or invocation failures.
Tenant enablement and consent are the real deployment gate
Work IQ access is protected by Microsoft Entra ID OAuth 2.0, and Microsoft says an organization administrator must enable Work IQ before applications can use its permissions. The WorkIQAgent.Ask delegated permission also requires administrator consent.
Those controls are necessary because Work IQ’s value comes from its ability to reason over work data while honoring the caller’s existing Microsoft 365 permissions. Microsoft says requests operate in the signed-in user’s context, which should prevent an employee from receiving content they could not otherwise access. But that does not make an agent integration risk-free. A well-permissioned user can still ask an agent to synthesize a broad set of information they are allowed to see, and the response can then be displayed, stored, forwarded, or mixed into another application’s workflow.
Teams should therefore review the receiving application, not just the declarative agent. A consent screen that says an app can ask Work IQ agents on a user’s behalf can carry wider practical implications than a narrowly scoped content lookup. Microsoft’s permission description says the agent permission includes read and write access to Microsoft 365 resources accessible to Work IQ agents and scoped to the signed-in user. The exact actions available depend on the agent and Work IQ capabilities involved, so administrators should treat the permission as an integration boundary requiring a security review.
A sensible rollout should include the following checks:
- Confirm that Work IQ has been enabled intentionally in the tenant and that the relevant Entra enterprise application has received approved administrator consent.
- Test with least-privileged pilot users whose Microsoft 365 access mirrors the intended deployment population.
- Verify which declarative agents are discoverable to those users and whether their knowledge sources, plugins, and actions are appropriate for invocation outside Copilot Chat.
- Capture audit, application logging, and data-retention requirements before responses are written into a separate line-of-business system.
- Set spending controls before broad deployment because custom and third-party Work IQ usage can be billed by consumption.
Licensing is separate from API cost
Microsoft’s Work IQ overview says API access is independent of Microsoft 365 Copilot licensing and uses consumption-based billing. Microsoft 365 Copilot users can use Work IQ within Copilot experiences and agents, while custom and third-party agent usage remains subject to usage-based billing. Users without a Microsoft 365 Copilot license can also generate Work IQ costs based on use.
That is a significant departure from a simple “Copilot license equals API access” assumption. A tenant may be able to technically enable a new application for users without assigning every one of them a Microsoft 365 Copilot license, but it must account for metered usage. Microsoft says costs can be managed in the Microsoft 365 admin center; the roadmap entry itself does not publish rates, workload quotas, or a migration path for existing agent integrations.
The immediate consequence of Roadmap 559019 is not that every organization should expose its declarative agents through a custom app. It is that declarative agents can now be considered as callable, user-scoped building blocks in Microsoft 365 workflows. Enterprises that have already invested in agent instructions, knowledge, and governance can reuse that work—but only after confirming the protocol’s production status, approving delegated access, and deciding who pays when those agent calls move beyond Copilot Chat.
