An enterprise agent rarely fails because it cannot produce a fluent paragraph. It fails because it cannot distinguish the current balance from the definition of balance, the approved policy from the email that discussed an exception, or the authority to explain a decision from the authority to change a system of record.
That distinction matters in financial services. A relationship manager asking why a commercial borrower has become riskier is really asking several questions at once. What changed in the borrower’s accounts? How does the exposure roll through facilities, collateral, guarantees, and legal entities? What does credit policy require? What did the deal team agree to last week? If action is warranted, who may open a review, request documents, or change a limit?
No single knowledge source can answer all of that honestly. The useful architecture is a Copilot Studio agent that coordinates several bounded kinds of intelligence: Fabric IQ for business state, Foundry IQ for institutional knowledge, Work IQ for the user’s working context, an ontology for shared meaning, and MCP tools for controlled action. API Center anchors design-time inventory and discovery, while Microsoft Purview anchors data governance and supported AI-interaction compliance. Runtime enforcement remains with Entra, Power Platform data policies, native IQ permissions, API Management, and the source systems.
Agent IQ is the Result, Not Another Service
Microsoft’s current name for the umbrella is Microsoft IQ. Its documentation groups Work IQ, Fabric IQ, Foundry IQ, and Web IQ into a shared intelligence layer for agents. Ignite material also used the phrase “agent IQ layers,” but there is no separate Agent IQ workload to provision. Agent IQ is the result of giving an agent the right combination of organizational context.
The four IQ capabilities are peers; ontology is a core item within Fabric IQ.
| System or component | The question it should answer | Architectural role |
|---|---|---|
| Fabric IQ | What is true in the business now? | Governed structured data, measures, relationships, events, and operational state |
| Foundry IQ | What does the institution know or require? | Curated, reusable knowledge bases with agentic retrieval and citations |
| Work IQ | What does this user’s work context add? | Permission-trimmed emails, meetings, chats, files, people, and workflows |
| Web IQ | What current external context is relevant? | Fresh public information when the use case allows it |
| Ontology (within Fabric IQ) | What do these facts mean together? | Shared entities, properties, relationships, rules, constraints, and actions |
That separation prevents a common architectural mistake. A chat thread is not policy. A policy document is not a live account state. A semantic measure is not permission to execute a transaction. The parent agent may combine evidence from all three, but the evidence should keep its identity.
Copilot Studio is the Front Door
Copilot Studio provides the conversation, channel, routing, and composition layer. In the standard harness, generative orchestration can select topics, knowledge, tools, child agents, and connected agents. Agents on the GitHub Copilot harness use enhanced orchestration across instructions, knowledge, tools, skills, workflows, and connected agents. In either harness, names, descriptions, inputs, and outputs are part of the routing contract.
The parent agent should remain thin. It identifies the user’s intent, resolves missing inputs, delegates bounded work, reconciles the results, and controls the approval experience. It should not contain a copy of every policy, a direct connection to every source, and dozens of vaguely named actions. That creates a large tool-selection problem and makes every permission change a change to the front door.
Domain boundaries belong below it. A commercial-lending experience might expose a customer-and-relationship specialist, a credit-and-exposure specialist, and a payments-and-operations specialist. Each carries its own instructions, sources, evaluation, access model, and owner.
The adapter depends on the harness. The standard harness can attach a published Fabric data agent as a preview connected agent. This same-tenant path is validated only in Teams and is not supported when the parent is deployed to Microsoft 365 Copilot.
The GitHub Copilot harness has a first-party preview Fabric IQ tool grounded in a Fabric semantic model; connected agents there are currently other Copilot Studio agents. To combine several Fabric data agents, a composed option attaches each published data-agent MCP endpoint as a preview tool to a domain specialist, then connects those specialists to the parent. Validate that composition explicitly: it is not a documented native Fabric connected-agent path.
Ontology is the Semantic Spine
Fabric IQ’s ontology item supplies the piece most multi-agent diagrams leave implicit: a machine-readable agreement about the business. It defines entity types, properties, relationships, constraints, rules, and data bindings. It can be defined over supported Fabric sources or generated from a Power BI semantic model, then consumed by Fabric data agents, operations agents, Foundry IQ, Copilot Studio, and MCP-compatible clients.
In a bank, Customer, Legal Entity, Account, Facility, Collateral, Guarantee, Covenant, Payment, and Case should not be rediscovered independently by every agent. Modelers establish the identifiers, bindings, and typed relationships that make one agent’s borrower the same declared entity another agent knows as an account owner or guarantor; ontology does not perform master-data deduplication for them. Semantic models still own measures, hierarchies, and analytical definitions, while ontology adds reusable cross-domain concepts and relationships.
This also changes tool design. An action such as OpenCovenantReview should accept an ontology-backed facility identifier, not a name extracted from prose and hoped to be unique. The ontology narrows ambiguity before an action reaches a system of record. Copilot Studio can query the Fabric IQ ontology MCP tool directly, while specialist Fabric agents use the same ontology as a source. Upstream changes currently require an ontology refresh before they appear in its graph.
Several Fabric Agents Are a Feature
Fabric data agents are virtual analysts for a domain. They translate natural language into read-only SQL, DAX, KQL, Microsoft Graph, or ontology queries and return concise answers. Sharing an agent does not grant source access; the requesting identity still needs it, and row- and column-level security continue to apply. Use user authentication when end-user trimming is part of the promise; agent-author authentication is a different choice.
That boundary is useful. The customer specialist can focus on relationship, household, contact, and account data. The exposure specialist can own obligors, facilities, collateral, limits, covenants, and portfolio measures. The operations specialist can combine historical facts with Eventhouse data for payment exceptions, card authorizations, settlement events, or service alerts. An operations agent can monitor some of those signals continuously and recommend an action, while the conversational data agent answers an analyst’s question.
A Fabric data agent supports up to five sources and caps returned chat tables at 25 rows by 25 columns. It neither reads arbitrary unstructured documents nor writes through SQL, DAX, or KQL. Keep each domain small, put documents in Foundry IQ, and place writes behind explicit tools.
Foundry IQ and Work IQ Fill Different Gaps
Foundry IQ is the institutional knowledge layer. Built on Azure AI Search, a knowledge base can combine supported sources, decompose a question, run parallel keyword, vector, or hybrid retrieval, rerank the evidence, and return grounded content with citations. Multiple agents can reuse the same curated knowledge base. For supported sources, it can synchronize access-control lists, honor Purview sensitivity labels, and trim results under the caller’s Entra identity.
For the lending example, that is where credit policy, product terms, underwriting guidance, standard covenants, operating procedures, and approved regulatory interpretations belong. It is also where the knowledge owner can tune retrieval once instead of rebuilding it in every Copilot Studio agent. In the GitHub Copilot harness, the native tool currently permits one Foundry IQ connection per agent, which makes curation more important than accumulation.
Work IQ answers a different question: what does the signed-in user’s work context contribute? Its APIs are GA and usage-based through Copilot Credits, independent of Microsoft 365 Copilot licensing. The native GitHub-harness connection in Copilot Studio is preview, uses consumptive billing, and requires a separate Work IQ spending policy. It brings in permitted Microsoft 365 signals through delegated identity, applies a request-time policy, and denies writes until an administrator enables them.
This is valuable but easy to misuse. A deal-team email can establish that a document was requested or that a meeting occurred. It should not silently override the credit policy retrieved from Foundry IQ or a covenant value calculated in Fabric. The parent agent should label the provenance and resolve conflicts explicitly.
MCP Standardizes the Tool Boundary
MCP gives the architecture a standard way to expose tools and contextual resources. It does not eliminate the need for good APIs. A useful enterprise MCP server presents narrow business verbs with clear schemas, stable identifiers, bounded permissions, idempotency, and predictable failure behavior. RequestUpdatedFinancials is a better agent tool than a generic endpoint that allows arbitrary updates to a loan-origination record.
Fabric data agents and ontology can themselves be exposed through MCP, but transactional tools should sit behind an enterprise runtime boundary. Azure API Management can publish selected REST operations as MCP tools or proxy an existing remote MCP server. It can validate tokens, apply quotas and rate limits, restrict networks, route calls, add correlation identifiers, and send gateway telemetry to Azure Monitor. Its current MCP support governs tools, not MCP resources or prompts.
Azure API Center has the complementary role. It inventories APIs, MCP servers, agents, skills, versions, deployments, owners, lifecycle states, and assessment results. It can make promoted assets discoverable to Microsoft Foundry tool catalogs and other MCP-compatible clients. It does not proxy production calls. API Center records lifecycle or approval metadata; API Management can enforce only custom REST or remote MCP calls explicitly routed through its gateway.
Native connectors, agent flows, and Logic Apps remain valid when the action still has a clear owner, identity, contract, approval path, and audit trail.
Governance Has to Follow the Call
Purview governs the data estate and supported AI interactions; it is not a universal runtime gateway. In Fabric, it contributes catalog, lineage, classification, sensitivity, DLP, audit, and risk capabilities. For supported Copilot Studio interactions, Microsoft documents DSPM, audit, classification, sensitivity labels, DLP, insider risk, communication compliance, eDiscovery, and lifecycle controls. Non-Microsoft channels require pay-as-you-go billing for Purview interaction management.
Coverage is product-specific. Copilot Studio DLP is currently limited to SharePoint knowledge in agents published to Teams, SharePoint, or Microsoft 365 Copilot. Fabric data-agent interaction governance is preview; interaction-level sensitivity labels and DLP are not supported, although underlying source policies still apply. Foundry Data Security Policies require an Entra user-context token or explicit user context; other authentication receives audit and classification visibility only, and native integration alone does not prevent runtime oversharing. Purview does not automatically inspect arbitrary MCP calls. Power Platform data policies govern the agent boundary; API Management governs custom MCP traffic explicitly routed through it.
Agent 365 provides Microsoft’s agent-fleet control plane, while new Copilot Studio agents receive Entra Agent IDs. A complete operating model combines Agent 365 and Entra for fleet identity and lifecycle, Power Platform policies at the agent boundary, API Center for design-time inventory, Purview for data governance and supported interaction compliance, and API Management for custom calls routed through it. Source authorization remains authoritative.
A Lending Request, End to End
Consider a relationship manager asking, “Acme’s revolver utilization rose sharply this month. Are we approaching a covenant problem, and what should I do before Friday’s client meeting?”
Under a user-authenticated path, Copilot Studio resolves Acme only against the ontology and sources the manager is permitted to see. The credit Fabric data agent calculates utilization, headroom, exposure, collateral coverage, and covenant measures. The operations specialist checks recent payments, exceptions, and event data. Foundry IQ retrieves the governing policy, facility terms, and approved covenant procedure. Work IQ finds the manager’s recent meeting notes, emails, calendar entry, and outstanding document requests.
The parent agent then composes one answer without pretending the evidence is interchangeable. It can say that utilization is a live Fabric measure, that the covenant threshold comes from the executed agreement, that policy requires escalation at a specified level, and that the borrower’s controller promised updated financials in an email. If the calculations conflict, the agent should expose the disagreement instead of averaging it into a confident sentence.
When the manager asks, “Open the review and request the documents,” Copilot Studio presents the proposed action, target facility, items, recipients, and due date. The manager approves. The MCP call travels through API Management under the configured identity and gateway policy, writes to the case and workflow systems, and returns durable identifiers. If the application propagates a correlation ID end to end, it can join Copilot, gateway, and backend operational traces. Purview separately records supported interaction evidence; that custom identifier should not be assumed in every Purview record.
That is what turns a chat answer into an auditable workflow: the system can show what it knew, where it learned it, who approved the action, and what changed afterward.
Build For the Seams That Exist Today
Fabric data agent and its standard runtime are GA, as is operations agent. Fabric IQ’s workload grouping and ontology are preview, so ontology-grounded scenarios inherit that dependency. The ontology MCP surface, data-agent MCP server, standard-harness Fabric connection, GitHub Copilot harness, and generic MCP attachment are preview; Microsoft calls the harness a production-ready preview. Ontology has no native versioning, and lakehouses with OneLake security enabled cannot be binding sources. The native Work IQ connection remains preview; Foundry IQ status varies by API version. Cross-product calls can also cross service or geographic compliance boundaries.
The production decision should be made capability by capability. Keep the ontology and tool contracts versioned outside the preview surface, test routing with a real evaluation set, retain a deterministic path for material actions, and make geographic processing an explicit architecture decision. A diagram labeled “Microsoft” does not create one compliance boundary.
The Useful Agent Knows What Kind of Truth it is Holding
A strong Copilot Studio architecture keeps the parent small so evidence, identity, policy, and authority survive every handoff while users ask whole business questions.
Start by choosing one decision that already crosses those boundaries. Model its entities, separate its sources of truth, expose only the actions the decision genuinely requires, and make every handoff visible. The agent becomes more useful when it knows more. It becomes trustworthy when it knows what kind of knowledge it has—and what authority it does not.
