Building a Semantic Layer for AI Agents with Microsoft Fabric: A Technical Deep Dive

By Brian Curry | Vector1 Research

“AI fails without context-rich data. No matter how well modeled, data without the context provided by shared semantics and mature ontologies will fall short for agentic AI use cases.” — Forrester Research, June 2026

Abstract

The most common reason enterprise AI agent pilots fail to reach production isn’t model capability — it’s semantic drift. Agents built directly on raw warehouse tables, inconsistent column names, and undocumented business logic produce responses that are technically correct and operationally meaningless. The fix isn’t better prompting. It’s a governed semantic layer that gives agents a shared, trusted understanding of what your data actually means.

Microsoft Fabric, with the June 2026 general availability of Fabric IQ and its expanding Ontology preview, has become the most architecturally complete answer to this problem in the enterprise market. This article is a technical deep dive into how to build that semantic layer — from raw OneLake data through Power BI semantic models, through Fabric IQ Ontology, and out through Model Context Protocol (MCP) endpoints that make the entire layer consumable by any agent, whether built in Microsoft Foundry, GitHub Copilot, Claude, or a custom LangChain or AutoGen framework.

We cover the full stack: the four-tier architecture, Prep for AI configuration, Ontology entity modeling, MCP server setup, Data Agent creation and governance, and the operational considerations that separate a demo from a production system.

I. Why Agents Fail Without a Semantic Layer

Consider a straightforward business question: “What was our revenue from enterprise customers in the Northeast last quarter?”

A human analyst answering this question brings implicit knowledge to bear: she knows that “revenue” means net revenue after returns, not gross bookings. She knows that “enterprise” maps to the customer_segment field with value 'ENT', not 'SMB' or 'MID'. She knows that "Northeast" maps to a specific set of region codes in the territory table, not a free-text field. She knows that "last quarter" is relative to fiscal quarter, not calendar quarter, and that the company's fiscal year starts in October.

An AI agent querying the raw data warehouse directly has none of this knowledge. It sees a fact_orders table, a dim_customer table, and a dim_territory table, connected by integer keys it can't interpret. It sees a revenue_amount column it can't distinguish from gross_order_value. It sees a quarter field in two different tables with inconsistent encoding. Without external guidance, the best it can do is make educated guesses based on column names — and educated guesses on financial data are how AI agents end up in front of audit committees.

This is semantic drift: the gap between what data says and what it means. It’s endemic in enterprise data environments because data is created by engineers optimizing for storage and query performance, while business questions are asked by humans operating in business language. The two vocabularies have never naturally aligned.

A semantic layer solves this by acting as a translation layer between raw data and business meaning. It defines what “revenue” means in your organization. It defines what “enterprise customer” maps to in your schema. It defines the relationships between business concepts and the tables that implement them. It enforces the business rules — fiscal year definitions, regional hierarchies, segment classifications — centrally, so they don’t have to be re-implemented in every query, every dashboard, and every agent prompt.

Power BI semantic models have been doing this for BI workloads for years. Fabric IQ extends this capability into the agentic AI layer — taking the semantic definitions that your BI team has already built and making them the grounding layer for every AI agent in your organization. At Build 2026, Fabric IQ reached general availability. The argument for building on this layer is now production-grade.

II. The Four-Tier Semantic Architecture

Understanding the Fabric semantic layer for agents requires understanding four distinct tiers and how they relate to each other. These are not redundant alternatives — they are a stack, each tier serving a distinct purpose and building on the one below it.

┌─────────────────────────────────────────────────────────────────┐
│  TIER 4: AGENT CONSUMPTION LAYER                                │
│  Data Agents · Copilot · MCP Clients · External Agents          │
│  (Claude, GitHub Copilot, Foundry, AutoGen, LangChain)          │
├─────────────────────────────────────────────────────────────────┤
│  TIER 3: FABRIC IQ ONTOLOGY (Preview)                           │
│  Business Entities · Relationships · Rules · Actions            │
│  Operational Context · Real-Time Signals (Eventhouse)           │
├─────────────────────────────────────────────────────────────────┤
│  TIER 2: POWER BI SEMANTIC MODEL                                │
│  Measures · Hierarchies · RLS · Prep for AI                     │
│  Verified Answers · AI Instructions · DAX Logic                 │
├─────────────────────────────────────────────────────────────────┤
│  TIER 1: ONELAKE DATA FOUNDATION                                │
│  Lakehouse · Warehouse · Eventhouse · Mirrored Databases         │
│  Delta Parquet · Delta Lake · Open Formats                       │
└─────────────────────────────────────────────────────────────────┘

Tier 1: OneLake is the unified data plane. All data — structured, semi-structured, streaming — lives here in open Delta Parquet formats. Lakehouses handle big data workloads. Warehouses handle T-SQL analytics. Eventhouses handle real-time streaming telemetry via KQL. Mirrored databases connect external sources (Snowflake, Azure SQL, Cosmos DB) without data movement. Tier 1 is governed, versioned, and secured through Microsoft Purview and Entra ID.

Tier 2: Power BI Semantic Model is the analytical semantic layer. This is where raw tables become business concepts: measures like [Net Revenue] encapsulate the calculation logic; hierarchies define how [Region] → [Territory] → [Store] relates; row-level security ensures users only see data they're authorized to see; Prep for AI adds the metadata layer — AI Instructions, Verified Answers, and AI Data Schemas — that directs agents toward correct interpretations.

Tier 3: Fabric IQ Ontology is the operational semantic layer. While semantic models define analytical metrics, Ontology defines business entities and their live operational context. A Customer entity isn't just a dimension table — it's a live business object with properties bound to multiple data sources, relationships to Orders, Contracts, and SupportTickets, rules that define what makes a customer "at-risk," and actions that can be triggered when those rules fire. Ontology adds real-time signal binding (from Eventhouse), rule enforcement, and operational context that semantic models were never designed to carry.

Tier 4: Agent Consumption is where the semantic layer becomes active. Data Agents expose the semantic layer as a conversational interface. MCP servers expose it as a standard tool API that any agent framework can call. The Power BI Modeling MCP Server exposes the semantic model definition itself for LLM-assisted development. Every consumption pattern in Tier 4 inherits the governance, security, and semantic grounding of the layers below.

The key architectural insight: you don’t have to build all four tiers at once. Tier 2 alone (a well-configured semantic model with Prep for AI) gives you most of the value for analytical agents immediately. Tier 3 (Ontology) adds operational context and is worth building when your agents need to reason about live business state, not just historical metrics. Tier 4 is where you connect everything to your agent ecosystem.

III. Building the Semantic Model for AI Consumption (Tier 2)

The Power BI semantic model is the most underappreciated AI infrastructure asset in most organizations. If your BI team has already built certified semantic models, you have a semantic foundation for agents that most organizations are years away from replicating from scratch.

But a semantic model built for human BI consumption is not automatically well-configured for agent consumption. Agents interact with semantic models differently than humans do: they read metadata to understand what a model contains, they generate DAX queries programmatically, and they can’t ask clarifying questions in the middle of a query. The Prep for AI feature suite addresses exactly this gap.

3.1 Naming Conventions: The Foundation Everything Else Builds On

Before Prep for AI, before Ontology, before Data Agents — naming matters more for AI consumption than for any other use case. An agent generating DAX queries reasons about your model entirely through the names it sees. Table names, column names, and measure names are the agent’s vocabulary.

The practical standard:

BAD (engineer-optimized):  fact_ord_hdr, cust_sgmt_cd, rev_amt_net_fx
GOOD (business-language):  Orders, Customer Segment, Net Revenue (FX Adjusted)

BAD:  dim_dt, per_id, prd_cat_l2
GOOD: Date, Period ID, Product Category (Level 2)

For organizations with existing large semantic models where renaming manually would be prohibitive, the Power BI Modeling MCP Server (released at Ignite 2025, in public preview) makes this tractable at scale. Connect it to VS Code and prompt an LLM to generate business-friendly rename suggestions across the entire model:

// .vscode/mcp.json
{
  "servers": {
    "powerbi-modeling": {
      "type": "http",
      "url": "https://api.fabric.microsoft.com/v1/workspaces/{workspace-id}/semanticModels/{model-id}/mcp"
    }
  }
}

// Prompt to LLM via Power BI Modeling MCP Server
"Review the table and column names in this semantic model. For each name that 
uses abbreviations, underscores, or technical conventions, propose a business-
friendly rename. Output as a structured list of [current_name] → [proposed_name] 
pairs. Flag any renames that might break existing DAX expressions."

The MCP server supports bulk rename operations, DAX validation after rename, and TMDL export/import for Git-based review workflows. The net result: LLM-assisted renaming of a 200-table semantic model in hours rather than weeks, with human review before any change ships.

3.2 Prep for AI: The Three Configuration Levers

Prep for AI is the semantic model configuration surface designed specifically for AI consumption. It has three components that work together to direct agents toward correct interpretations.

AI Data Schema: Scoping the model for agent focus

A semantic model built for general BI use may contain hundreds of tables, measures, and columns. An agent asked about revenue doesn’t need to see the entire model — it needs to see the subset relevant to revenue analysis. AI Data Schema lets you define a focused subset that agents prioritize.

// In Power BI Desktop: Model view → Prep for AI → AI Schema

// Define the Revenue Analysis schema
// Include: fact_sales measures, customer dimensions, date dimensions
// Exclude: HR tables, IT asset tables, operational tables irrelevant to revenue

// Practical effect: when a Data Agent receives a revenue question,
// it reasons over 15 tables instead of 85, reducing token consumption
// and DAX generation errors significantly

AI Instructions: Injecting business context agents can’t infer

AI Instructions are free-text metadata attached to the semantic model that agents read before generating queries. This is where you encode the business knowledge that lives in your analysts’ heads but not in your schema.

// Semantic Model AI Instructions (example for a retail company)

FISCAL YEAR: Our fiscal year begins October 1st. When users ask about 
"this year", "last year", "YTD", or "QTD" without specifying calendar vs. 
fiscal, always use fiscal year definitions. The [Date].[Fiscal Year] 
hierarchy is the authoritative fiscal calendar.

REVENUE DEFINITION: [Net Revenue] is the standard revenue measure for all 
financial reporting. [Gross Order Value] is pre-returns and should only be 
used when explicitly requested. Never use [Gross Order Value] as a proxy 
for revenue unless the user specifically asks for gross figures.

CUSTOMER SEGMENTS: "Enterprise" refers to [Customer Segment] = "ENT". 
"Mid-market" refers to [Customer Segment] = "MID". "SMB" refers to 
[Customer Segment] = "SMB". Do not attempt to infer segment from 
company size or other proxy fields.

TERRITORY HIERARCHY: Northeast region includes territory codes 
NE01-NE12 in [Territory].[Territory Code]. Use [Territory].[Region] 
for regional aggregations, not free-text fields.

KNOWN AMBIGUITIES: The [Orders] table contains both web and in-store 
orders. The [Channel] field distinguishes them. Unless the user 
specifies a channel, always aggregate across both.

This is the most high-value configuration step in the entire pipeline. A well-written AI Instructions block is worth weeks of prompt engineering because it’s applied at the data layer, not the application layer — every agent that consumes this model benefits automatically.

Verified Answers: Guaranteeing consistency on common questions

Verified Answers let you pre-approve responses to specific questions that the model should always answer the same way. They are stored at the model level and propagate to every Data Agent that uses the model.

// Verified Answer examples (configured in Power BI Service)

Q: "What is our total revenue this year?"
A: [Configured DAX query returning [Net Revenue] for current fiscal YTD,
    with the approved visualization type and formatting]

Q: "How many active customers do we have?"
A: [Configured DAX returning customer count where [Customer Status] = 'Active'
    as of the most recent date in the model]

Q: "What is our NPS score?"
A: [Configured query against the NPS survey model with the approved
    calculation methodology, not an approximation]

Verified Answers are particularly important for sensitive business metrics that have precise approved definitions — revenue, headcount, NPS, churn rate. Without them, agents will generate their own DAX approximations that may be close but not match the official figures, creating inconsistency between agent-driven analytics and official BI reporting.

3.3 Row-Level Security Inheritance

One of the most architecturally important properties of the Fabric semantic layer is that Row-Level Security defined on a semantic model is automatically inherited by every Data Agent and MCP client that uses it. An agent querying a semantic model on behalf of a user sees exactly the data that user is entitled to see — no more. RLS roles defined for regional sales managers, for example, automatically constrain what agents can return for those users, without any additional configuration at the agent layer.

// Example RLS rule defined on semantic model
// (automatically enforced for all agent queries)

[Sales Territory Manager RLS]
=
[Territory].[Territory Manager Email] = USERPRINCIPALNAME()

// Effect: a sales manager in the Northeast asking an agent 
// "show me all territory performance" sees only their territory.
// This behavior requires zero additional agent configuration —
// it's inherited from the semantic model.

This is a critical governance property that distinguishes Fabric’s semantic layer approach from building agents directly on warehouse tables with custom permission logic. Custom permission logic in agent prompts is brittle, hard to audit, and doesn’t inherit organizational policy updates automatically.

IV. Fabric IQ Ontology: Adding Operational Context (Tier 3)

Power BI semantic models are excellent for analytical questions about historical data. But a growing class of agentic use cases requires operational intelligence — understanding what is happening in the business right now, reasoning about live business entities, and taking actions based on current state.

Fabric IQ Ontology addresses this. An Ontology item in Fabric defines business entities, their properties, the relationships between them, the rules that govern their behavior, and the actions that can be triggered when conditions are met. It binds to both historical data in a Lakehouse or Warehouse and to real-time streaming data in an Eventhouse — making it a live operational model of the business.

4.1 Creating an Ontology from a Semantic Model

The fastest path to an Ontology is to generate it from an existing, well-structured semantic model. This is the recommended starting point for organizations that have already invested in Power BI semantic modeling.

In the Fabric workspace:

New item → Ontology → Generate from semantic model

Select the semantic model. Fabric IQ will auto-generate entity types from dimension tables, infer relationships from the model’s relationship graph, and propose property bindings from columns and measures. The auto-generated ontology is a starting point — you will enrich it, not ship it directly.

For organizations without a semantic model (greenfield), or for entity types that don’t map cleanly to an existing model, you build the ontology manually from OneLake:

New item → Ontology → Build directly from OneLake

4.2 Defining Entity Types and Property Bindings

After generation, the core modeling work is defining entity types with rich property bindings. Each entity type represents a real business concept — Customer, Order, Product, Store, Employee — with properties drawn from multiple data sources.

The Ontology editor in Fabric provides a visual canvas for this work. The key configuration steps:

Entity type definition:

// Entity type: Customer (conceptual representation)
{
  "entityType": "Customer",
  "description": "A business or individual with an active or historical 
                  commercial relationship with the organization",
  "primaryKey": "customer_id",
  "dataSource": "dim_customer (Lakehouse: SalesLakehouse)",
  
  "properties": [
    {
      "name": "Customer Name",
      "sourceColumn": "customer_legal_name",
      "description": "Legal entity name as registered"
    },
    {
      "name": "Segment",
      "sourceColumn": "customer_segment_code",
      "description": "Enterprise (ENT), Mid-Market (MID), or SMB. 
                      Do not use company size as a proxy for segment."
    },
    {
      "name": "Annual Contract Value",
      "sourceColumn": "acv_usd",
      "description": "Annualized contracted revenue in USD. 
                      Excludes professional services."
    },
    {
      "name": "Health Score",
      "sourceColumn": "cs_health_score",
      "description": "Customer success health score 0-100. 
                      Updated nightly. Below 40 = at-risk."
    }
  ]
}

Live signal binding (Eventhouse integration):

One of Ontology’s most powerful capabilities is binding real-time streaming signals from Eventhouse to entity properties. This gives agents live operational awareness — not just historical records.

// Eventhouse KQL table: customer_activity_stream
// Columns: customer_id, event_type, event_timestamp, session_duration_seconds

// Bind to Customer entity as a live property
// Property: "Last Active"
// Binding query (evaluated in real-time):
customer_activity_stream
| where event_timestamp > ago(7d)
| summarize LastActive = max(event_timestamp) by customer_id
| project customer_id, LastActive

With this binding, when an agent asks “which enterprise customers haven’t been active in the last 30 days,” the Ontology resolves the answer using live Eventhouse data, not a stale nightly batch. The semantic layer becomes a live operational model, not a historical archive.

4.3 Relationship Modeling

Relationships between entity types define how agents can traverse the business knowledge graph. Well-defined relationships enable multi-hop reasoning — an agent can navigate from Order → Customer → Contract → SupportTicket because the ontology explicitly defines how those entity types connect.

// Relationship: Customer → Orders (one-to-many)
{
  "relationship": "Customer.has_orders",
  "from": "Customer",
  "to": "Order",
  "cardinality": "one-to-many",
  "joinCondition": "Customer.customer_id = Order.customer_id",
  "description": "All orders placed by this customer, 
                  including historical and open orders"
}

// Relationship: Customer → Contracts (one-to-many)  
{
  "relationship": "Customer.has_contracts",
  "from": "Customer",
  "to": "Contract",
  "cardinality": "one-to-many",
  "joinCondition": "Customer.customer_id = Contract.customer_id",
  "description": "All active and historical contracts for this customer"
}

// Relationship: Order → Product (many-to-many via order lines)
{
  "relationship": "Order.contains_products",
  "from": "Order",
  "to": "Product",
  "via": "OrderLine",
  "description": "Products included in this order, accessed through order lines"
}

With these relationships defined, an agent asked “which enterprise customers have open orders but no active support contracts” can traverse the graph correctly — without the agent needing to know the underlying table structure, join keys, or the distinction between contract_status = 'ACTIVE' and contract_status = 'EXPIRED'.

4.4 Rules and Actions

Ontology introduces rule definitions — conditional logic that fires when entity state meets specified conditions — and action bindings that connect rule outcomes to downstream workflows.

// Rule: At-Risk Customer Detection
{
  "rule": "CustomerAtRisk",
  "entityType": "Customer",
  "condition": "Health Score < 40 AND Last Active > 21 days ago",
  "severity": "high",
  "description": "Customer shows signals of churn risk",
  "actions": [
    {
      "type": "notify",
      "target": "customer_success_team",
      "template": "at_risk_alert"
    },
    {
      "type": "tag",
      "property": "risk_flag",
      "value": "at_risk"
    }
  ]
}

For agents, rules serve as guardrails and action triggers. An Operations Agent configured to monitor customer health can evaluate this rule across all customers in real-time, generate alerts, and initiate workflows — all grounded in the ontology’s definitions rather than ad hoc logic embedded in the agent prompt.

V. Exposing the Semantic Layer via MCP (Tier 4)

With the semantic model configured (Tier 2) and the ontology built (Tier 3), the final architectural step is exposing the semantic layer as consumable MCP endpoints — making it accessible to any agent, inside or outside Microsoft’s ecosystem.

Microsoft has published a constellation of MCP servers that expose different facets of the Fabric platform. For semantic layer consumption, three are critical.

5.1 The Fabric MCP Server (Core)

The @microsoft/fabric-mcp package is the primary entry point for agent developers. It provides control-plane access to the Fabric workspace — discovering assets, reading metadata, and navigating the catalog.

# Install via npx — works in VS Code, Claude Desktop, Cursor, and any MCP-compatible client
npx @microsoft/fabric-mcp

// mcp.json configuration
{
  "servers": {
    "fabric-core": {
      "type": "stdio",
      "command": "npx",
      "args": ["@microsoft/fabric-mcp"],
      "env": {
        "FABRIC_WORKSPACE_ID": "<your-workspace-id>",
        "FABRIC_TENANT_ID": "<your-tenant-id>"
      }
    }
  }
}

This server exposes workspace navigation, asset discovery, and metadata retrieval. It’s the foundation that lets an external agent understand what’s available in a Fabric workspace before deciding which more specific tool to invoke.

5.2 Data Agent as MCP Server

A Fabric Data Agent can itself be exposed as an MCP server — a critical capability that lets you encapsulate the full semantic layer (semantic model + ontology + governance) behind a single tool endpoint that any MCP client can call.

Creating and configuring a Data Agent:

In the Fabric workspace:

New item → Data Agent

Configure data sources (up to five per agent):

Data Sources:
✓ Sales Semantic Model    (Power BI semantic model — analytical layer)
✓ Customer Ontology       (Fabric IQ Ontology — operational layer)  
✓ Support Tickets LH      (Lakehouse table — raw support data)
✓ Real-Time Sales EH      (Eventhouse KQL database — live signals)

Configure agent instructions:

You are a revenue and customer intelligence agent for [Company Name].

You have access to four data sources:
1. Sales Semantic Model: Use for historical revenue analysis, cohort analysis, 
   and any questions involving financial metrics. Always use [Net Revenue] 
   as the revenue measure unless gross figures are explicitly requested.

2. Customer Ontology: Use for questions about current customer state, 
   health scores, at-risk customers, and operational customer data. 
   The ontology reflects live data as of the last sync.

3. Support Tickets Lakehouse: Use for support volume analysis, ticket 
   categorization, and CSAT trends.

4. Real-Time Sales Eventhouse: Use when questions require data from 
   the last 24 hours. Default to the semantic model for anything older.

Always cite your data source when providing figures. When a question 
touches multiple sources, make clear which figures come from which source.

Exposing as MCP server:

In the Data Agent settings → Model Context Protocol tab:

// Download the mcp.json file from the MCP tab
// and configure in your agent client:
{
  "servers": {
    "revenue-intelligence-agent": {
      "type": "http",
      "url": "https://api.fabric.microsoft.com/v1/workspaces/{workspace-id}/dataagentelements/{agent-id}/mcp",
      "headers": {
        "Authorization": "Bearer ${FABRIC_ACCESS_TOKEN}"
      }
    }
  }
}

With this configuration, any MCP-compatible agent client — Claude Desktop, VS Code with Copilot, a custom Foundry agent, a LangChain orchestrator — can invoke the Data Agent as a tool. The agent client sends a natural language question; the Data Agent routes to the correct data source, generates the appropriate query (DAX for semantic model, KQL for Eventhouse, SQL for lakehouse), executes it under the user’s identity with full RLS enforcement, and returns a structured, grounded answer.

5.3 Ontology MCP Server

For agents that need direct access to the ontology knowledge graph rather than routing through a Data Agent, Fabric IQ Ontology exposes its own MCP server endpoint.

// Ontology MCP server configuration
// Workspace ID and Ontology Item ID are found in the Fabric portal
{
  "servers": {
    "customer-ontology": {
      "type": "http",
      "url": "https://api.fabric.microsoft.com/v1/workspaces/{workspace-id}/ontologies/{ontology-id}/mcp",
      "headers": {
        "Authorization": "Bearer ${FABRIC_ACCESS_TOKEN}"
      }
    }
  }
}

The Ontology MCP server exposes the ontology as a navigable knowledge graph. External agents — including Claude, GitHub Copilot, and custom-built Foundry agents — can discover entity types, traverse relationships, query live property values, and evaluate rules against current entity state.

Important versioning note: Once external agents are pointing at an Ontology MCP endpoint, the ontology becomes a public API contract. Removing entity types, renaming properties, or changing binding logic are breaking changes that affect every agent consuming the endpoint. Treat the ontology with the same semantic versioning discipline you’d apply to a production REST API: change logs, deprecation periods, and consumer notification before breaking changes ship.

VI. Multi-Agent Architecture: Fabric as the Data Plane

The most architecturally sophisticated deployment of the Fabric semantic layer is as the data plane for a multi-agent system. Rather than one agent that does everything, specialized agents handle different domains, each grounded in the relevant semantic layer resources, coordinated by an orchestrator.

# Example: Multi-agent revenue intelligence system
# Orchestrated via Azure AI Foundry / LangChain
# Each agent connects to Fabric via MCP

from langchain_mcp import MCPClient
from langchain.agents import AgentExecutor, create_tool_calling_agent
from langchain_openai import AzureChatOpenAI

llm = AzureChatOpenAI(
    azure_deployment="gpt-4o",
    api_version="2024-12-01-preview"
)

# ── Agent 1: Revenue Analyst ───────────────────────────────────────────────
# Grounds in the Sales Semantic Model via Data Agent MCP
revenue_mcp = MCPClient(server_url="https://api.fabric.microsoft.com/v1/...revenue-agent/mcp")
revenue_tools = revenue_mcp.get_tools()

revenue_agent = AgentExecutor(
    agent=create_tool_calling_agent(llm, revenue_tools, revenue_prompt),
    tools=revenue_tools,
    verbose=True
)

# ── Agent 2: Customer Intelligence ────────────────────────────────────────
# Grounds in Customer Ontology MCP — live operational customer state
customer_mcp = MCPClient(server_url="https://api.fabric.microsoft.com/v1/...customer-ontology/mcp")
customer_tools = customer_mcp.get_tools()

customer_agent = AgentExecutor(
    agent=create_tool_calling_agent(llm, customer_tools, customer_prompt),
    tools=customer_tools,
    verbose=True
)

# ── Agent 3: Operations Monitor ───────────────────────────────────────────
# Grounds in Eventhouse KQL for real-time signals
rti_mcp = MCPClient(server_url="https://api.fabric.microsoft.com/v1/...rti-agent/mcp")
rti_tools = rti_mcp.get_tools()

operations_agent = AgentExecutor(
    agent=create_tool_calling_agent(llm, rti_tools, operations_prompt),
    tools=rti_tools
)

# ── Orchestrator: Routes questions to the right specialist ────────────────
def route_and_orchestrate(user_question: str) -> str:
    """
    Orchestrator determines which agent(s) to invoke and synthesizes results.
    Historical analytics → Revenue Agent
    Current customer state → Customer Agent  
    Live operational data → Operations Agent
    Complex questions spanning domains → Multiple agents in sequence
    """
    routing_response = llm.invoke(
        f"""Given this question: "{user_question}"
        
        Determine which of these agents should handle it:
        - revenue_agent: historical metrics, revenue analysis, cohorts, trends
        - customer_agent: current customer state, health scores, at-risk customers
        - operations_agent: real-time signals, last 24 hours, live monitoring
        - multiple: question requires data from more than one domain
        
        Return JSON: {{"agents": ["agent1", "agent2"], "sequence": "parallel|sequential"}}"""
    )
    
    routing = json.loads(routing_response.content)
    
    results = {}
    for agent_name in routing['agents']:
        agent = {
            'revenue_agent': revenue_agent,
            'customer_agent': customer_agent,
            'operations_agent': operations_agent
        }[agent_name]
        results[agent_name] = agent.invoke({"input": user_question})
    
    # Synthesize results if multiple agents responded
    if len(results) > 1:
        synthesis = llm.invoke(
            f"Synthesize these responses to: '{user_question}'\n\n" +
            "\n\n".join([f"{k}: {v['output']}" for k, v in results.items()])
        )
        return synthesis.content
    
    return list(results.values())[0]['output']

This architecture gives each agent a focused, semantically rich context — the revenue agent doesn’t have to reason about live customer health, and the customer agent doesn’t have to navigate the full semantic model. Each is grounded in the specific slice of the semantic layer most relevant to its domain.

All three agents share the same underlying governance: the same Purview DLP policies, the same Entra identity model, the same RLS enforcement. Governance at the Fabric layer propagates automatically to every agent in the ecosystem.

VII. Governance, Security, and Production Operations

7.1 The Governance Stack

The Fabric semantic layer for agents inherits a comprehensive governance stack that addresses the three most common enterprise concerns about AI agents: data access control, compliance monitoring, and auditability.

Identity and access: Every agent call flows through Entra ID. Agents operate under either a user-delegated token (the agent acts as the calling user, inheriting their exact permissions) or a service principal (the agent acts under its own identity with explicitly granted permissions). User-delegated flow is appropriate for interactive agents; service principal flow is appropriate for automated or scheduled agents.

Row-Level Security: As established in Section III, RLS defined on semantic models is automatically enforced for all agent queries. There is no path to bypass RLS through agent invocation — the semantic model enforces it at the query execution layer.

Purview DLP: Data Loss Prevention policies applied to Fabric data sources constrain what agents can return. An agent querying a warehouse with a DLP policy restricting PII columns cannot return those columns, regardless of how the agent prompt is written.

DSPM for AI: The Data Security and Privacy Management for AI capability, introduced in the March 2026 update, adds a monitoring layer specifically for agent interactions — logging prompts and responses, flagging sensitive data exposure in agent outputs, and providing an audit trail of all agent data access. This is the compliance surface that makes agent deployments auditable.

7.2 Capacity and Cost Considerations

Fabric AI workloads consume capacity units (CUs) from your Fabric capacity. Understanding the consumption model is essential for production deployment planning.

Minimum requirements:

Data Agents: F2 capacity or Power BI Premium P1 with Fabric enabled
Ontology MCP: F2 or higher
AI Functions: F4 or higher recommended for production workloads

Cost drivers to monitor:

DAX query execution against semantic models (relatively efficient)
LLM token consumption for query generation (the dominant cost for high-volume agents)
KQL query execution against Eventhouse (efficient for filtered queries, expensive for full-table scans)
Ontology traversal for complex multi-hop queries

Capacity optimization:

# Pattern: Cache common agent responses to reduce redundant LLM + query execution

from functools import lru_cache
import hashlib

@lru_cache(maxsize=1000)
def cached_agent_query(question_hash: str, agent_name: str) -> str:
    """Cache agent responses for identical questions within a session.
    Use cautiously for real-time data queries where staleness is a concern."""
    pass

def get_cached_or_execute(question: str, agent, ttl_minutes: int = 15) -> str:
    question_hash = hashlib.md5(question.encode()).hexdigest()
    # Check cache with TTL logic
    # ...
    return cached_agent_query(question_hash, agent.__class__.__name__)

For high-volume deployments, response caching at the application layer is the most effective cost control mechanism. Common questions with stable answers (dashboard-level metrics, standard reports) are ideal candidates. Real-time operational queries should not be cached or should use very short TTLs.

7.3 Known Limitations and Production Caveats

Honest assessment of current limitations saves production incidents.

Complex DAX generation remains unreliable. The DAX generation tool in Data Agents handles straightforward aggregations, filters, and comparisons reliably. Complex DAX — time intelligence calculations, complex CALCULATE expressions, multi-table calculations with multiple filters — should be pre-built as named measures in the semantic model and referenced by name rather than generated on the fly. This is the most impactful quality improvement available for agent accuracy.

Data Agent MCP is officially supported only in VS Code. Other MCP clients (Claude Desktop, Cursor, custom frameworks) work if you configure authentication manually, but they’re not the officially supported path as of the writing of this article. Production deployments outside VS Code should have a tested authentication and error-handling strategy.

Ontology is still in preview. Fabric IQ Ontology reached expanded preview at FabCon Atlanta 2026 and is expected to reach general availability in the coming months per the Build 2026 announcements. Preview features can change. Don’t build production-critical workflows on the Ontology MCP endpoint without a mitigation plan for preview API changes. The semantic model + Data Agent path is GA and production-safe today.

Rate limits are real and underdocumented. During high-volume testing, throttling occurs at thresholds that aren’t clearly published and appear to be capacity-tier dependent. For customer-facing or high-volume internal agents, implement retry logic with exponential backoff and test load behavior at your expected peak query volume before production launch.

Authentication for multi-agent flows requires planning. In a multi-agent architecture where an orchestrator invokes specialist agents, each of which calls a Fabric MCP endpoint, the token acquisition chain can become complex. Service principals simplify this but require explicit permission grants. Delegated user tokens in multi-hop flows require careful handling of the on-behalf-of (OBO) OAuth flow. Design your authentication architecture before building agents, not after.

VIII. The Strategic Case for Building Here

The Microsoft Fabric semantic layer for agents makes a compelling case that deserves honest evaluation from teams choosing where to invest.

The case for building here:

Power BI semantic models already exist in most mid-large enterprises. They represent years of accumulated business logic — measure definitions, hierarchies, RLS configurations, validated metric calculations. Using this as the semantic foundation for agents doesn’t require rebuilding that knowledge; it extends it. For organizations already in the Microsoft ecosystem, this is the highest-ROI path to governed enterprise agents.

The MCP architecture is genuinely open. A Fabric Data Agent exposed as an MCP server is consumable by Claude, GitHub Copilot, Cursor, custom LangChain agents, or any other MCP-compatible client. The semantic layer isn’t locked inside Microsoft’s agent stack — it’s a governed data API that any agent can call. This is a meaningful architectural commitment that distinguishes Fabric’s approach from closed alternatives.

The governance properties are production-grade. RLS inheritance, Purview DLP enforcement, Entra identity integration, and DSPM for AI monitoring form a governance stack that most organizations would spend years building from scratch if they tried to replicate it outside the Fabric platform. For regulated industries and enterprises with serious data security requirements, this is the critical differentiator.

The honest caveats:

Ontology is still in preview and represents the most strategically important tier of the stack. Building on it now means accepting preview terms — APIs may change. The semantic model + Data Agent path is GA and the right production-safe choice today. Ontology is the right architectural investment for teams building toward the 2026–2027 platform direction.

Cloud-first design means the semantic ontologies and agent reasoning logs live in Microsoft’s tenant. For organizations in GDPR-regulated environments or with strict data residency requirements, the cross-geo processing and storage implications of agent calls need explicit compliance review.

Complex DAX generation quality is still the binding constraint on agent accuracy for analytical questions. The quality ceiling for analytical agents on Fabric today is set by the quality of your semantic model’s Prep for AI configuration, the richness of your AI Instructions, and the coverage of your Verified Answers — not by model capability.

IX. Where to Start: A Practical Onramp

The four-tier architecture can feel overwhelming as a starting point. Here is the minimum viable path to a production-grade semantic agent:

Week 1–2: Semantic model audit and Prep for AI configuration

Audit your existing semantic models for agent-readiness: naming conventions, measure documentation, RLS coverage
Use the Power BI Modeling MCP Server to generate and apply business-friendly naming at scale
Write AI Instructions covering your most common ambiguities
Configure Verified Answers for your 10–20 most frequently asked business questions

Week 3–4: Data Agent creation and testing

Create a Data Agent connected to your Prep for AI-configured semantic model
Write agent instructions that reinforce the semantic model’s AI Instructions
Test systematically: ask the 50 questions your business users most frequently ask, validate results against known correct answers
Expose the agent as an MCP server in VS Code for developer testing

Month 2: Governance and production hardening

Enable DSPM for AI for monitoring
Review and configure Purview DLP policies for the data sources your agent accesses
Establish load testing and retry logic
Deploy to your agent client of choice (Copilot Studio for M365 integration, or direct MCP for custom agent frameworks)

Month 3+: Ontology layer (when you need operational context)

Build the Ontology from your existing semantic model as a starting point
Enrich with Eventhouse real-time bindings for live signal properties
Configure rules for operational monitoring use cases
Expose via Ontology MCP for agents that need live entity traversal

The key principle: the semantic model + Data Agent path is production-ready today. Don’t wait for Ontology GA to start delivering value. Build the foundation correctly — with Prep for AI, strong naming, and good agent instructions — and the Ontology layer plugs in on top when you need it.

Getting Started

Documentation:

Fabric IQ Overview: learn.microsoft.com/en-us/fabric/iq
Data Agent Creation: learn.microsoft.com/en-us/fabric/data-science/concept-data-agent
Data Agent as MCP Server: learn.microsoft.com/en-us/fabric/data-science/data-agent-mcp-server
Semantic Model Best Practices for Data Agent: learn.microsoft.com/en-us/fabric/data-science/semantic-model-best-practices
Ontology Tutorial: learn.microsoft.com/en-us/fabric/iq/ontology/tutorial-0-introduction
Prep for AI Training Module: learn.microsoft.com/en-us/training/modules/fabric-prepare-semantic-layer

Fabric MCP Server:

npx @microsoft/fabric-mcp

Minimum capacity requirements: F2 capacity or Power BI Premium P1 with Microsoft Fabric enabled.

References

Microsoft Fabric Team. (2025, November). Fabric IQ: The Semantic Foundation for Enterprise AI. Microsoft Fabric Community Blog.
Microsoft Fabric Team. (2026, June). Fabric IQ: The Shared Context Layer for AI Agents and Real-Time Intelligence. Microsoft Build 2026.
Ulag, A. (2026, June). Microsoft Build 2026: Building Agentic Apps with Microsoft Fabric and Microsoft Databases. Microsoft Azure Blog.
Microsoft Learn. (2026). Fabric data agent creation. Microsoft Learn Documentation.
Microsoft Learn. (2026). Data agent as Model Context Protocol server (preview). Microsoft Learn Documentation.
Microsoft Learn. (2026). Semantic model best practices for data agent. Microsoft Learn Documentation.
Microsoft Learn. (2026). Tutorial Part 0: Introduction and Environment Setup — Ontology. Microsoft Learn Documentation.
Psistla, P. (2026, March). Preparing Semantic Models for AI in Microsoft Fabric. psistla.com.
Forrester Research. (2026, June). Combine Semantics, Ontology, and Knowledge Graphs For AI-Ready Data. Forrester Report.
Team 400. (2026, April). Exposing Fabric IQ Ontology as an MCP Server for External AI Agents. team400.ai.
Behera, J. (2026, May). Fabric as the Enterprise Data Layer: The MCP Constellation and Microsoft Foundry. Medium.
EPC Group. (2026, June). Microsoft Build 2026: Fabric IQ and Power BI: Why Semantic Models Are Becoming the Brain of AI Agents. epcgroup.net.
Anthropic. (2024). Model Context Protocol: Introduction. modelcontextprotocol.io.
Curry, B. (2024–2026). Vector1 Research Series on Production AI Architecture. Medium / vector1.ai.

About the Author

Brian Curry is a Kansas City–based AI researcher, data scientist, and founder of Vector1 Research, where he works at the intersection of cognitive AI architecture, enterprise data platforms, and production AI systems. His practitioner work focuses on building knowledge engineering and causal inference systems deployable in enterprise environments, including semantic layer architecture for agentic AI.

He is the creator of Papilon (marketing mix modeling and complex systems) and MeaningFlow (semantic content modeling and gap analysis), and the author of Memory-Node Encapsulation (MNE), a novel architecture for artificial episodic memory.

Connect: Medium · LinkedIn · vector1.ai · brian@vector1.ai