The demos worked. The engineering bill arrived afterwards.<\/p>\n\n\n\n
Connectors need maintenance. Indexes fall behind. Retrieval quality changes as content grows. Permissions are even less forgiving: a system that gets access control right 99% of the time is not nearly good enough.<\/p>\n\n\n\n
That is why Work IQ caught my attention. It reached general availability on June 16, 2026, but the announcement itself was not the interesting part for me. I was more interested in the code I might no longer need to own: sync jobs, custom indexes, permission-trimming logic and the long list of edge cases that appear when a prototype becomes a client-facing application.<\/p>\n\n\n\n
This series is my attempt to understand whether Work IQ genuinely removes that work or simply moves it behind another SDK.<\/p>\n\n\n\n
In this first part, I will explain the mental model that clicked for me and make the smallest useful call from C#. Part 2<\/a> adds the A2A SDK, multi-turn context and streaming. Part 3<\/a> moves from delegated answers to MCP tools.<\/p>\n\n\n\n Version note:<\/strong> The API details in this article were checked against the Microsoft documentation available in July 2026. Work IQ is moving quickly, so check the linked documentation before copying preview-specific code into a production project.<\/p>\n<\/blockquote>\n\n\n\n Imagine an agent that can answer this:<\/p>\n\n\n\n Catch me up on the Contoso migration. What changed, who owns the open actions, and what did we agree in the last review?<\/p>\n<\/blockquote>\n\n\n\n The impressive demo is the final answer, the difficult system sits behind it.<\/p>\n\n\n\n To answer properly, the agent may need information from email, Teams chats, meeting transcripts, SharePoint, OneDrive and the organisation directory. A traditional implementation usually grows into something like this:<\/p>\n\n\n\n Retrieval gets most of the attention because it is easy to demonstrate. Permission trimming deserves more.<\/p>\n\n\n\n A stale result is annoying. A result containing a document the user should not see is a security incident.<\/p>\n\n\n\n That failure rarely arrives as a helpful exception. The application still returns a fluent answer. The problem is that one of its sources crossed a sharing boundary, sensitivity label or access rule that your custom pipeline did not model correctly.<\/p>\n\n\n\n This is where several of my prototypes stopped feeling like AI projects and started feeling like data-governance projects.<\/p>\n\n\n\n My first assumption was that Work IQ would be Microsoft Graph with a more conversational endpoint.<\/p>\n\n\n\n That is not how I think about it now.<\/p>\n\n\n\n Graph gives your application data<\/strong>. You call \/me\/messages, receive messages and decide what to do with them.<\/p>\n\n\n\n Work IQ gives an agent access to Microsoft’s understanding of work<\/strong>. It combines Microsoft 365 data with context, permissions and reasoning so the caller can ask a work-shaped question rather than manually reconstructing the answer from several APIs.<\/p>\n\n\n\n That difference sounds small until you build both versions.<\/p>\n\n\n\n With Graph, the application owns retrieval, ranking and synthesis. With Work IQ Chat, the application can hand over the question and receive a grounded answer with citations. The request still runs as the signed-in user, so existing Microsoft 365 permissions and compliance controls remain part of the boundary.<\/p>\n\n\n\n The simplest comparison I can offer is this:<\/p>\n\n\n\n Both are useful. They solve different problems.<\/p>\n\n\n\n Microsoft describes Work IQ through four connected components. I find it easier to think about them in terms of what an agent needs.<\/p>\n\n\n\n The distinction between Chat and Tools is especially important.<\/p>\n\n\n\n Sometimes you want to delegate the whole problem:<\/p>\n\n\n\n Find the latest decisions about this project and summarise them.<\/p>\n<\/blockquote>\n\n\n\n At other times, your own agent is already doing the reasoning and only needs a capability:<\/p>\n\n\n\n Read these messages, create a draft and schedule a follow-up.<\/p>\n<\/blockquote>\n\n\n\n The first is a conversation with Work IQ. The second is tool use. I confused those models initially, and separating them made the rest of the API much easier to understand.<\/p>\n\n\n\n If you already have a RAG solution over Microsoft 365, Work IQ does not automatically make the whole architecture irrelevant. You may still need your own model, domain data, prompts, workflows or non-Microsoft connectors.<\/p>\n\n\n\n What it can remove is the part many teams would rather not rebuild:<\/p>\n\n\n\n For the private AI application we have been developing, this is the interesting trade-off. Every component we remove is one less component that can drift, fail or expose information incorrectly.<\/p>\n\n\n\n It also changes what the team spends time discussing. Instead of asking, “How do we keep this connector and index in sync?”, we can spend more time on the behaviour of the agent itself.<\/p>\n\n\n\n That is a better engineering problem.<\/p>\n\n\n\n Work IQ exposes the same underlying intelligence through different interaction models.<\/p>\n\n\n\n I am starting with A2A<\/strong> because it makes the delegation model visible. We will send a message to Work IQ and receive a task containing a grounded answer.<\/p>\n\n\n\n For a normal web application, REST may feel more familiar. For an agent that wants individual Microsoft 365 capabilities, MCP is usually the more interesting surface.<\/p>\n\n\n\n There is no single correct protocol. The question is: who is doing the reasoning?<\/p>\n\n\n\n This is one area where old preview guidance can mislead you.<\/p>\n\n\n\n As of July 2026, custom use of the Work IQ API is billed through a consumption-based model using Copilot Credits<\/strong>. Microsoft states that there is no separate Work IQ API subscription, SKU or per-user licence for this API usage. Administrators enable and govern consumption through the Microsoft 365 admin centre, including access policies, spending limits and alerts.<\/p>\n\n\n\n Microsoft 365 Copilot’s prebuilt experiences follow their own licensing treatment. Custom agents built through Copilot Studio, Foundry or third-party platforms can incur Work IQ API consumption.<\/p>\n\n\n\n In other words, do not copy a preview-era setup guide and assume the licensing section still applies. Confirm billing and access in the tenant before debugging the code.<\/p>\n\n\n\n Work IQ changed quickly between preview and general availability. Endpoints, permissions and samples did not all move at exactly the same pace.<\/p>\n\n\n\n When I first worked through the examples, I found it useful to compare three things rather than trusting one page in isolation:<\/p>\n\n\n\n\n
The hard part was never the demo<\/strong><\/strong><\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/codingwithramin.com\/wp-content\/uploads\/2026\/06\/part1_1.png\")
<\/figure>\n\n\n\n\n
\n
The mental model that finally clicked<\/strong><\/strong><\/h2>\n\n\n\n
\n
The four parts of Work IQ<\/strong><\/strong><\/h2>\n\n\n\n
\n
\n
\n
How it changes a custom RAG architecture<\/strong><\/strong><\/h2>\n\n\n\n
\n
Choosing the right protocol<\/strong><\/h2>\n\n\n\n
Protocol<\/th> I would use it when\u2026<\/th> Typical caller<\/th><\/tr><\/thead> A2A<\/strong><\/td> One agent needs to delegate a structured task to Work IQ<\/td> Another agent<\/td><\/tr> REST<\/strong><\/td> An application or backend needs a request\/response integration<\/td> Web app, service or orchestrator<\/td><\/tr> MCP<\/strong><\/td> A model-driven client needs Work IQ capabilities as tools<\/td> Custom agent, IDE assistant or agent platform<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Licensing after general availability<\/strong><\/strong><\/strong><\/h2>\n\n\n\n
A note before copying samples<\/strong><\/strong><\/strong><\/strong><\/h2>\n\n\n\n