If you’ve built an enterprise agent that needs to understand what’s actually happening inside an organization \u2014 who’s working on what, what was decided in last week’s meeting, which document is the latest version of the proposal \u2014 you already know the hard part isn’t the model. It’s the context.<\/p>\n\n\n\n
I’ve spent a good chunk of the last year on exactly this problem. In my SharePoint agents series<\/a> I grounded an agent in SharePoint content, and more recently I added long-term memory to Foundry agents<\/a> so they’d stop forgetting everything between turns. Both worked. Both also meant I was building and maintaining plumbing: connectors, indexing, retrieval, and \u2014 the part nobody enjoys \u2014 permission trimming, so the agent never surfaces something the user isn’t allowed to see.<\/p>\n\n\n\n Work IQ is Microsoft’s answer to that plumbing. Microsoft says the Work IQ APIs<\/strong> go generally available on June 16, 2026<\/strong>, and honestly it’s the missing piece I kept wishing Microsoft would expose. This post is the first in a short series on building with it. In this one I’ll explain what Work IQ actually is, how it’s different from the approaches you might be using today, and make a first grounded call from C#. Later posts will build a proper agent with the A2A SDK, wire Work IQ in as MCP tools, and look at long-running agents with Workspaces.<\/p>\n\n\n\n Say you want an agent that can answer: “Catch me up on the Contoso migration \u2014 what’s the latest, who owns it, and what did we agree in the last review?<\/strong>“<\/em><\/p>\n\n\n\n To answer that well, the agent needs to pull from email, Teams chats, meeting transcripts, files in SharePoint and OneDrive, and the org chart, then reason across all of it. The usual approach looks something like this:<\/p>\n\n\n\n Steps 3 and 4 are where a lot of these projects start to fall apart. Permission trimming is especially nasty. Sensitivity labels, conditional access, sharing boundaries, odd edge cases around who can see what. If you get it almost<\/em> right, that’s worse than not doing it at all, because now you’ve built something that looks polished and quietly leaks data.<\/p>\n\n\n\n Work IQ is the intelligence layer behind Microsoft 365 Copilot, exposed as a developer API. The important distinction is that it doesn’t just hand you raw data and leave the reasoning to you. It exposes intelligence<\/em>. You ask a question in natural language, it does the assembling, grounding, and reasoning internally, and it returns a Copilot-quality answer with citations, all inside your tenant’s existing security and compliance boundary.<\/p>\n\n\n\n Microsoft introduced it at Build 2026 as one of a family of “IQ” services: Work IQ for organizational intelligence, alongside Foundry IQ, Fabric IQ, and Web IQ. Work IQ is the one that understands your work<\/em>: emails, meetings, chats, files, people, and the relationships between them.<\/p>\n\n\n\n It’s organized into four domains, and the names are worth learning because they line up pretty neatly with what agents usually need:<\/p>\n\n\n\n If you’ve used Microsoft Graph, the obvious question is: isn’t this just Graph with a nicer wrapper? It isn’t, and that difference is the whole point.<\/p>\n\n\n\n With Graph<\/strong>, you get data<\/em>. You call \/me\/messages<\/strong>, you get messages back, and all the reasoning about what matters, how it connects, and what the answer should be is on you. With Work IQ<\/strong>, you get answers<\/em>. The reasoning happens server-side, with the same grounding quality you see in Copilot.<\/p>\n\n\n\n If you’ve built your own RAG<\/strong> over Microsoft 365 content, Work IQ removes the four hardest parts: you don’t manage a vector store, you don’t run sync jobs, you don’t re-implement permission trimming, and you don’t own retrieval ranking. Responses are permission-trimmed by design. Every request runs in the context of the signed-in user, and because the API exposes intelligence rather than raw data, an app can’t<\/em> accidentally sidestep tenant security. That’s the part I think matters most.<\/p>\n\n\n\n If you used the older Copilot Chat API<\/strong> during preview, Work IQ is the production-ready version of that direction. Same general idea, but now with enterprise SLAs and stable contracts. If you’re starting something new, this is the one to build on.<\/p>\n\n\n\n Work IQ fits into a few different architectures. The same intelligence runtime is exposed through several protocols, so the grounding and response quality stay consistent whichever one you choose:<\/p>\n\n\n\n For this series I’m starting with A2A<\/strong>, because it’s the most agent-native of the three and it makes the model easy to see. Your code sends a message, Work IQ responds as a peer with a grounded answer. We’ll cover MCP in Part 3 and REST in Part 4.<\/p>\n\n\n\n This part tripped me up, so it’s worth calling out. During the public preview, Work IQ access leaned on a Microsoft 365 Copilot add-on license, and the sample errors are not especially helpful if that license isn’t there yet or hasn’t fully propagated.<\/p>\n\n\n\n At GA (June 16), that changes: Work IQ API access is independent of Copilot licensing and billed consumptively through Copilot Credits.<\/strong> Licensed Copilot users get it across their Copilot experiences and are billed consumptively for custom and third-party agents; unlicensed users are billed consumptively too. There isn’t a separate Work IQ SKU or a per-user license, and IT can manage the spend from the Microsoft 365 admin center. In practical terms, if you’re testing against a preview tenant right now, keep the Copilot license assigned and give it 15\u201330 minutes after assignment before expecting solid answers. The index needs a little time to warm up.<\/p>\n\n\n\nThe problem, stated plainly<\/strong><\/h2>\n\n\n\n
\n
What Work IQ is<\/strong><\/h2>\n\n\n\n
\n
How it’s different from what you’re probably doing today<\/strong><\/h2>\n\n\n\n
Choosing a protocol<\/strong><\/h2>\n\n\n\n
Protocol<\/th> Use it when\u2026<\/th> The caller is\u2026<\/th><\/tr><\/thead> A2A<\/strong> (Agent-to-Agent)<\/td> Another agent needs to delegate a task to Work IQ and get a result back<\/td> Another agent<\/td><\/tr> REST<\/strong><\/td> You’re building an app or service that calls Work IQ programmatically<\/td> Your app or backend<\/td><\/tr> MCP<\/strong> (local + remote)<\/td> An LLM-based client (Copilot, an IDE assistant, a custom agent) invokes Work IQ as a tool<\/td> An LLM client<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n A note on licensing (this changed at GA)<\/strong><\/h2>\n\n\n\n
One gotcha before we write code<\/strong><\/h2>\n\n\n\n