When Microsoft announced that Fabric Data Agents reached general availability at FabCon 2026 — alongside the news that Fabric is now serving more than 31,000 customers, the fastest-growing data platform in Microsoft's history — I had the same reaction I always have when a platform vendor ships "agents": cautious interest, tempered by years of watching marketing outrun reality.

Then I read the actual documentation, tested the setup flow, and mapped the feature against what enterprises in Malaysia genuinely need. My conclusion: this one is worth your attention, but not for the reasons the launch blogs suggest. The interesting part isn't that Microsoft bolted a chatbot onto Fabric. It's that they built a read-only, identity-enforced, governance-aware conversational layer directly over OneLake — and that design decision changes everything about how you should evaluate it.

The Problem: The Data Grounding Gap

Every enterprise team I work with has the same frustration. You can build a Copilot Studio bot in an afternoon, but getting it to reliably answer questions that require joining data across your ERP, data warehouse, and operational systems takes months. The agent can talk, but it can't think over the data that actually matters.

The root cause is grounding. Point a large language model at raw warehouse tables and you get three failure modes:

  • Missing business semantics. The model sees cust_id in one table and customer_number in another and has no idea they're the same entity. It doesn't know whether "revenue" means gross or net, or whether intercompany sales are included.
  • Expensive RAG pipelines. The alternative — copy data out, chunk it, embed it, maintain a vector index — creates a second data estate that drifts out of sync with the first one. Every schema change becomes an integration project.
  • Governance holes. Most DIY patterns either embed everything (permission boundaries vanish) or pass user credentials through hand-written code that nobody wants to audit.

Fabric Data Agents attack the problem from the opposite direction: instead of moving data to the model, the model's queries run where the governed data already lives.

What a Fabric Data Agent Actually Is

Let me be precise, because precision matters here. A Fabric Data Agent is a conversational Q&A system that answers natural language questions over Fabric data sources. It is now generally available, and these are its defining characteristics:

  • Supported data sources: warehouses, lakehouses, Power BI semantic models, KQL databases (including Eventhouse), mirrored databases, ontologies, and Microsoft Graph. Each agent can use up to five data sources in any combination.
  • Read-only by design. This is the single most important fact about the product, and the one most launch coverage missed. Fabric Data Agents strictly enforce read-only connections. They don't trigger pipelines, don't run notebooks, don't modify anything. If you've seen demos implying agents "take action" on your warehouse, that's Operations Agents and Copilot Studio territory — a different capability.
  • No model plumbing required. You don't supply an Azure OpenAI key or manage tokens. Fabric uses a Microsoft-managed Azure OpenAI Assistant service and handles authentication for you.
  • Queries run as the requesting user. The agent reads schemas and executes SQL, DAX, or KQL only with the data the asking user can already access. Least privilege is enforced by identity, not by prompt engineering.

Under the hood, the flow is: question parsing against security and responsible-AI policies, identification of the most relevant data source, then query generation — NL2SQL for lakehouses and warehouses, NL2DAX for semantic models, NL2KQL for KQL databases — followed by validation, execution, and a human-readable answer.

Where It Sits in Fabric IQ

Microsoft introduced Fabric IQ at Build 2026 — now generally available — as the business context layer for agents. Three layers matter here:

  1. Unified Data — your estate in OneLake, with shortcuts to SharePoint and OneDrive now GA, and shortcuts from Fabric Data Warehouses in preview.
  2. Business Intelligence — governed Power BI semantic models that encode business definitions.
  3. Operational Intelligence — ontologies (in preview) that model business entities, relationships, rules, and actions.

Data Agents consume all three. When you ask "What were our top 10 customers by revenue in Q1?", a well-configured agent resolves "revenue" against your semantic model rather than guessing from a column name. That semantic grounding is the difference between a demo and something a CFO will sign off on.

Setting Up Your First Data Agent

Here's the practical walkthrough, based on the GA product.

Step 1: Capacity and Tenant Settings

Prerequisites: an F2 or higher Fabric capacity (or Power BI Premium P1+ with Fabric enabled), plus at least one supported data source with data in it.

Enablement is done in the Fabric Admin Portal → Tenant settings — there's no API for this part, and don't let anyone tell you otherwise:

  • Users can use Copilot and other features powered by Azure OpenAI — the master switch.
  • Capacities can be designated as Fabric Copilot capacities — lets capacity admins assign Copilot capacity.
  • Cross-geo processing and storage settings — and this one matters for Malaysia.

Malaysia note: if your Fabric capacity sits outside the EU data boundary and the US — which Malaysian capacities do — you must explicitly enable the tenant settings allowing data sent to Azure OpenAI to be processed, stored, and (for conversation history) held outside your capacity's region. These settings may take up to an hour to propagate. For organizations subject to PDPA or sector regulations, this is a documented, deliberate consent decision — get it approved by your compliance owner before flipping the switch, and record the decision.

Step 2: Create the Agent and Select Data Sources

In your workspace, create a new Data agent item, name it (e.g., "Finance Q&A"), and select its data sources. Remember the five-source limit — it's a design constraint, not an inconvenience. It forces you to scope each agent to one business domain, which is exactly the governance posture you want.

Step 3: Instructions and Example Queries

This is where quality is won or lost. You can add:

  • Organization-specific instructions — plain-language guidance on terminology, tone, and how to interpret ambiguous questions.
  • Example queries — up to 100 per data source. Seed these with the questions your business users actually ask, including the tricky ones with known joins and filters.
  • Data source guidance — hints about which source covers which topic.

The improved NL2SQL engine (preview as of mid-2026) uses these example queries to follow your team's patterns and asks clarifying questions when intent is ambiguous. Invest in examples early; it's the highest-leverage hour in the whole setup.

Step 4: Bring Outside Data In — The Right Way

If your source data lives outside Fabric, there are two correct patterns:

OneLake shortcuts for lake and file-based sources — ADLS Gen2, Amazon S3, Google Cloud Storage, Azure Blob, Dataverse, SharePoint/OneDrive. You can create them programmatically via the Fabric REST API:

# Get a Fabric API token with the Azure CLI
TOKEN=$(az account get-access-token \
  --resource https://api.fabric.microsoft.com \
  --query accessToken -o tsv)

# Create an ADLS Gen2 shortcut inside a lakehouse item
curl -s -X POST \
  "https://api.fabric.microsoft.com/v1/workspaces/${WORKSPACE_ID}/items/${LAKEHOUSE_ITEM_ID}/shortcuts" \
  -H "Authorization: Bearer ${TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "Tables/landing",
    "name": "PartnerProducts",
    "target": {
      "adlsGen2": {
        "location": "https://contosoadls.dfs.core.windows.net",
        "subpath": "/mycontainer/data/ContosoProducts",
        "connectionId": "91324db9-8dc4-4730-a1e5-bafabf1fb91e"
      }
    }
  }'

Note the endpoint shape: shortcuts hang off /v1/workspaces/{workspaceId}/items/{itemId}/shortcuts — the item being your lakehouse — and the target must specify exactly one supported destination. OneLake shortcuts do not point at Azure SQL tables; for operational databases, use mirrored databases, which are a first-class Data Agent data source and keep operational data queryable without ETL.

Step 5: Test, Then Choose Your Channel

Test in the built-in chat pane, then share. As of June 2026, Data Agents can be published into Microsoft 365 Copilot (GA — business users discover and chat with your agent inside M365 Copilot with Entra ID permissions enforced), embedded in Copilot Studio bots, consumed as a tool by Microsoft Foundry agents (with observability telemetry in preview), or exposed as an MCP server for other agent ecosystems.

Where Does This Fit? The Decision Framework

Use Fabric Data Agents when your data lives in Fabric, the job is governed Q&A and conversational analytics, and the team building it is data-focused rather than AI/ML-focused. Time-to-value is hours, not weeks.

Use Copilot Studio when you need external channels (Teams, web chat, WhatsApp), multi-turn orchestration, or a customer-facing bot. A Fabric Data Agent can be embedded as a capability inside a Copilot Studio bot — that combination covers most internal scenarios cleanly.

Use Azure AI Foundry Agent Service when you need full control: custom tools, external APIs, specific models, multi-agent routing. You pay for that control in engineering effort.

For most Malaysian enterprises I advise, the honest answer is: start with a Fabric Data Agent on your highest-value governed dataset, and only escalate to Foundry when you hit a requirement Data Agents genuinely can't express.

Governance: The Part That Actually Matters

This is where Fabric Data Agents earn enterprise trust:

  • Identity-enforced access. Every query executes under the asking user's Entra ID identity and workspace permissions. No service-principal loophole, no shared credential.
  • Semantic model security carries through. Row-level and column-level security defined on Power BI models apply to agent answers. Model-level Read permission is sufficient — no workspace membership needed.
  • Microsoft Purview integration. Purview DLP policies for Fabric Data Warehouse are GA and can restrict agent access to sensitive assets; access restriction policies for KQL and SQL databases are in preview. Agent prompts and responses can flow into Purview audit, eDiscovery, and retention.
  • Azure AI Content Safety can be layered on to screen responses.
  • Workspace outbound access protection (preview) governs what external endpoints agents may reach.

For Malaysian banks and GLCs that must demonstrate data access controls to regulators, this audit chain — identity in, policy enforcement, logged prompts and responses out — is the feature that turns a pilot into a production approval.

Limitations Nobody Demos

I'll save you the discovery cycle:

  1. Answers are capped at 25 rows and 25 columns. Data Agents are built for conversational insight, not data export. If users need full datasets, that's a report or an API, not an agent.
  2. Strictly read-only. No pipeline triggers, no notebook runs, no writes. Plan around it rather than against it.
  3. Chat history influences follow-ups. A narrowed earlier answer constrains later ones; starting a fresh session is sometimes the correct debugging step.
  4. Five data sources per agent. Decompose by business domain.
  5. Cross-geo consent is mandatory outside EU/US. For Malaysian capacities, that's a compliance decision, not a checkbox.
  6. Purview policies can truncate or block answers. Expected behavior — but set user expectations, or they'll report "the agent is broken."

What This Means for Malaysian Enterprises

Most enterprises here are data-rich but insight-poor. The bottleneck was never the warehouse — it was getting business users to use the data. SQL skills are scarce, report queues are long, and data teams are backlogged. Data Agents remove the query-language barrier while keeping governance intact, which is the combination Malaysian compliance environments actually permit.

If you're already on Fabric, this is an incremental capability on capacity you already pay for. If you're evaluating Fabric for modernization, Data Agents strengthen the business case: you're not just building a data platform, you're building the interface people will actually talk to.

Key Takeaways

  1. Fabric Data Agents are GA, read-only, and identity-enforced — conversational Q&A over up to five Fabric data sources, with queries executing under each user's own permissions. No keys, no RAG pipeline, no vector store.
  2. Semantic models and ontologies are the differentiator — NL2SQL/NL2DAX/NL2KQL over governed business definitions is what makes answers trustworthy instead of plausible.
  3. Governance is architectural, not procedural — Entra ID enforcement, RLS/CLS inheritance, and Purview DLP/audit give you an evidence chain your regulators can inspect.
  4. Know the constraints before promising anything — 25-row caps, five sources, read-only, and mandatory cross-geo consent for Malaysian capacities.
  5. Position it correctly — Data Agents for governed answers, Copilot Studio for channels and orchestration, Foundry Agent Service for full custom control. They compose; they don't compete.