Microsoft Just Shipped Work IQ APIs. Here's What I'd Build — and Why I Haven't Yet.

Microsoft's Work IQ APIs went generally available on June 16. That was one week ago. I've been thinking about them since — not because they're not interesting, but because the specific thing I want to build has a cost question attached to it that I haven't resolved yet. This post is me working through both sides of that out loud.

What Work IQ Actually Is

Work IQ is Microsoft's semantic intelligence layer for Microsoft 365. It continuously indexes what your organization does inside M365 — emails, calendar events, meetings, chats, document edits, file co-authorship, collaboration frequency between people — and builds a live model of how work actually flows. Not just what's stored, but who interacts with whom, how often, and in what context.

The APIs expose that model in three ways: a REST API, a redesigned remote MCP server, and an A2A (agent-to-agent) protocol. Call the REST endpoint for a specific user and you get structured data back: their reporting line, their team membership, who they collaborate with most frequently, what documents they're currently active on, what their calendar density looks like. Not a search result — a structured organizational profile, queryable on demand.

It went through developer preview for roughly a year before going GA. The MCP server and A2A protocol support were added at Microsoft Build 2026 in early June. From a tooling standpoint, if you're already running agents in your environment — through n8n, Copilot Studio, or direct API calls — Work IQ is now a real callable data source, not a roadmap item.

The IT Support Use Case I Keep Coming Back To

When a new IT support ticket lands in my queue, I know three things: who filed it, what they wrote, and which tool it came in through. That's the full context I'm working with at triage. It's thin. I can look up the person's department in Active Directory or their deal stage in the CRM if it's a customer ticket. But for internal employee tickets, the AD entry tells me their job title and their group memberships, which often isn't enough to understand the urgency or the blast radius of their problem.

Work IQ would change that. For an internal ticket, I could query the API and get back: their manager, which team they sit in, which three to five people they collaborate with most frequently, what files they've been active on in the last week, and whether their calendar is packed or quiet right now. That's a qualitatively different starting point for triage. A calendar-dense week suggests their issue is probably time-sensitive. A tight collaboration graph with five other people means if the issue is environmental, those five people may be affected too.

The difference between a 30-minute resolution and a 2-hour one is often context you didn't have at ticket open. For internal IT tickets filed by employees, Work IQ is the context layer I've been missing.

A Recent Example That Made Me Want This

Two weeks ago I spent about 45 minutes troubleshooting an authentication issue that turned out to be a shared OAuth token affecting an entire project team. I diagnosed the first person's problem, fixed it, and closed the ticket. The next morning, three more tickets landed — same root cause, different people. All of them worked closely together on the same project. If I'd known at the start that the first person had a tight collaboration cluster of four colleagues on an active shared project, I would have checked whether the issue was isolated or shared before closing anything.

Work IQ doesn't tell me about the OAuth token. But it would have told me about the collaboration cluster. That's the signal I was missing.

What I Actually Want to Build

The build is a straightforward extension of an n8n workflow I already run. When a new ticket arrives in Help Scout, I have a workflow that checks whether the sender matches a known customer in Pipedrive, then appends their deal stage, owner, and last activity as an internal note before the support agent opens the ticket. That's the customer-facing side.

For internal IT tickets, I want a parallel branch: if the email domain matches our internal domain, call the Work IQ REST API with the sender's email, get back their organizational profile, and post it as a separate internal note. Manager, team, top collaborators, recent file activity. Same pattern, different data source. The agent opens the ticket and immediately has context from two directions.

The n8n piece is not the hard part here. The REST API call, a JSON parse, a Help Scout internal note — that's an hour of work at most. The part I'm sitting with is the cost model.

The Cost Question

Work IQ uses Copilot Credits with consumption-based pricing. There's a fixed component for Tools and a variable component for Context queries, which is exactly what I'd be running — a context profile request per ticket. Microsoft launched a Cost Management dashboard in the M365 admin center alongside the GA (also June 2026) that lets admins set spending limits by tenant, by group, and by individual user. That's a useful guardrail. But I don't have real-world data on what a single Work IQ Context query actually costs in credits, at the volume of tickets I process in a week. The pricing model is published. Production benchmarks from people running this at scale are not yet available publicly.

For a light-volume environment — say, a 50-person company with 20 IT tickets a week — the math is probably easy. For higher volumes, the monthly credit spend could be substantial, and I want to see real numbers before I build a workflow that fires unconditionally on every ticket.

My current plan: gate the Work IQ enrichment on ticket priority. Priority 1 and Priority 2 tickets get the full organizational context pull. L1 volume — password resets, printer issues, VPN reconnects — does not. That limits the credit exposure while still covering the cases where context actually changes what I do. After 90 days of data, I'll recalibrate the threshold.

The MCP Server Is the More Interesting Part

I'm more interested in the remote MCP server than the REST API, honestly. I already have Claude running inside n8n workflows via MCP — the n8n native MCP server has been in production since April. If I can register the Work IQ MCP server as an additional tool in the same agent setup, the agent can decide when to pull organizational context rather than me hard-coding that call into a fixed workflow step. The agent would have a "get_work_context" tool available and use it when it thinks context would help its triage decision. That's a better architecture than a fixed enrichment step that runs unconditionally.

The A2A protocol support matters too, longer term — it means Work IQ can participate in multi-agent pipelines where one agent hands off to another, passing context with it. For an IT support environment that's slowly adding agent steps to its escalation paths, that's the direction things need to go.

What This Means for M365 Admins Right Now

If you're managing a Microsoft 365 environment today, Work IQ APIs add a new layer to your admin responsibilities: the organizational intelligence graph and its associated credit spend. The M365 admin center now has cost management controls for AI credit usage — this is a new category of governance that didn't exist six months ago. For teams that have been adding Copilot licenses and building Copilot Studio agents through 2025 and early 2026, the credit usage dashboard is becoming a real operational concern, not just a finance line item.

The time to set spending limits and understand the billing model is before you've built workflows that query Work IQ at scale, not after. The Cost Management dashboard is there. Use it before you're chasing an unexpected overage.

Three Things I'm Watching Over the Next 90 Days

• Real cost benchmarks from the community. The pricing model is published. What I need is actual per-query credit data from people running Work IQ Context requests in production at meaningful volume. That data doesn't exist publicly yet — but it will within a few months.
• Whether n8n ships a native Work IQ node. They added the MCP Server node in April and moved quickly when the API went GA. A dedicated Work IQ node — with built-in authentication and response mapping — would significantly reduce the build time for the workflow I described above.
• First-contact resolution data from early adopters. The claim I want tested: does richer organizational context at ticket open actually improve FCR for internal IT support? My instinct is yes, particularly for issues with a shared root cause. But instinct is not a number. I want to see someone publish their before-and-after FCR data after running Work IQ enrichment for a quarter.

The APIs are real and the use case is clear. The only thing standing between me and shipping the workflow is cost data I don't have yet. If you're running IT support inside an M365 environment and you've started experimenting with Work IQ, I'd genuinely like to compare notes — especially on the credit spend side. Reach out here.