Microsoft WorkIQ Deep Dive: Injecting Work Context into AI Agents

In enterprise AI applications, one word keeps coming up at the center of every conversation: context. A model can write clean code and generate polished copy, but it has no way of knowing on its own that you have a meeting in Building 7 at 11 a.m., or what you and your colleagues actually discussed in that meeting. At a developer-facing session, Microsoft formally gave this missing piece a name: WorkIQ—an intelligent layer that provides AI Agents with organizational work context.

This article is based on a live demo session with Microsoft's WorkIQ product team—including developer relations lead Aysha, technical advisor Anthony Shah, and GPM Tolga—and breaks down WorkIQ's positioning, how it differs from Microsoft Graph, and how developers can integrate it into their own Agents.

What WorkIQ Is: Organizational Context That Models Can't Infer on Their Own

At its core, WorkIQ aggregates the scattered work information inside Microsoft 365—meeting notes, emails, Teams messages, PowerPoint decks—into a context layer that models can directly consume.

Anthony demonstrated this with a real scenario from his own life: he typically opens Copilot 20 to 30 minutes before a meeting and asks something like, "What are the five things I need to prepare for my fly meeting with Copilot?" Even with a typo and no mention of the meeting time or date, Copilot correctly identifies the target meeting and surfaces the key details: the meeting is in Building 7, it starts at 11 a.m., he hasn't RSVP'd yet, and he's responsible for presenting the WorkIQ section.

The heavy lifting behind this is done by WorkIQ—it referenced the demo deck, the team's meeting recording, and knew exactly which content each of the three speakers owned. "Organizational context is something a model simply cannot infer from a prompt alone," as Anthony put it, and that sentence captures the fundamental reason WorkIQ exists.

Also worth noting: Anthony demonstrated Copilot's voice capabilities on mobile and mentioned that it's already integrated with CarPlay and Android Auto. While driving his kids to school on the way to the meeting, he asked the same questions out loud—and WorkIQ's context made that possible.

WorkIQ Is Not a Replacement for Microsoft Graph

One question that kept coming up was: is WorkIQ meant to replace Microsoft Graph? The team's answer was a clear no.

Graph has been around for years and exposes over 200 endpoints for specific operations—sending emails, creating calendar invites, retrieving all of someone's messages, and so on. The challenge, however, is that in agentic development, asking an Agent to figure out which of 200+ endpoints to call for a given task is genuinely hard.

WorkIQ's approach is to build an intelligent layer on top of that platform. Rather than dumping a pile of endpoints on the Agent, it provides a set of dynamic tools under the hood that are easier for Agents to understand and select. In other words, Graph is about operations, while WorkIQ is about helping Agents read and make use of work data—they address different layers of the problem.

This design philosophy aligns with the dominant "tool-calling" paradigm: instead of exposing a sprawling set of low-level APIs, abstract them into a semantically clear, manageable toolset that reduces the model's decision burden.

Microsoft Graph is Microsoft's unified REST API gateway. Launched in 2017, it progressively consolidated the previously fragmented APIs across Exchange, SharePoint, OneDrive, Teams, and other product lines. Through a single endpoint (graph.microsoft.com), developers can access nearly all data and services in the Microsoft 365 ecosystem—user profiles, email, calendars, files, groups, Teams channels, and more. Its authorization model is built on OAuth 2.0, supporting both delegated permissions (acting on behalf of a user) and application permissions (for background services with no user interaction). Graph's design philosophy is "one endpoint, all data"—but that also means developers need to be familiar with the semantics and parameters of hundreds of interfaces. In agentic scenarios, asking a model to autonomously select the right Graph endpoint and construct a valid request places significant demands on both reasoning capability and context length. That's precisely the problem WorkIQ aims to solve by building an abstraction layer on top.

Three Integration Options: REST API, A2A, and MCP

For developers, WorkIQ offers three standardized integration channels to accommodate different architectural preferences:

REST API

Ideal for integrating WorkIQ into web or mobile applications. Under the hood, REST calls use the same intelligent toolset, delivering a Copilot-equivalent intelligent experience.

A2A (Agent-to-Agent) Protocol

If you're building multi-agent orchestration—whether via Copilot Studio, Foundry, or a custom SDK—you can use the A2A protocol to incorporate WorkIQ as one Agent node within a collaborative system.

MCP (Model Context Protocol)

WorkIQ is also available as an MCP server, with the same toolset and data as the other channels.

The team emphasized that regardless of whether you're using Copilot Studio, the GitHub CLI, or a fully custom application, the integration path is unified—"there's no difference for builders versus developers." Which channel you choose depends on your Agent architecture and preferences.

On the permissions side, WorkIQ takes an enterprise-grade approach. Administrators can view all WorkIQ MCP tools in the agent configuration section of the admin center and exercise fine-grained control—for example, allowing create and update actions while blocking delete, with full policy tracking. Before integrating a custom Agent, developers register their application in the tenant and select the appropriate WorkIQ permissions (such as WorkIQ agent ask) in the API permissions section, following the principle of least privilege.

MCP (Model Context Protocol) is an open protocol introduced by Anthropic in late 2024, designed to establish a standardized interface between AI models and external tools and data sources. Its core idea is to package three types of capabilities—tools, resources, and prompt templates—into an MCP Server, which client-side models or Agent frameworks can discover and invoke through a unified protocol, without needing custom adapters for each service. A2A (Agent-to-Agent) protocol, introduced by Google in 2025, is a multi-agent collaboration standard that defines how different Agents discover each other, delegate tasks, and pass results. Its core abstractions are the "AgentCard" (metadata describing an Agent's capabilities) and HTTP-based task lifecycle management. WorkIQ's support for both protocols means it can serve as a tool called by a single model, or as an independent Agent node participating in more complex multi-agent workflow orchestration.

Supporting Tools: Open-Source WorkIQ OS and an Interactive Demo

To lower the barrier to entry, the team shipped two important companion resources.

The first is WorkIQ OS—a line-of-business application sample that calls the WorkIQ API directly and will be open-sourced under the MIT license, hosted on GitHub (it wasn't live at the time of the demo, pending legal review). It includes built-in widgets for action items, meeting intelligence, and daily eval, all updated in real time, with full source code included. Developers can swap in their own logo and UI theme and integrate parts or all of it into their own business applications. It also includes developer tools and an inspector view to help you understand which APIs are being called, and you can even hand off configuration work to a GitHub Copilot session running in the browser.

The second is an interactive demo site, described as "the next-generation Graph Explorer." Developers can test tool calls across REST, A2A, and MCP directly in the browser. The most valuable feature is the API log—after each call, you can see the full details including headers, body, and how WorkIQ processed the request. The demo showed querying "who am I" via A2A, fetching a user profile via MCP's fetch tool, and attempting to create a calendar invite using create entity (which hit a small tenant-related snag during the live demo—which, if anything, added to the authenticity).

Real-World Case Study — Margo: A Chief of Staff Agent Managing 250,000 Emails

The most vivid part of the session came from GPM Tolga and the Agent he built: "Margo."

Tolga's pain points were painfully specific: a primary inbox with 250,000 emails, 50,000 unread, over a million messages across all folders, 92 to 120 meeting invitations per week, and a rather absurd KPI he'd started tracking—the number of conflicts within a 25-minute meeting slot, which peaked at 8.

What he originally built wasn't an Agent but a "skill," with the goal of managing a day's worth of meetings and emails and prioritizing them. From day one he set firm rules: take no action without authorization, and always cite sources to prevent hallucinations. He then connected this skill to WorkIQ—because all the data, from emails to Teams messages, lives there.

The tool orchestration logic was clean: use fetch to retrieve metadata and data for reasoning, use retrieve and ask for task grounding, and use do action to create invites, draft and send emails, and post Teams messages. The finished product, Margo, can receive a command like "let me know what's going on right now," automatically check the calendar, locate the meeting, pull the prep meeting recording, and generate a prep summary covering "who to collaborate with and what message to convey."

Margo also supports personalized preferences: all meetings default to starting 5 minutes late (because Tolga has 120 back-to-back meetings), and all invites sent on his behalf must be signed with Margo's name—making it clear to everyone that an Agent is acting on his behalf. He also set up an hourly cron job via GitHub Copilot to automatically review "what happened in the last hour and whether any decisions were missed."

The Margo project is open-sourced at github.com/TolgaKR/Margo. As for the name, Tolga asked Margo what its own acronym stood for, and it offered: Managing Actions, Relationships, Goals and Obligations—but the real inspiration was Margo Martins, the character who runs the Shipton Abbott police station in the British series Beyond Paradise.

Margo's layered tool-calling design reflects an important engineering principle in current agentic development: separating read and write permissions, and maintaining operational traceability. fetch and retrieve are read-only operations used to gather information and establish a reasoning foundation. ask is semantic retrieval, allowing the model to query structured data in natural language. Only do action triggers actual write operations—creating calendar invites, sending emails, and so on. This layering not only reduces the risk of unintended actions, it also makes Agent behavior far clearer from an audit perspective. Administrators can use logs in the admin center to trace every do action back to which Agent triggered it and under what context. Tolga's insistence on "no action without authorization" and signing everything as "Margo" corresponds, on the engineering side, to requiring user confirmation before any write operation executes and embedding Agent-operation metadata in the resulting artifacts (emails, invites). This is a practical illustration of the ongoing enterprise AI conversation around transparency and trustworthiness.

Conclusion: The Context Layer Is Becoming the New Infrastructure for the Agent Ecosystem

WorkIQ represents a product philosophy worth paying close attention to: when Agents need to do real work in real enterprise environments, the bottleneck is rarely model capability—it's whether the Agent can access the right context and safely read and write enterprise data.

By abstracting Microsoft 365 work data into an intelligent layer, offering three standard integration paths (REST / A2A / MCP), tenant-level permission governance, open-source sample applications, and interactive debugging tools, WorkIQ turns "organizational context" into programmable, governable infrastructure. For developers building enterprise-grade Agents, the maturity of this kind of context layer may ultimately do more to determine a product's real-world value than the parameter count of the underlying model.