Hello there and thank you for being a subscriber to The Data Massagist newsletter.

In this fourth edition, I will address a frequent question from customers and partners: How can I add graphs to the responses generated by a Data Agent in Microsoft Fabric? This topic also came up during last week’s Microsoft AI Tour in Mexico, where I had the opportunity to speak and meet many of you at the booth.

Microsoft Fabric is rapidly evolving from a unified data platform into a true intelligence platform, and AI agents are at the center of that transformation.

Two agent types are often confused: Fabric Data Agents and the newer Operations Agents. While both are “agents,” they serve fundamentally different purposes.

In this article we will explore:

• What a Data Agent in Microsoft Fabric is and how it works

• How it differs from the Operations Agent (real-time / operational reasoning)

• How to incorporate graph-based insights when working with a Data Agent

• A new architectural pattern: Data Agent + Microsoft Foundry for graph generation and orchestration

I hope you find this edition valuable. Let's go! ¡Vamos!

What Is a Data Agent in Microsoft Fabric?

A Fabric Data Agent is a governed conversational AI layer that allows users to ask natural-language questions over trusted enterprise data stored in Fabric and receive structured, reliable answers — without writing SQL, DAX, or KQL. They can be consumed from difference sources including Copilot Studio, AI Foundry, Microsoft Teams or any API endpoint.

A Data Agent can connect to Lakehouses, Warehouses, semantic models, KQL databases, and now, also to Ontologies in OneLake. Personally, I often recommend to my customers to connect the Data Agents to Semantic Models that were prepared for AI and are connected to tables in the gold layer. You can learn more about this by reading the edition #2 of this newsletter: The Real Magic Behind AI Accuracy Isn’t AI — It’s Your Data

Under the hood, the Data Agent uses Azure OpenAI Assistant APIs and behaves as a read-only reasoning agent. It:

1. Interprets user intent

2. Identifies the relevant governed data source

3. Generates the appropriate query (SQL, DAX, or KQL)

4. Validates permissions through Microsoft Entra ID

5. Returns a human-readable, trustworthy response

This makes Data Agents ideal for scenarios such as self-service analytics, executive Q&A, democratizing access to curated enterprise data, and explaining KPIs & trends - especially powerful when we customize it via agent AI instructions and semantic guidance. Of course, always fully governed by Microsoft Fabric security and permissions.

Data Agent vs. Operations Agent

Although both are called agents, they address completely different problem spaces.

In short, Data Agents explain the past and present. Operations Agents protect the future. This distinction is critical when designing an agent strategy in Fabric.

Data Agents explain the past and present. Operations Agents protect the future.

Data Agents in Microsoft Fabric

A Data Agent in Microsoft Fabric is essentially a virtual data analyst designed for business decision-makers. It gives leaders immediate, self-service access to insights by allowing them to ask questions in natural language and receive fast, governed, contextual answers based on enterprise data. Instead of waiting on analytics teams, executives can explore performance, trends, root causes, and business opportunities conversationally, accelerating decisions and reducing bottlenecks.

A Data Agent answers:

• Why did revenue drop in Q4?

• Which regions underperformed last month?

• What products are driving churn?

Users can use Data Agents inside Microsoft Fabric via a Copilot like interface. Also, they can be consumed vfrom Azure AI Foundry, Copilot in PowerBI, Microsoft Copilot Sudio, using Python SQK, Microsoft 365 Copilot (as an agent in the Microsoft 365 Marketplace) and as Model Context Protocol (MCP) Server in Visual Studio Code.

Technically, the Data Agent operates as a conversational query orchestration layer across Microsoft Fabric’s unified data foundation (Lakehouses, Warehouses, Semantic Models, KQL, Ontologies). It uses Azure OpenAI‑based LLM reasoning to parse intent, select optimal data sources, generate SQL/DAX/KQL, validate permissions, execute queries, and return structured, high‑fidelity answers. It enforces role-based security, provides schema‑aware reasoning, and supports custom instructions for domain accuracy. The Data Agent is read‑only and optimized for precision, governance, and safe enterprise‑grade analytics.

Data Agents explain the past and present. Operations Agents protect the future.

Do Data Agents let us choose which OpenAI model to use? No, Fabric Data Agents do not expose any setting that allows us to select or switch OpenAI models.

Operations Agent in Microsoft Fabric

Operations Agents are part of the workload Real-Time Intelligence (or RTI). An Operations Agent is a virtual operations supervisor designed to safeguard business continuity. Instead of reacting to issues after they become problems, it continuously monitors live signals—like processes, pipelines, service health, KPIs, and anomalies—and proactively recommends or triggers actions. Executives rely on it to reduce operational risk, shorten incident response times, and keep mission-critical processes running smoothly.

In other words, an Operations Agent continuously monitors signals and:

• Detects anomalies

• Identifies root causes

• Recommends or triggers actions

• Integrates with Teams, Power Automate, and operational systems

From the technical perspective, the Operations Agent is a stateful, always‑on agent that ingests streaming telemetry from Eventhouse and KQL databases. It constructs rule sets, context graphs, and monitoring playbooks using business goals and provided actions. The agent evaluates conditions in real time, detects anomalies or threshold breaches, and uses LLM reasoning to generate recommended actions routed to Teams or automation endpoints. Unlike the Data Agent, the Operations Agent can initiate actions (with optional human approval), making it part of a closed-loop autonomic operations system.

Similar to Fabric Data Agents, Operations Agents also use a Microsoft‑managed model with no exposed OpenAI model selection.

Can a Data Agent Create Visuals or Graphs?

As said, this is a common question as people get confused with the Copilot for PowerBI.

The answer is not yet. Why? Because Microsoft Fabric is a data platform in continue evolution and the engineering team led by Arun Ulag, Dipti Borkar, Bogdan Crivat, Yitzhak Kesselman , Shireesh Thota and many other brilliant minds are always innovating and adding features. You can check the roadmap here: https://aka.ms/fabricroadmap

Back to the question, Fabric Data Agents do not render charts, dashboards, or graphs inside the agent experience. Their responsibility is:

• Query orchestration

• Governed reasoning

• Structured textual answers

Visualization is intentionally handled by Power BI, Notebooks, and Graph in Fabric. In fact, many of my customers are using Data Agents connected to the same Sematic Model used by PowerBI reports to provide a cheaper but efficient way to chat with their data. Why? Because users of Copilot for PowerBI currently need a PowerBI Pro Licence.

Adding Graph-Based Insights to a Data Agent

Then, what we can do? While Data Agents cannot render graphs directly, graph-driven insights can be layered architecturally around them using the following three patterns.

Pattern 1 — Data Agent + Power BI Semantic Model

In my experience, this is the most common and production-ready approach as Data Agents respects semantic model logic and security and can explain results derived from those models.

To implement it, you should:

• Use a semantic model with relationships and measures

• Connect that model to the Data Agent

• Let the Data Agent answer what and why

• Let Power BI show how it looks

Best for

• KPI and trends analysis

• Dimensional relationships

• Trend and variance explanation

• Governed business metrics

Pattern 2 — Data Agent + Graph in Microsoft Fabric

For relationship-centric analytics, Fabric introduces a native graph engine built on OneLake.

Graph in Fabric enables:

• Nodes and edges modeling

• ISO-standard GQL querying

• Relationship exploration without heavy joins

• AI reasoning over connected data

Typical Use Cases

• Fraud and risk networks

• Customer and product relationships

• Supply chain dependencies

• Community and influence detection

In this pattern:

• Graph analytics compute relationships

• Power BI / Notebooks visualize them

• Data Agent explains the graph-derived insights conversationally

Graph in Fabric is currently in preview but represents the strategic direction for relationship intelligence in Fabric. To learn more: Graph in Microsoft Fabric Overview at Microsoft Learn

Pattern 3 — Data Agent + Microsoft Foundry (Agent Orchestration + Graph Generation)

If the previous pattern didn't meet your requirement, this third pattern is for you. It enables building a single AI application front door using Microsoft Foundry that orchestrates Fabric Data Agents and post-processes their structured output into graph visualizations.

When to Use

• You want one AI interface across multiple tools and data systems

• You need graph visualization generated dynamically from Data Agent results

• You want orchestration beyond Fabric (multi-agent / multi-tool)

Why It Works

• Data Agents provide governed, trusted reasoning over enterprise data

• Foundry Agent Service orchestrates tools via MCP and APIs

• Graphs can be generated from structured JSON returned by the Data Agent

Core Architectural Flow

Implementation Options

Currently, I see two architectural approaches for integrating a Fabric Data Agent into a graph-generation workflow orchestrated by Microsoft Foundry. They differ in maturity, supportability, and execution model.

In both cases, the key design principle is to ask the Data Agent to return structured output like:

1. Supported (Recommended) — Direct SDK Invocation Pattern

In this model, a component hosted within Microsoft Foundry invokes a Fabric Data Agent programmatically using the official Python SDK.

Execution Flow

1. The Foundry-hosted runtime (API, notebook, function, or backend service) authenticates against Microsoft Fabric using Entra ID.

2. The component calls the Fabric Data Agent through the Python client SDK (ask() operation).

3. The agent performs governed reasoning over Fabric data sources and returns a structured response, typically JSON.

4. The application parses the JSON payload and transforms it into a graph structure (nodes and edges).

5. A graph rendering library such as NetworkX, PyVis, or Graphviz generates a visual artifact (HTML, SVG, PNG, or interactive canvas).

6. The generated visualization is returned to the caller (Copilot, UI, dashboard, or API response).

Code sample

This sample uses the documented client calls:

• InteractiveBrowserCredential

• FabricDataAgentClient

• client.ask()

• optional client.get_run_details()

The output is an interactive "graph.html". If you want the code, follow me here in Linkedin and send me a private IM, I will send it to you.

Key Characteristics

• Fully supported and production-ready

• Uses documented SDK and security model

• Deterministic execution controlled by your application layer

• Clear separation between reasoning (Data Agent) and visualization (graph library)

• Easier observability, logging, and debugging

• Works in any runtime supported by Foundry

• Foundry Agent Service supports choosing models (e.g., GPT‑4.1, GPT‑4.1‑mini) and disallows unsupported ones

Architectural Role

The Data Agent acts purely as a governed reasoning engine, while the Foundry-hosted component performs post-processing and visualization generation.

2. MCP Tool Pattern (Experimental) — Agent-to-Agent Invocation

In this alternative model, the Fabric Data Agent is exposed as an MCP-compatible server, and a Foundry Agent connects to it as an MCP client.

Execution Flow

1. The Fabric Data Agent is published as an MCP server endpoint. However, Microsoft’s documentation says you can use the Data Agent MCP server only in VS Code right now.

2. A Foundry Agent registers that MCP endpoint as an external tool.

3. During execution, the Foundry Agent invokes the Data Agent via MCP. Learn more here Consume Fabric data agent from external applications with Python client SDK.

4. The Data Agent returns structured output (typically edges/nodes JSON - as commented before).

5. The Foundry Agent or downstream tool converts the structured response into a graph representation.

6. The graph is rendered and returned to the user or system.

Key Characteristics

• Agent-to-agent interaction instead of SDK-based invocation

• Enables fully composable multi-agent architectures

• Aligns with tool-based orchestration patterns in Foundry

• More dynamic and extensible than direct SDK calls

Current Limitation

At present, MCP consumption for Fabric Data Agents is primarily documented for use within development environments and is not yet broadly documented as a general production integration pattern. Therefore, this approach should be treated as emerging/experimental until broader runtime support is formalized.

Final Thoughts

Fabric Data Agents are not chatbots with charts or an alternative for Copilot for PowerBI. Fabric Data Agents are governed reasoning engines built on top of trusted enterprise data.

The newer Operations Agent expands Fabric into autonomous, real-time decision intelligence, while Graph in Fabric introduces relationship-aware analytics at scale.

Together, these capabilities move Fabric decisively from a data platform to an intelligence platform.

If you are designing an AI-first data architecture for 2026 and beyond, understanding how these agents work together is no longer optional — it is foundational.