DIE AGENTINNICOLENDERS.COM
DEEN
← Dispatches

AnalysisTHE CONNECTORTHE HANDLER

Work IQ, the layer underneath

Published

Blank documents on a light table, with a glowing web of fine threads connecting them underneath.AI generated
Work IQ in Microsoft Copilot StudioMicrosoft Learn

The most common reason an agent convinces in testing and disappoints in daily use is not the model. It is missing context.

In testing somebody asks: "What is the holiday request process?" In daily use somebody asks: "Can I still move Thursday's meeting if Kerstin is away then?" The second question needs calendars, absences, responsibilities and the history of a case. That gap is what Work IQ is meant to close.

What Work IQ is

Work IQ is the intelligence layer that grounds Microsoft 365 Copilot and your agents in shared real-time context. It connects signals across the Microsoft 365 ecosystem and business systems, enabling personalised search and deeper semantic understanding, and from there recommendations and actions.

In practice that means an agent gets access to emails, calendar entries, files, Teams messages and people information without you building a connection for it.

Anyone who has been around a while will hear Microsoft Graph in that. The difference is the level. The Graph delivers objects and you build the meaning. Work IQ delivers the meaning with it: who works with whom on what, what belongs together, what is currently relevant.

Work IQ is part of a larger family. Under the Microsoft IQ umbrella sit Web IQ for live web grounding, Fabric IQ for data and semantic models, and Foundry IQ as the knowledge layer behind Foundry agents.

Why this reframes the collaboration question

I have worked on collaboration in organisations for more than fifteen years, and the quiet constant was always the same: the context exists, but scattered. A case lives in an email, a Teams conversation, two files and a calendar entry, and the connection between them exists only in one person's head.

Every generation of tools has tried to fix this. Portals were going to bundle everything. Search was going to find everything. Teams was going to bring everything into one place. Each time, the work of connecting stayed with the human.

Work IQ is the first serious attempt to establish that connection mechanically and offer it as a service. Whether it holds I do not know yet. That it is the right place to intervene seems obvious to me.

There is a flip side that belongs to my role as DIE ARCHIVARIN: a layer that reads across everything an organisation has in the way of communication is the most powerful data layer anybody has ever had in a tenant. Permissions are carried through, that is the assurance. Even so: what a human would never have found, because it sat in a three-year-old channel, an agent finds in seconds. That is not a permissions problem, it is an expectations problem, and you should discuss it before somebody notices it.

Where Work IQ attaches

In Copilot Studio, Work IQ hangs off the GitHub Copilot harness and is billed by consumption through Copilot Credits. Through Microsoft IQ you connect an agent in the new experience to organisational data.

In Foundry you reach Work IQ through toolboxes, the managed endpoint for all tool types. Foundry IQ is GA as a standalone knowledge layer and unifies Work IQ, Fabric IQ, Azure SQL, file search and MCP sources behind one retrieval endpoint with an SLA.

There is a neighbour that in practice gets mentioned in the same breath: the Windows 365 for Agents MCP server is GA and gives agents full control of a Windows 365 Cloud PC, including desktop interaction, browser automation and semantic UI inspection.

The contradiction I cannot resolve

This is where it gets murky, and I would rather write it down than smooth it over.

The Build 2026 announcements list Work IQ as GA. The Copilot Studio documentation on Microsoft Learn lists Work IQ in Copilot Studio as preview. The Foundry blog lists Work IQ in toolboxes as preview too, while Foundry IQ there is GA.

Both can be true at once if the service is GA and individual integration paths are not. That is presumably exactly what is happening. For you it means: maturity depends on the surface you access it through, not on the name. Check the state for your specific path before you make a commitment, and write down the date you checked.

The question to settle before rollout

Work IQ hangs off the GitHub Copilot harness in Copilot Studio, and that bills by consumption through Copilot Credits. Context is therefore a per-request line item, not a one-off effort.

What I cannot say with certainty is how much of it remains included in the Microsoft 365 Copilot licence and how much is billed separately. The Copilot Studio licensing materials are moving faster than the product documentation at the moment, and the two are not always aligned.

This is not an academic question. Work IQ is precisely the reason an agent becomes useful. A model without organisational context answers general questions. One with context answers the questions people actually ask. If that capability is billed per call rather than sitting in the seat licence, it changes the arithmetic considerably for any broadly deployed agent.

Get hold of the current licensing guide before you build an architecture on it, and work the numbers before you roll it out broadly.

What I would recommend

  1. Start small. One agent, one department, one clearly bounded task. Work IQ makes answers more specific, and specific answers are also more specifically wrong.
  2. Measure how it runs without it first. Otherwise you cannot say afterwards whether the context helped or the new model did.
  3. Bring the works council and data protection in early. Not as a formality. A layer that evaluates communication patterns touches questions you do not settle retroactively.
  4. Keep per-call cost in view. Context is a cost item per request, not a one-time expense.
  5. Document the maturity of your specific path. With a date. For a capability that is GA or preview depending on the surface, that is not overcaution.

Sources

Copilot Studio · Governance & Compliance