Work IQ APIs go GA on June 16 with a Microsoft 365 agent pricing model

Microsoft announced on June 2, 2026, through the Microsoft 365 Blog that Work IQ APIs will reach general availability on June 16, 2026. The company describes Work IQ as the workplace intelligence layer behind Microsoft 365 Copilot and agents. Its data scope includes email, calendar, meetings, chats, files, people, collaboration patterns, and line-of-business systems. For developers, the announcement is not just another Microsoft Graph extension. It packages Microsoft 365 work context, actions, state, authentication, auditability, and usage billing into one agent-facing API surface.

Microsoft's official Build 2026 blog placed Work IQ inside a broader Microsoft IQ architecture used across GitHub Copilot, Microsoft Foundry, and Copilot Studio. In that stack, Work IQ handles workplace intelligence, Fabric IQ handles structured business data, Foundry IQ handles enterprise knowledge and live web retrieval planning, and Web IQ provides MCP-native web grounding. Microsoft is separating Work IQ because Microsoft 365 agents need to understand how work happens inside an organization, not only retrieve documents from a storage system.

The Work IQ API surface is split into four domains. Chat returns Microsoft 365 Copilot-style answers and citations programmatically. Context returns the source data and context Copilot would use, shaped for agent consumption. Tools exposes Microsoft 365 entities and actions such as sending email, scheduling meetings, and uploading documents through stable verbs and resource paths. Workspaces gives long-running agents a Microsoft 365 tenant-bound place to store intermediate state, files, memory, progress, and outputs.

The Work IQ API overview on Microsoft Learn is more specific about protocol choice. Use A2A when another agent needs to delegate work to Work IQ and receive a structured result. Use MCP when a user-facing LLM client, such as GitHub Copilot or an IDE assistant, should call Work IQ as a tool. Use REST when an app or backend calls Work IQ directly and renders the response in its own UI, although the preview documentation marks REST as coming soon. That split asks developers to identify the execution actor and permission boundary before choosing a protocol.

Microsoft 365 Blog says Work IQ folds tool calling into "10 generic tools" and uses MCP progressive disclosure so agents do not need to learn hundreds of data-specific tools up front. The practical developer issue is familiar: enterprise agents often fail because every business system adds another tool schema, and the model cannot reliably decide which tool to call. Microsoft is trying to move more of the context packaging and tool selection burden into the Work IQ runtime instead of leaving it entirely in the orchestration layer.

Microsoft also published several performance claims in the announcement. It says Work IQ covers an average data footprint of more than 600TB in Fortune 500 organizations. It also shows internal figures claiming Work IQ APIs are 2x faster at runtime than traditional APIs and use 80% fewer tokens in an internal coding harness test. These are not independent benchmark results. The useful signal is how Microsoft is selling Work IQ: less as raw access to more data, and more as a way to reduce latency and token budget when agents work inside Microsoft 365.

The security model is one of Work IQ's main selling points. Microsoft says data, context, and insights remain inside the Microsoft 365 tenant trust boundary, while agent actions are auditable and discoverable. Microsoft Learn says requests run in the signed-in user's context and automatically apply Microsoft 365 permissions, sensitivity labels, and compliance policies. Authentication uses Microsoft Entra ID delegated authentication and supports the on-behalf-of flow. The same documentation says application-only authentication is not supported.

That limitation may frustrate enterprise platform teams, but it clarifies what Work IQ is. A conventional backend service often uses application permissions so a daemon or batch worker can scan organization data. Work IQ is closer to an agent acting on behalf of a user inside Microsoft 365. The default model is not "my service can read the tenant." It is "this signed-in user can ask an agent to read and act on information the user is allowed to access." Teams building internal agent platforms should verify whether their service-account architecture can map to that delegated model.

The Work IQ CLI and MCP server matter separately for developer tooling. The microsoft/work-iq repository describes Work IQ plugins, MCP servers, skills, and tools as a way to connect AI assistants to Microsoft 365 data. Its description also says the WorkIQ CLI and MCP Server need consent for permissions requiring tenant admin rights before they can access Microsoft 365 tenant data. That makes this a security-reviewed connector, not a package that an individual developer should quietly add to an enterprise workflow.

The use case intersects directly with the current AI coding assistant market. As tools such as Cursor, Claude Code, Codex, and GitHub Copilot do more work inside repositories, developers want agents to pull context from meeting notes, issue discussions, product documents, customer email, and org charts. Work IQ MCP is aimed at requests such as: summarize the launch risks discussed in Teams last week, find the related OneDrive documents, and reflect them in the pull request description. That request needs permissions, citations, freshness, and audit logs more than it needs a simple search endpoint.

Pricing is a separate news item in this release. Microsoft 365 Blog says Work IQ APIs use consumption-based pricing, with a fixed component for Tools and variable components for Chat and Context. The unit is Copilot Credits. Microsoft's licensing page for Work IQ GA also says that, starting June 16, 2026, Work IQ API usage will be billed through a Copilot Credits consumption model. Read alongside GitHub Copilot's June 1 move toward AI Credits, Microsoft is moving more agent products from seat-only pricing toward explicit usage accounting.

Microsoft paired the API announcement with a cost management dashboard for that reason. In the Microsoft 365 admin center, IT admins can view AI credit usage, configure prepaid and pay-as-you-go billing, and set spending limits by tenant, group, or user. Microsoft says Work IQ APIs are the first product managed through this experience, and that additional products such as Copilot Studio will be added later. For organizations where agents run repeatedly, pre-execution spending policy will matter more than inspecting a monthly invoice after the fact.

Community discussion is still centered more on AI Credits than on the Work IQ API itself. Hacker News and GeekNews did not show much standalone discussion of Work IQ APIs when the Korean article was prepared. Reddit had smaller posts introducing the Work IQ CLI and MCP preview as Microsoft 365 data access tools, while complaints and cost calculations around GitHub Copilot usage-based billing after June 1 were more visible. That reaction suggests Work IQ may be technically framed as an enterprise context API, but adoption conversations will quickly become questions about how often agents read context and how many credits they consume.

The first design question for development teams is which API domain to use. If the product needs a Copilot-style answer for an employee question, Chat is the fastest route. If a custom agent needs grounded materials for its own planning or workflow, Context is the better fit. If the agent needs to perform real work, Tools becomes necessary. If a long-running agent needs to preserve intermediate files or state, evaluate Workspaces. Turning on all four domains is convenient, but it also expands the permission review and cost tracking surface.

The second question is protocol boundary. A2A fits agent-to-agent delegation. MCP fits AI assistants embedded in IDEs, CLIs, or Copilot-style clients that fetch context on behalf of the user. REST fits a service with its own UI and workflow that treats Work IQ as a backend dependency. Microsoft exposes similar capabilities through multiple protocols because the agent's runtime location, user context holder, and response renderer differ across organizations.

The third question is permission trimming. Work IQ's promise to follow Microsoft 365 permissions and sensitivity labels is a strength, but it can create surprising UX. The same question may produce different answers for user A and user B. One user may receive incomplete context because a relevant document is not visible to them. When an agent says no material was found, the UI needs to distinguish "the material does not exist" from "the signed-in user cannot access it." Without that distinction, developers will confuse retrieval quality problems with permission problems.

The fourth question is the audit artifact. Microsoft says Work IQ agent operations are auditable and discoverable. In enterprise agent systems, that is an operating requirement rather than a feature bullet. Teams need to reconstruct which question read which context, which tool action ran, who approved it, and which workspace retained intermediate output. For the Tools domain, actions such as sending email, scheduling meetings, and uploading documents cannot be audited through a chat transcript alone.

The fifth question is cost attribution. Work IQ APIs have different pricing structures across Tools, Chat, and Context. If one agent run reads three meetings, five Teams threads, and 12 OneDrive documents, then asks for a Copilot answer and drafts an email, the cost may not appear as one tidy "agent run." Microsoft's dashboard supports tenant, group, and user spending limits because agent costs need organizational ownership. Product teams should decide before launch whether Copilot Credits are attributed to a user, team, workflow, customer account, or internal cost center.

The timing of Work IQ also connects to Microsoft's other Build 2026 governance announcements. On the same day, the Microsoft Foundry Blog introduced ASSERT and the Agent Control Specification as open approaches for agent evaluation and runtime control. Work IQ is the Microsoft 365 data and action plane. ASSERT and ACS are closer to policy and control planes. Together, they show Microsoft's enterprise agent strategy shifting from model access alone toward context, actions, governance, and billing.

The competitive set includes Google Workspace, Salesforce Agentforce, and ServiceNow AI agents. Each tries to turn organizational data into agent context, preserve the existing SaaS permission model, and continue into work actions. Work IQ's advantage is the density of collaboration data inside Microsoft 365 and the existing Copilot distribution base. Its constraints are the Microsoft 365 tenant boundary, delegated-auth-first model, and Copilot Credits predictability. In multi-SaaS organizations, Work IQ will not replace every business context system by itself.

For teams building agents inside Microsoft 365, Work IQ deserves evaluation before a custom Graph sync job, vector database, or connector layer becomes the default architecture. The evaluation order should not start with model intelligence. It should start with who can read which data, which protocol invokes the API, which actions leave audit records, and which Copilot Credit limits govern repeated runs. Work IQ can reduce context integration work, but it does not choose the organization's permission design or cost accountability model.

Three signals are worth checking after GA on June 16. First, whether REST and Remote MCP availability changes from the preview documentation. Second, whether Microsoft's internal claims of 2x speed and 80% token reduction turn into customer case studies or independent measurements. Third, whether the Copilot Credits dashboard explains per-run, per-user, and per-team agent costs well enough for real workflows. As agents move into business systems, pricing tables and audit logs may decide adoption speed as much as the API surface.