Microsoft IQ Explained: Giving Enterprise AI Agents Real Business Context

Models Give Agents Intelligence — Context Gives Them Meaning

Here's an often-overlooked truth: the upper limit of an AI agent's capability isn't determined solely by the underlying model — it's determined by the context that model can access. As Microsoft emphasizes in this demo: "Models give agents intelligence; context gives agents meaning." Without the support of enterprise data, knowledge, language, and relationship networks, even the most powerful model can only "respond" and "generate answers" — it can't truly "understand what matters" and deliver well-grounded results.

Microsoft IQ is designed precisely around this pain point. It brings together an enterprise's data, knowledge, language, and relationships, transforming agents hosted in Foundry from isolated Q&A machines into executors that can connect to enterprise context and turn information into real action. This article uses the Supply Autopilot (supply chain autopilot) case from the official demo to break down how each of the four Microsoft IQ modules actually works.

Four IQs, Four Roles: From the Web to Workflows

The Supply Autopilot shown in the demo is an application built on Foundry-hosted agents. It simultaneously calls on all four IQ types, each serving a distinct role. In Foundry, these capabilities are accessed via a "toolbox" — a toolbox called supply tools connects to all four IQs.

WebIQ retrieves real-time information from the public web. In the demo, it's triggered when asking about weather. It has its own portal at webiq.microsoft.ai, where the playground lets you search queries like "latest AI trends" and filter by vertical — for example, searching only "Microsoft developer videos" returns results from the official YouTube channel. WebIQ calls news and web tools and supports multilingual implementations. Through Foundry's traces feature, you can clearly see where results come from.

Foundry IQ handles structured enterprise knowledge bases. It's triggered when asking "which products qualify for replacement and credit terms." Its knowledge base is backed by four different knowledge sources, each an Azure AI Search index with its own description. Developers can configure the completion model, reasoning effort, output format, and both answer and retrieval instructions. Foundry IQ automatically determines which knowledge source to access based on the question and includes citations in its responses.

Fabric IQ: Semantic Models and Ontologies Working Together

Fabric IQ integrates differently from the other two — rather than going through MCP, it's accessed via a Fabric data agent (the supplier data agent). The Fabric workspace contains three key components: a semantic model, an ontology, and a data agent.

The semantic model is built on top of supplier datasets and surfaces various data relationships. More interesting is the "generate ontology" feature: clicking it automatically builds relationships between products, substances, manufacturers, marketing authorizations, and regulatory bodies — you can click any node to see what the relationship means.

The semantic model and ontology serve different types of questions. For example, asking "rank all suppliers by their latest OTIF" draws from the semantic model, while relationship queries — such as "which medical products contain a certain vaccine ingredient" — draw from the ontology. The hosted agent connects directly to the Fabric data agent and returns the appropriate results. This division of labor between semantic model and ontology makes complex supply chain relationship queries feasible.

Semantic Model is a business semantics layer built over structured data. It maps raw database tables and fields to business concepts (like "supplier" or "order fulfillment rate"), enabling natural language queries to be translated into meaningful data analysis without users needing to understand the underlying SQL structure. Ontology is a formal description of concepts and their relationships, rooted in knowledge graph theory — for example, "Product A contains Ingredient B" or "Manufacturer C holds Regulatory Authorization D." These multi-hop relational queries can't be efficiently answered with traditional tabular models, but ontologies are naturally suited to this kind of graph traversal. The fundamental difference: semantic models answer aggregation questions like "how many" or "what's the ranking," while ontologies answer relational questions like "who is connected to whom and through what path." OTIF (On Time In Full) is a key performance indicator in supply chain management, measuring whether orders are delivered completely within the agreed timeframe — it's one of the core metrics for evaluating supplier reliability.

Work IQ and Identity: Acting "As Me" vs. "As Itself"

Work IQ handles actual workflow actions. In the demo, when asked to "summarize the conversation and send an email to someone," Work IQ authenticates through Foundry IQ using "my" account and sends the email on my behalf. It calls the do action tool, and you can see in Outlook an email sent "from me to myself," proving this delegation mechanism works.

What really demonstrates the depth of the design is the ability to switch agent identity. When Supply Autopilot is deployed as part of the tenant, it gets its own dedicated mailbox address and reports directly to a manager in the Teams organizational chart. At that point, the agent is no longer acting "as me" — it's acting "as itself."

In the demo, when asked "do you have any urgent supply escalation issues in your inbox," the autopilot checks its own inbox and finds an escalation email from Maria requesting a replacement and credit — addressed to the autopilot itself. It then orchestrates across all four IQs: calling WebIQ to check weather-related shipping disruptions, Foundry IQ to determine eligibility for replacement, and the Fabric IQ data agent to rank suppliers. It then replies to Maria from its own mailbox address, confirming that a free replacement and credit will be issued — the entire closed loop completed autonomously by the agent acting as an independent identity.

Delegated Permissions is an authorization model in the Microsoft identity platform (based on OAuth 2.0): the application requests access to resources on behalf of the signed-in user, and the permissions it can obtain are capped at what that user already has. The counterpart is Application Permissions, where the application runs under its own identity (without a user present). When an agent has its own mailbox and acts "as itself," what's actually happening under the hood is a switch in this identity model — the agent moves from "borrowing a human user's delegated permissions" to "holding its own application permissions as a Service Principal." This is precisely why it needs its own license and bot ID assigned in Agent 365.

Agent 365: The Governance Foundation for Enterprise Agents

The final section of the demo points to Agent 365 — a new module in the admin center for managing agents like Caldova Supply Autopilot within a tenant.

Here, administrators can manage an agent's identity details, including its agent ID and blueprint ID, and create instances from agent templates. To run an agent across different scenarios, you need to assign it licenses — for example, E5 plus a Frontier license for the autopilot. Permission management also happens in Agent 365: for Work IQ to execute actions, it requires the appropriate delegated permissions. If you want the agent to appear in Teams, you need to assign it a bot ID so users can interact with it through the message handler.

From capability integration and identity authentication to permission management and license assignment, Microsoft IQ combined with Agent 365 forms a relatively complete enterprise agent framework. The core problem it aims to solve is exactly how to let agents "do things" safely, controllably, and with accountability — not just "say things." For teams considering scaling AI agent deployments across the enterprise, this architecture approach — centered on context, with identity and governance as guardrails — is worth paying close attention to.

The distinction between Blueprint ID and Agent ID reflects a "template vs. instance" design philosophy: a Blueprint is the agent's definition template, describing its capabilities, tools, and behavioral specifications; an Agent is a specific running instance created from a Blueprint within a particular tenant, with its own identity, license, and permission configuration. This is analogous to the "class and object" relationship in software engineering — the same Blueprint can be instantiated into multiple agents across different departments or scenarios, each behaviorally consistent but with an independent identity. The Frontier license currently corresponds to the advanced capability tier in Microsoft's enterprise Copilot ecosystem, enabling agents to use more autonomous execution capabilities. It's an incremental authorization layer on top of the standard Microsoft 365 E5 license, specifically designed for AI agents with autonomous action capabilities.