Roadmap item 559017 describes pay-as-you-go usage billed according to the agents and models invoked per request. Its June 2026 release window should not be mistaken for a new September launch: Microsoft announced the APIs on June 2, with general availability scheduled for June 16, and its roadmap now identifies the suite as generally available. The practical development is an additional way to fund applications using Microsoft 365 intelligence, rather than a change that every Copilot subscriber must activate.
The operational details are more consequential than the short roadmap entry suggests. Microsoft’s administration documentation describes group-scoped access, monthly spending limits, prepaid-credit consumption, automatic pay-as-you-go continuation, and policies that can automatically admit future services. Those controls make a measured deployment possible—but several defaults deserve attention before administrators select Activate.
Work IQ pay-as-you-go separates API access from Copilot seats
Microsoft’s Copilot Credits licensing guide says Work IQ APIs can be invoked on behalf of Microsoft 365 users through agents and custom AI solutions. API usage consumes Copilot Credits; a Microsoft 365 Copilot seat is not the entitlement that pays for those calls. Microsoft’s developer guidance also says usage-based billing must be enabled for the calling user.
This is a narrower change than “Copilot without a license” might imply. It provides a way to fund a particular programmatic service. It does not grant every Microsoft 365 Copilot application feature, eliminate the underlying Microsoft 365 account, or substitute for the user’s permissions to organizational information. Work IQ requests still run under delegated Microsoft Entra identity.
Microsoft explicitly distinguishes these charges from Work IQ operating inside native Copilot experiences. Its licensing guide says native Copilot chat, supported AI experiences in Office applications, and included agents do not incur an additional Work IQ API charge merely because Copilot uses Work IQ internally. Existing licensing treatment for the older Retrieval API and Chat API also continues, according to the guide.
For a development team, the useful comparison is therefore between access paths, not simply between licensed and unlicensed employees. An application calling the new Work IQ APIs introduces a separately metered component. An employee using an included native Copilot capability is following a different licensing path. Treating both as interchangeable “Copilot usage” would obscure the purchasing decision.
Roadmap metadata lists Desktop, Linux, Mac, and Web, alongside Worldwide Standard Multi-Tenant and DoD cloud instances. These are service-roadmap classifications, not evidence that every client, authentication configuration, or government-cloud endpoint has identical setup instructions. The commercial administration procedures discussed here should not be treated as a verified DoD deployment recipe.
Work IQ exposes workplace context through distinct interfaces
Microsoft describes Work IQ as an intelligence layer combining Microsoft 365 information with contextual understanding. Its API overview lists email, meetings and calendars, OneDrive and SharePoint documents, Teams messages, people and organizational context, Planner plans, and enterprise search among the supported information sources. The aim is to let applications reason over work without separately assembling all that context themselves.
The distinction between returning an answer and returning material for another agent is important. Microsoft’s launch announcement divides the API suite into four domains: Chat returns synthesized responses; Context supplies information prepared for agent consumption; Tools provides access to actions and entities; and Workspaces holds intermediate state and outputs during agent execution. These domains describe different jobs, rather than four names for a single conversational endpoint.
Microsoft’s claimed development benefit is reduced responsibility for extraction, indexing, synchronization, and permission enforcement. The API overview describes permission-trimmed access: results are constrained by what the signed-in user can access. That can simplify an application’s data plumbing, although it does not establish that every proposed integration will be cheaper or require no additional engineering. Those outcomes depend on the application.
Developers also have a choice of interaction protocols:
| Interface | Documented purpose | Architectural consequence |
|---|---|---|
| Agent-to-Agent, or A2A | Delegating work from another agent and receiving structured results. | Suits an orchestrator that hands a task to Work IQ. |
| Model Context Protocol, or MCP | Exposing Work IQ as tools for an AI assistant, with local and remote options. | Suits developer environments and assistants that request context when needed. |
| REST | Programmatic request-and-response interaction from an application or service. | Suits a custom application that renders or processes the returned answer. |
Microsoft presents these as recommendations rather than exclusive rules. Choosing a protocol does not change the requirement for the appropriate identity and billing configuration.
Nor should developers assume that every interface exposes every capability. The separate REST overview says that interface returns text and does not support actions such as sending mail, scheduling meetings, or creating files. It also lists long-running tasks as unsupported and warns that they are prone to gateway timeouts. An application requiring actions should not be designed around the REST conversational interface simply because the wider Work IQ suite includes Tools.
The same REST documentation says enterprise and web grounding are enabled by default. Disabling web grounding applies to an individual turn, so applications that do not want it must make that choice for each relevant message. Microsoft also warns that generated responses can be inaccurate. These are application-design boundaries, not matters resolved by buying additional credits.
Work IQ billing does not remove delegated identity
The most important authentication limitation is explicit in Microsoft Learn: application-only authentication is not supported. Work IQ uses delegated Microsoft Entra authentication, with requests executing in the signed-in user’s context. On-behalf-of flows are supported, allowing a service to act within that delegated authorization chain.
A backend integration therefore cannot assume that an app registration and client credentials are enough. The architecture must preserve the relevant user context. This also explains why removing the requirement for a preassigned Copilot seat does not make Work IQ anonymous or unrestricted: billing eligibility and permission to access information remain separate requirements.
Microsoft says existing Microsoft 365 permissions, sensitivity labels, and compliance policies are enforced. For administrators, that places the deployment review around the users and information the application can legitimately reach. Paying for a request does not confer broader access, while selecting a narrow billing group does not itself narrow the underlying document permissions of its members. The latter is an implication of the separate identity and spending controls, not an additional Work IQ security feature.
Multitenant organizations have a specific failure condition to account for. Microsoft documents that the access token’s issuer must match the tenant to which the signed-in user belongs, rather than simply the tenant containing the application registration. For its parent-and-child-tenant scenario, Microsoft directs developers to use a multitenant registration and authenticate users through their home tenant. An incorrect issuer can produce a 400 AuthenticationError reporting an error authenticating with the resource.
A2A developers have another concrete compatibility check. The overview documents versions 1.0 and 0.3: using the version 1.0 SendMessage method requires the A2A-Version: 1.0 request header, while omitting the header defaults to version 0.3. Multi-turn exchanges carry forward the returned contextId, and time-sensitive queries require location metadata. These are request-level prerequisites; changing a spending limit will not correct them.
There is also a reason to validate a real data operation during a pilot, rather than stopping at successful sign-in. In an August 19 Microsoft Q&A post, a customer reported that authentication and metadata tools worked for a user without a Copilot seat, while data-tool calls failed with an entitlement error despite a Work IQ spending policy. This is a customer report, not a confirmed service-wide limitation or a change to Microsoft’s published licensing terms. It nevertheless illustrates why sign-in alone is insufficient evidence that an integration is ready.
Microsoft 365 Cost Management makes a scoped rollout possible
Work IQ API spending is administered through Copilot > Cost Management in the Microsoft 365 admin center. Microsoft’s documentation places this service in the same usage-based management experience as Copilot Cowork, while directing administrators of other products—including Copilot Chat, SharePoint agents, and Copilot Studio—to their respective management instructions. A common credit currency does not make those configuration paths interchangeable.
Before activation, identify the intended users, the billing subscription, the responsible budget owner, and the service scope. Microsoft’s initial setup defaults to the entire organization and all users. Administrators planning a limited Work IQ deployment should use Customize setup configuration before activating, rather than enable the default organization-wide policy and assume they can treat it as a pilot.
The documented setup sequence is:
- Sign in with a Billing administrator or Global administrator account and open Copilot > Cost Management.
- Select Get Started to open the default spending-policy activation panel.
- Select the billing method and review the Azure subscription that will support consumption.
- Choose a monthly policy limit or unlimited spending. For a controlled pilot, a finite limit makes the intended budget explicit.
- Set an optional monthly per-user limit so one participant cannot consume the entire policy allowance.
- Configure policy alerts and recipients. If a per-user limit is set, configure the separate user-level threshold notifications.
- Review Auto-apply new services. Turn it off if future services should require a separate approval decision.
- Customize the scope to the intended security groups and select Work IQ API as the relevant service before activating.
- Select Activate, then Manage Configuration to inspect the resulting policy and its settings.
Microsoft says activation produces a completion notification, while newly created policies appear in the Configuration list and begin applying to scoped users immediately. That verifies the administrative configuration, not the entire application. A sensible acceptance check is then to confirm that an intended user can perform the intended Work IQ operation and that consumption becomes attributable to the expected policy. This is a deployment recommendation based on the separation between configuration, authentication, and reporting.
Billing ownership deserves particular care. Microsoft says a policy’s billing method cannot be changed directly after creation; changing it requires deleting and recreating the policy. Deletion does not erase historical consumption, and a user covered by another applicable policy may continue consuming credits under that policy. Deleting the pilot policy should therefore not be treated as a universal off switch.
The default Auto-apply new services setting is equally significant. It allows future supported Copilot services and agents to inherit the policy automatically. Leaving it enabled is a choice to extend an existing spending authorization as Microsoft expands the service list; disabling it keeps those additions subject to manual review. Either can be appropriate, but the selection should match the organization’s approval process.
Work IQ spending policies are limits, not reserved credit pools
A policy specifies who may consume credits, which services it covers, and how much consumption is permitted. Microsoft explicitly says policies do not reserve or allocate credits to users or groups. Creating a departmental policy with a particular limit therefore does not set aside an equivalent amount of purchased capacity exclusively for that department.
The default policy’s limit is also not a universal ceiling over every later policy. Microsoft documents that additional spending policies have independent limits and do not inherit the default tenant-level limit. A finance team looking only at the initial policy could consequently misunderstand the total consumption authorized across the organization.
Overlapping membership has a defined precedence rule. When multiple policies cover the same user and service, Microsoft selects the policy with the highest per-user limit. Ties are broken by the largest overall policy limit, then by the most recently created policy. If a policy has no per-user limit, its overall limit supplies the comparison value. The selected policy applies in full; the system does not combine the strictest settings from every applicable policy.
That behavior changes how administrators should review exceptions. Adding someone to a small pilot group does not necessarily place that person under the pilot’s tighter allowance if another applicable policy wins the selection. Review overlapping security-group membership alongside the policy values before concluding that a proposed cap is effective.
Microsoft also says users who reach their assigned policy limit do not automatically fall back to another policy. Moving between groups during the billing period does not reset their consumption history, either. Previously consumed credits remain accounted for when the new policy becomes effective. These rules prevent policy changes from functioning as an automatic fresh monthly allowance.
Budget limits have a service consequence: Microsoft’s documented behavior is that users reaching a limit lose access to the affected agents and services until the monthly reset or an appropriate policy change provides further access. Administrators should therefore choose alert thresholds early enough for someone to make a deliberate decision about additional consumption. A spending limit is an operational availability setting as well as a financial control.
Copilot Credits require two views of Work IQ costs
Microsoft’s licensing guide divides API consumption into a variable component for Chat and Context and a fixed component for Tools. It lists 0.1 Copilot Credit per Tools API call; Chat and Context consumption depends on factors including models, runtime, context, and tools. That fixed figure is not a universal price for a complete agent task.
The useful cost model is therefore based on representative work, not just a count of employees or prompts. For a proposed application, identify which interfaces it invokes and examine actual credit consumption for its intended tasks. The recommendation follows from Microsoft’s variable-consumption model: a single “cost per request” estimate would conceal differences in the operations performed.
Funding and permission to spend must also be considered separately. Microsoft says policies consume applicable prepaid credits before moving to pay-as-you-go. Its Copilot Credit Pre-Purchase Plan is layered on top of pay-as-you-go, with consumption continuing on that basis after prepaid capacity is exhausted. Exhausting a prepaid balance should not be mistaken for a spending stop.
The documentation distinguishes existing capacity packs from subscription-linked pre-purchase plans. For capacity-pack deployments, it directs administrators to enable a pay-as-you-go meter if they want service to continue when prepaid credits run out. The practical decision is whether continuity beyond prepaid capacity is intended, and which policy limits constrain that continuation.
Microsoft 365’s Cost Management dashboard provides the operational view: consumption can be examined by policy, user, group, service, agent, and funding source. Its Consumption tab exposes policy status, active users, credits used, limit utilization, and billing method. “Active users” means users generating consumption during the selected period, rather than everyone eligible under the policy.
Historical interpretation requires care because the dashboard’s displayed spending limit reflects the policy’s current configuration, even when an earlier reporting period is selected. A later increase to the limit can therefore change the context in which older usage is presented. Supported reader roles allow finance and operations staff to inspect consumption without receiving authority to modify spending policies or billing configuration.
What this means for Work IQ developers and administrators
Start with a restricted deployment tied to a defined application task, rather than enabling organization-wide consumption solely because the API no longer requires a Copilot seat. The documented controls support that approach: group scope establishes eligible users, service selection identifies what they may consume, delegated identity governs data access, and reporting shows the resulting usage.
For developers, the first decision is whether the intended interface actually supports the task. For administrators, it is whether the correct users and subscription are covered without unintended policy overlap. For budget owners, it is whether prepaid capacity is meant to transition into further pay-as-you-go consumption. These decisions should be made together because each can determine whether a technically valid request is useful, authorized, and affordable.
- Treat custom Work IQ API consumption separately from native Copilot use when assessing licensing and costs.
- Design for delegated Microsoft Entra authentication; do not assume application-only credentials will work.
- Customize the initial policy before activation, because the documented default covers the whole organization.
- Review overlapping policies and Auto-apply new services before relying on a pilot’s spending boundary.
- Validate an actual data operation and examine recorded consumption, rather than treating successful authentication as the end of testing.
- Decide explicitly whether consumption should continue after prepaid credits are exhausted, and configure limits and alerts accordingly.
Work IQ pay-as-you-go gives organizations a route to fund programmatic Microsoft 365 intelligence according to consumption rather than preassigning Copilot seats for that access. The immediate opportunity is a controlled application deployment with clear user identity, a deliberately selected billing policy, and measured usage. Expansion should follow evidence from that deployment: successful operations, acceptable results, and consumption the organization is prepared to fund.