Work IQ: A Technical Guide to Microsoft 365’s Agent Intelligence Layer

Work IQ: The Context Layer Enterprise Agents Have Been Missing

Enterprise agents rarely fail because an organization has no data. They fail because the data arrives without enough context.

An email can be retrieved, but why does it matter? A meeting transcript can be searched, but which decision superseded the earlier one? A document can be opened, but who owns it, what project does it support, and how does it relate to the user asking the question?

That gap—between retrieving records and understanding work—is the problem Microsoft Work IQ is designed to address.

Microsoft describes Work IQ as a workplace intelligence layer that enables agents to access and reason over organizational data, context, and tools. It combines Microsoft 365 information with contextual understanding, applies existing permissions and policies, and exposes the result through agent-friendly interfaces such as Agent-to-Agent (A2A), Model Context Protocol (MCP), and REST APIs.

The shortest useful mental model is this:

That distinction is important, but it is not an either-or choice. Work IQ does not make Microsoft Graph obsolete. The two surfaces solve different parts of the architecture.

From Data Retrieval to Work Understanding

Traditional application integration starts with explicit resource operations:

1. Call an API for messages, events, files, or people.
2. Handle pagination, schemas, and permissions.
3. Normalize the returned data.
4. Build search or retrieval pipelines.
5. assemble the relevant context.
6. Send that context to a model.
7. Implement actions separately.

That approach remains appropriate when an application needs deterministic access to known resources. However, it pushes substantial orchestration work onto the developer when the request is semantic and open-ended—for example:

• “What changed in the Contoso proposal after Tuesday’s review?”
• “Summarize the decisions that affect next week’s launch.”
• “What is blocking this project, and who is best positioned to resolve it?”

These questions do not map neatly to one endpoint or one record type. They cross messages, meetings, files, people, and organizational relationships. Work IQ moves more of the retrieval, context assembly, and reasoning into a Microsoft-managed runtime, so the calling agent can work with grounded results instead of stitching together every raw signal itself.

This is the architectural shift: from record-centric integration to context-centric agent interaction.

Relationships Are the Real Unit of Intelligence

The source session makes a particularly useful distinction: Work IQ’s value is not only that it can retrieve an artifact, but that it can understand the web around the artifact.

Consider a proposal document. In isolation, it is a file with text and metadata. In the flow of work, it may also be connected to:

• the people editing and reviewing it;
• the customer or opportunity it supports;
• meetings in which its assumptions were challenged;
• email and Teams conversations where decisions were made;
• a business process that moves the proposal from draft to approval;
• and structured data in Dynamics 365, Power Apps, or another line-of-business system.

Those relationships allow an agent to reason across a workflow rather than answer one disconnected question at a time. It can prepare someone for a meeting, identify what changed after the meeting, help move a deal forward, and follow up on an unresolved decision. The goal is end-to-end reasoning about work, not just better document search.

A useful way to express the difference is:

Artifact-centric retrieval:

• Document → summarize the document

Relationship-centric reasoning:

• Document → people → conversations → meetings → decisions → business process → next action

That relationship model is also why Work IQ draws on changing activity signals. Work is not static: comments appear, meetings happen, priorities shift, and documents evolve. Relevant context must therefore be continuously refreshed rather than treated as a one-time snapshot.

A More Accurate Model of the Work IQ Architecture

The source session explains Work IQ through a three-layer developer mental model: Data, Context, and Skills and Tools. It also describes the developer-facing ingredients as four simple ideas—data, context, skills, and tools—with skills representing task-specific instructions or expertise and tools representing operations an agent can invoke.

Microsoft’s current API documentation uses a complementary product-surface model: Chat, Context, Tools, and Workspaces. These views are not contradictory. The three-layer model explains how intelligence builds upward from organizational signals to agent behavior; the four-capability model explains what developers can consume from the platform today.

The diagram is a conceptual model, not a published physical topology. It explains the responsibilities developers interact with without making unsupported claims about Microsoft’s internal service implementation.

Mapping the Source’s Three Layers

• Data is where the work is recorded: documents, email, meetings, messages, comments, business records, and connected external information.
• Context connects those silos through semantic understanding and aligns retrieval with the user’s work, priorities, preferences, and available memory signals.
• Skills provide task-specific know-how or instructions that shape how an agent approaches work.
• Tools provide callable operations that let an agent retrieve information or act across supported applications and services.

The Work IQ APIs make the intelligence used by Microsoft 365 Copilot available to custom agents and applications through supported interfaces. That does not mean a custom solution receives every internal Copilot capability automatically; it means developers can invoke documented Work IQ agents, context, and tools instead of rebuilding the entire workplace-intelligence pipeline themselves.

1. Chat: Processed, Work-Grounded Responses

The Chat capability is the best fit when the caller wants a completed answer rather than raw context. Work IQ can provide conversational access to Microsoft Copilot and available agents through A2A or REST.

Think of Chat as asking a capable workplace analyst to investigate a question and return a synthesized response. The caller delegates more of the reasoning process to Work IQ.

Typical scenarios include:

• an operations agent delegating a workplace investigation;
• a web application presenting a grounded answer to a signed-in user;
• an orchestrator requesting a summary that spans multiple Microsoft 365 sources.

2. Context: Agent-Ready Grounding

Context is about assembling relevant organizational information for an agent. Instead of forcing every developer to build a separate extraction, indexing, retrieval, and ranking pipeline, Work IQ can ground requests across supported Microsoft 365 data and connected systems.

The underlying value is not merely semantic search. Context can reflect relationships among content, people, activity, and organizational signals while remaining permission-aware. Microsoft also describes Work IQ as building on capabilities such as semantic indexing and personal memory to improve relevance.

A useful analogy is a briefing book. A raw API hands you folders of records. A context service prepares the subset an agent needs for the task, with the surrounding relationships that make those records meaningful.

This does not mean every business fact becomes automatically correct or complete. Grounding improves relevance; it does not eliminate source quality problems, conflicting records, missing permissions, or model error.

3. Tools: A Compact Surface for Reading and Acting

The Tools capability gives agents a simplified way to interact with Microsoft 365 entities and actions. The remote Work IQ MCP server uses a deliberately compact design: generic verbs operate on resource paths, while agents can discover schemas at runtime.

Microsoft currently documents ten core MCP tools across three groups:

• Entity tools: fetch, create_entity, update_entity, delete_entity, do_action, and call_function
• Copilot tools: ask and list_agents
• Schema tools: get_schema and search_paths

The pattern looks like this:

fetch         /me/messages
create_entity /me/events
update_entity /me/events/{id}
do_action     /me/sendMail
call_function /search/query
ask           "What decisions were made about the launch?"

The architectural idea is fewer tools, more paths. Instead of loading hundreds of workload-specific tool definitions into an agent’s context window, the agent uses a small verb set and discovers the relevant resource path and schema when needed.

That design can reduce tool-selection complexity and context overhead, especially as the number of supported resources grows.

4. Workspaces: Durable State for Long-Running Work

Not every agent task ends in one request. Research, document production, investigation, and multi-agent handoffs may require intermediate files, partial results, and durable working state.

Work IQ Workspaces address that need through SharePoint Embedded working storage within the Microsoft 365 tenant boundary. A workspace can hold intermediate data and outputs so an agent can resume work, reuse results, or hand off progress to another agent or experience.

This is different from conversational memory. Memory helps personalize or continue interactions; a workspace provides an explicit working area for the artifacts of a longer-running process.

Choosing Between A2A, MCP, and REST

Work IQ exposes multiple protocols because not every integration is shaped the same way. The choice is less about which protocol is “best” and more about who is calling, what is being delegated, and how much control the caller wants.

These are recommended patterns, not absolute boundaries.

A2A: Delegate Work, Not Just a Function Call

The Agent-to-Agent protocol is designed for structured communication and delegation between agents. With Work IQ, a calling agent can discover an Agent Card and send a task to the Work IQ endpoint.

Work IQ supports A2A version 1.0 and version 0.3. Version 1.0 is selected with the A2A-Version: 1.0 header; omitting the header currently falls back to version 0.3 for compatibility. The service supports synchronous messaging and streaming responses.

A2A is a good fit when the abstraction you want is:

It is not accurate to say that A2A grants a downstream agent broad authority to move across tenants. The documented Work IQ flow uses Microsoft Entra ID delegated authentication and operates on behalf of the signed-in user, subject to permissions and policy.

MCP: Expose Work IQ as an Agent Toolset

MCP is a good fit when your agent runtime already knows how to call MCP tools. The Work IQ MCP server exposes both semantic capabilities and structured Microsoft 365 operations through a single endpoint.

The important nuance is that MCP is not limited to “fast, one-shot, stateless lookup.” An MCP client may use multiple tool calls in a longer reasoning loop, and Work IQ’s tools can perform reads, writes, actions, Copilot queries, and schema discovery.

Use MCP when you want the calling model to retain orchestration control:

Because tools can create, update, send, or delete data, production clients should introduce confirmation and safety patterns for consequential actions. Authentication and policy remain essential; an agent-friendly tool surface is not a permission bypass.

REST: Integrate Work IQ into a Custom Application

REST is the most natural option for an application or backend that wants to submit a work-grounded request and render the result in its own experience.

Use REST when the abstraction is:

REST is especially useful when your application already owns authentication, session handling, telemetry, and UI behavior. It can also be easier to adopt in architectures that are not built around an MCP client or an A2A-compatible agent framework.

What Multi-Agent Orchestration Does—and Does Not—Mean Here

Work IQ is relevant to multi-agent systems because one agent can delegate workplace questions to Work IQ through A2A, or an orchestrator can expose Work IQ capabilities through MCP or REST. Workspaces can also support longer-running processes and handoffs.

A conceptual execution flow might look like this:

What matters is the separation of responsibilities:

• The orchestrator decides how the broader task is decomposed.
• Work IQ supplies workplace-grounded intelligence and Microsoft 365 capabilities.
• Other agents may contribute public, domain-specific, or application-specific knowledge.
• The solution remains responsible for validating results and controlling consequential actions.

What the Source Demo Shows

The source includes a simple web application with two paths operating side by side:

1. A generic knowledge agent answers a public question, such as a weather query.
2. When the user asks a workplace question—for example, about an internal time-off policy—the application recognizes that enterprise context is required and delegates the question to the Copilot work agent.
3. The background view shows the request being decomposed into multiple tasks while partial results stream back to the browser.
4. The final response is personalized to the user’s preference for BLUF—Bottom Line Up Front—placing the conclusion before the supporting detail.

The demo is valuable because it illustrates three design patterns: intent-based routing between agents, background task decomposition with streaming output, and presentation adapted to the user’s working style. These should be understood as behaviors shown in that particular demonstration, not as a complete public specification of Work IQ’s internal runtime.

The transcript verbally refers to the demo’s application or routing layer as “AJA,” but it does not define the acronym, and current public Work IQ documentation does not identify an “Agent-to-JSON-Architecture” protocol or product component. The safe conclusion is that AJA belongs to the demonstrated application architecture, whereas A2A is the documented protocol used to communicate with Work IQ.

Model Selection and Multimodality: Keep the Boundary Clear

The source also states that Work IQ is multimodal under the hood, draws from models supplied by multiple vendors, and selects a suitable model for the task so developers do not have to hardcode that choice. This is useful architectural context from the Work IQ team, especially because a task may involve different content forms and reasoning patterns.

However, current public API documentation does not define a model-routing contract, list eligible model providers, or guarantee that callers can inspect or control the selected model. Therefore, treat dynamic model selection as a service-level implementation explanation from the source session, not as a configurable API capability or production dependency. Applications should integrate with the documented Work IQ behavior rather than assume a particular underlying model.

Similarly, the source’s automatic BLUF formatting and visible task decomposition demonstrate personalization and orchestration in action, but public documentation does not promise a BLUF mode or expose a specific internal task tree as a stable API.

Cross-Platform Extensibility

Work IQ is not limited to agents built in one Microsoft authoring environment. Because it exposes standard interfaces—A2A, MCP, and REST—it can be called from Microsoft agent stacks or custom runtimes that support the required protocol, authentication, and policy model. In practice, this means a team can bring workplace intelligence to an agent it is already building rather than moving the entire solution into a single framework.

This portability has limits: the caller still needs Microsoft Entra authentication, tenant enablement, supported permissions, and a compatible client or backend. “Any platform” should therefore be read as framework and runtime flexibility, not anonymous or unrestricted access to Microsoft 365 data.

Work IQ and Microsoft Graph: Complementary, Not Opposing

The most important correction to many Work IQ explanations is this: Microsoft Graph is not simply “for humans,” and Work IQ is not a wholesale replacement for it.

Microsoft Graph is the broad API gateway for programmatic access to Microsoft 365 and other Microsoft cloud resources. Developers use it for precise, deterministic operations over messages, calendars, files, groups, users, Teams, security data, and many other resource types.

Work IQ is optimized for agentic interaction with workplace context. It can reduce the amount of custom retrieval and orchestration needed for semantic, cross-resource tasks, and its MCP tools use generic operations over Microsoft 365-style resource paths.

Use Microsoft Graph when

• you know the exact resource and operation you need;
• the application requires deterministic control over query shape and response handling;
• you need a Graph workload or permission model not exposed through Work IQ;
• or you are building conventional integration and automation rather than semantic agent reasoning.

Use Work IQ when

• the question spans messages, meetings, files, people, or organizational context;
• you want Copilot-quality processing rather than only raw records;
• an agent needs a compact tool surface and runtime schema discovery;
• another agent should delegate a workplace task;
• or a long-running agent process needs tenant-bound working storage.

Use both when

• Work IQ should answer the ambiguous, context-heavy part of a task, while Graph handles a precise downstream operation;
• your agent needs semantic discovery first and deterministic verification second;
• or Work IQ covers the high-value reasoning path while Graph fills an unsupported resource or integration gap.

A practical rule of thumb is:

Security, Permissions, and Operational Boundaries

Work IQ is designed to preserve Microsoft 365 permissions, compliance, and governance rather than copy enterprise data into an unmanaged retrieval stack. That is a major architectural advantage, but “built in” should not be confused with “nothing to configure.”

Current Work IQ APIs are protected by Microsoft Entra ID. The documented A2A quickstart uses the delegated WorkIQAgent.Ask permission, which requires admin consent and allows the application to ask Work IQ on behalf of the signed-in user. Server-side applications acting for a user should use an appropriate confidential-client design and the OAuth On-Behalf-Of flow.

Administrators must enable Work IQ in the tenant before applications can use its permissions. Microsoft’s current enablement guidance also requires a usage-based billing plan associated with an Azure subscription and resource group.

For solution architects, the practical controls are familiar:

• use delegated identity correctly;
• request only the capabilities the application needs;
• preserve user intent for write or delete operations;
• add application-level confirmation for high-impact actions;
• test permission trimming with realistic users, not only administrators;
• and monitor usage and policy centrally.

Work IQ reduces the need for a custom compliance and retrieval layer. It does not remove the need for sound identity design, application security, human oversight, or data quality management.

Availability and Commercial Model

Microsoft announced that the Work IQ API endpoints—including A2A, the remote MCP server, and REST—would become generally available on June 16, 2026. Current Microsoft Learn documentation presents these endpoints as available and describes usage as independent of Microsoft 365 Copilot licensing.

Access is usage-based rather than included automatically with a Microsoft 365 Copilot user license. Tenant enablement requires a billing plan, and governance and cost-management controls are available through the Microsoft 365 admin center.

That commercial detail matters operationally, but it should not dominate the architecture discussion. The central design question remains whether Work IQ removes enough retrieval, context assembly, tool-definition, and compliance plumbing to justify using the managed intelligence layer for the scenario.

A Practical Evaluation Path

A good proof of concept should test the layer that makes Work IQ distinctive: cross-resource workplace understanding.

1. Choose a question that requires relationships

Avoid starting with “list my next five meetings.” That is a deterministic calendar query and does not demonstrate much contextual value.

Prefer a scenario such as:

2. Pick the interface that matches the architecture

• Choose A2A if another agent is delegating the task.
• Choose MCP if an LLM-based client should invoke Work IQ tools directly.
• Choose REST if a custom application owns the experience.

3. Test with two permission profiles

Use one user who has broad access and another with narrower project access. Verify that results differ appropriately and that inaccessible content is not surfaced.

4. Separate retrieval quality from answer quality

Ask two questions:

1. Did Work IQ find the right evidence?
2. Did the agent interpret that evidence correctly?

A fluent answer can still be incomplete. Require links, identifiers, or other traceable references where the interface provides them.

5. Add a controlled action

After validating read scenarios, test a low-risk write or action with explicit confirmation—for example, preparing rather than immediately sending a follow-up message.

6. Measure architectural reduction

Compare the proof of concept with the custom solution you would otherwise build. Count the retrieval connectors, indexing jobs, tool definitions, permission checks, and orchestration code that Work IQ replaces or simplifies.

Limitations and Open Questions

Work IQ is a managed intelligence layer, not a guarantee of perfect organizational truth.

Keep these constraints in view:

• Permission-aware does not mean complete. The answer can only use information available to the signed-in user and supported by the service.
• Semantic relevance is probabilistic. Important evidence can be missed or ranked poorly.
• Grounded reasoning can still be wrong. Agents may misinterpret ambiguous or conflicting source material.
• Tool coverage is not identical to all of Microsoft Graph. Verify resource and operation support for the specific scenario.
• Write operations increase risk. Confirmation, auditability, and recovery design remain application responsibilities.
• Service behavior will evolve. Protocol versions, supported paths, pricing, and administrative controls should be checked against current documentation before production deployment.
• Internal implementation details are not public contracts. Architect against documented interfaces and behaviors, not assumptions about hidden routing or model-selection logic.

Final Perspective

Work IQ is best understood not as another database API, and not as a replacement for Microsoft Graph, but as an agent-oriented intelligence layer over workplace data and capabilities.

Its value comes from four connected ideas:

1. Chat can return processed, work-grounded answers.
2. Context can assemble relevant organizational information for agents.
3. Tools give agents a compact, discoverable surface for Microsoft 365 reads and actions.
4. Workspaces provide durable working state for long-running agent processes.

A2A, MCP, and REST then expose those capabilities to different kinds of callers.

The architecture decision is therefore not “Graph or Work IQ?” It is more precise:

When the task is explicit and record-oriented, Microsoft Graph remains the natural choice. When the task depends on relationships, organizational context, semantic grounding, or delegated agent work, Work IQ offers a higher-level building block. In many enterprise systems, the strongest design will use both.

Official Resources

• Work IQ overview
• Work IQ API overview and protocol selection
• Work IQ MCP overview
• Work IQ A2A overview
• Work IQ API permissions
• Enable Work IQ in a tenant
• Microsoft Work IQ samples and plugins on GitHub
• Work IQ API general availability announcement
• Work IQ developer series
• Work IQ labs, cookbooks, and self-paced material