In Microsoft Fabric, AI is not a separate sidecar experience bolted onto the platform. It is woven into the tools that teams already use: Power BI for semantic modeling and reporting, notebooks for code authoring, pipelines for orchestration, SQL experiences for warehousing, and Data Agents for natural-language question answering over governed data.

It helps to think about Fabric AI in two categories:

• Copilot: the interactive AI assistant that helps authors generate code, visuals, queries, summaries, and pipeline logic.
• AI features: built-in platform capabilities such as Data Agents that let you operationalize AI inside analytics workflows, plus authoring aids like Skills for Fabric.

What Copilot helps with

Prepare your data for AI

Copilot quality is strongly tied to semantic model quality. Keep this page focused on the essentials, then use the full guide in Best Practices → Preparing Data for AI for implementation detail.

• AI data schema: expose the most meaningful fields and hide noisy internal columns.
• AI instructions: add business context, preferred measures, terminology, and analysis rules.
• Verified answers: curate trusted responses for common executive or operational questions.

Prompts that usually work well

Limitations to keep in mind

• Copilot does not transform or repair your underlying data; it works with the model it is given.
• Results are better when measures, hierarchies, and descriptions are well defined.
• Generic or ambiguous models often produce vague visuals or incorrect metric choices.
• Generated output should be reviewed by a report author before publication.

Notebook Copilot is especially useful when you know the transformation you want but do not want to spend time writing boilerplate PySpark, fixing syntax, or documenting every step by hand. It can work across authoring, explanation, and debugging loops.

Best practices for better notebook results

• Use clear variable and dataframe names: names like sales_df and customer_dim provide far more context than df1 and tmp.
• Break work into logical cells: ingestion, cleansing, enrichment, and publish steps are easier for Copilot to understand than one monolithic script.
• Show intent in markdown cells: short headings and notes help both humans and Copilot follow the flow.
• Ask for one transformation at a time: iterative prompting usually produces better code than a giant multi-step prompt.
• Validate generated code against your runtime and libraries: Copilot can still suggest patterns that need adaptation.

Context awareness and cell behavior

Copilot can use the surrounding notebook context — prior cells, variable names, dataframe references, and markdown explanations — to generate more relevant code. It is particularly effective when your notebook has a clean narrative structure.

It can also help with IPython magic commands and notebook-specific behavior, such as working with %run, switching between Python and Spark SQL contexts, or explaining how a cell's output feeds the next step. Still, you should verify that generated magic commands and session assumptions match your Fabric runtime.

Generate PySpark code to read the bronze_orders Delta table,
filter to the current month, and aggregate revenue by sales region.

Explain why this merge statement fails with a duplicate key error.

Add markdown documentation for this notebook section in a concise,
team-friendly style.

Refactor this cell so it writes a partitioned Delta table and includes
basic error handling.

Where it helps most

• Natural language to pipeline creation: describe the source, transformation step, and destination to scaffold a pipeline.
• Activity suggestions: get recommendations for copy, notebook, dataflow, wait, condition, loop, and notification patterns.
• Expression generation: generate dynamic content for file paths, parameters, dates, branching logic, and output references.

Example prompts

Create a pipeline that copies daily CSV files from ADLS into a bronze
lakehouse folder and then runs a notebook to convert them to Delta.

Generate a dynamic expression that writes files to /raw/year=YYYY/month=MM/day=DD.

Suggest activities to retry a failed API extract, log the error, and send
an alert if the retry count is exceeded.

Current limitations

• Copilot is best used to create a starting point, not a fully production-hardened orchestration pattern.
• You still need to validate connection references, parameters, credentials, and environment-specific settings.
• Complex branching, custom expressions, and enterprise error handling usually need manual refinement.
• Generated logic should be tested in realistic failure scenarios before release.

Copilot for SQL is valuable when analysts or engineers understand the question they want answered but need help turning that requirement into valid T-SQL. It can also help explain legacy code, generate comments, and suggest improvements when a query is hard to maintain.

Where it works

These capabilities are most relevant in Fabric Warehouse and the SQL analytics endpoint, where teams author and review SQL over governed Fabric data.

Prompt patterns that work well

• Write a T-SQL query that returns the top 10 customers by net revenue in the last rolling 90 days.
• Explain what this query is doing and identify why it may return duplicate rows.
• Refactor this nested query into CTEs with comments for each step.
• Suggest a more efficient way to calculate monthly active users by product line.

What a Data Agent actually is

A Fabric data agent is a first-class Fabric item (created via + New Item → Fabric data agent) that turns governed OneLake data into a plain-English Q&A experience. Behind the scenes it uses a Microsoft-managed Azure OpenAI Assistant plus natural-language-to-query engines — NL2SQL, NL2DAX, NL2KQL, NL2GQL and NL2Ontology — to translate a question into a query against the sources you selected.

The distinction versus Copilot matters: Copilot is preconfigured and assists you inside a Fabric tool. A data agent is a standalone artifact you configure, publish, share, version in Git, and promote through deployment pipelines.

Supported data sources

An agent supports up to five data sources in any combination — five semantic models, or a mix of two semantic models, a lakehouse, and a KQL database. The current source catalog is broader than the older concept pages suggest:

The four tuning layers — where answer quality is actually won

Most disappointing data agents are under-configured, not under-powered. Configuration is a layered model, and knowing which layer to fix is the core operating skill:

Microsoft publishes a recommended structure for agent instructions — use these headings verbatim as a starting template:

## Objective
What this agent is for, and who asks it questions.

## Data sources
Which source answers which kind of question (this drives routing).

## Key terminology
Acronyms, KPI definitions, what "active customer" or "MAU" means.

## Response guidelines
Tone, level of detail, when to show numbers vs. narrative.

## Handling common topics
Recurring question shapes and how to treat them.

And for data source instructions, which feed the NL2X engine directly:

## General knowledge
Authoritative tables, default filters, fiscal calendar, time zone rules.

## Table descriptions
Grain of each table (one row per order? per order line? per day?),
dedup rules, and join keys.

## When asked about
Map user terminology to stored values, e.g. "region" means
DimGeography.RegionName, and status "complete" means StatusCode = 'AP'.

Example queries — the few-shot layer

Example question/query pairs are few-shot learning. At question time the agent retrieves the most relevant examples by vector similarity and passes the top few into the prompt (docs say three in one place and four in another). Key mechanics worth knowing:

• Hard cap of 100 example queries per data source.
• Every example is validated against the live schema — examples that fail validation are silently never used. A stale example is a dead example.
• Supported on Lakehouse, Warehouse, Eventhouse KQL, and Graph (preview). Not supported on semantic models or ontology.
• For semantic models, the equivalent tuning surface is Verified Answers in Power BI's Prep for AI, not example queries.
• For KQL, NL2KQL can use user-defined functions in your databases — include examples that call your UDFs.
• Inline comments inside the query are used as guidance, e.g. -- substitute customer_id here.

Security model

Microsoft documents an explicit precedence order when instructions conflict, highest to lowest: organizational intent (tenant policy) → role-based intent (workspace governance) → developer intent (your instructions and examples) → user intent (the prompt). Attempts to talk the agent out of read-only behavior are refused at a layer you don't control — which is the correct design.

Minimum permission per source type

If a user can open the agent but lacks permission on an underlying source, those queries fail with an authorization error or return empty results — a common and confusing support ticket. Note also that sharing an agent before publishing it means default-permission users can't query it at all.

Licensing, capacity, and tenant settings

• Capacity: a paid F2 or higher, or Power BI Premium P1+ with Fabric enabled.
• Tenant settings: "Users can use Copilot and other features powered by Azure OpenAI" must be on. If your capacity's region sits outside the EU data boundary and the US, you must also enable cross-geo processing and cross-geo storing — the latter because conversation history persists across sessions (up to 28 days if not manually cleared). Settings can take up to an hour to take effect.
• Billing: there is no data-agent-specific meter. Usage bills through the general Copilot in Fabric rates — per 1,000 tokens: 100 CU seconds input, 10 cached input, 400 output. Graph sources additionally incur graph operation consumption.
• Region: see the hard constraint below.

Consuming a published agent

Current limitations

• English only — questions, instructions, and example queries.
• Responses capped at 25 rows × 25 columns. Agents are built for conversational insight, not dataset export.
• You can't change the underlying LLM.
• Lakehouse answers come from selected tables, not standalone files — ingest CSV/JSON as tables first.
• Native unstructured content is unsupported (.pdf, .docx, .txt) — reachable only via an Azure AI Search index source Preview.
• Conversation history may not persist across service or model updates, and prior turns influence follow-ups — start a new chat when changing topic.
• No advanced analytics, ML, or causal inference natively — "why did this happen?" is out of scope unless you add the code interpreter tool Preview.
• Responses may be truncated or blocked by Purview DLP and access restriction policies; interactions are auditable and eDiscoverable.

Building one that actually works

1. Scope narrowly. One high-value domain per agent. An "everything agent" routes badly and answers vaguely.
2. Fix names before prompts. CustomerOrders and order_submission_date carry signal; Table1 and value do not. But don't rely on naming alone.
3. Select the minimum schema. Exclude staging, archive, and unrelated domains. Every extra object is another wrong path the query engine can take.
4. Declare grain and joins explicitly in data source instructions — one row per order, per order line, or per daily total changes every answer.
5. Define terminology and encodings. Does the state column store "CA" or "California"? Is the flag 1/0 or Y/N? Is currency dollars or cents?
6. Add examples only for hard patterns — multi-table joins, pre-aggregation, fiscal/relative dates, ranking and window functions. One reusable pattern per example; avoid overlapping or contradictory examples.
7. Debug at the closest layer. Read the generated query in run steps, then fix in this order: schema selection → schema description → data source instructions → example query.
8. Review before publishing — permissions, labels, and expected audience. Then version it in Git and promote via deployment pipelines.

Common use cases

What Skills for Fabric are

Skills for Fabric are reusable instruction files (SKILL.md) that teach AI coding tools how to work correctly with Fabric. They are not Fabric workspace items and they are not invoked at runtime from notebooks or pipelines. Instead, they give an AI assistant curated, Fabric-specific guidance so generated code follows the right patterns.

How they work

• Author a SKILL.md file: capture the task, the conventions, and the Fabric APIs or patterns the assistant should follow.
• Place it in your repository: the skill lives alongside your code so it is versioned and reviewable.
• Let the AI tool discover it: supported AI coding tools load the skill when the task matches its description.
• Share across the team: everyone working in that repository gets the same Fabric-aware guidance.

The main value is consistency: capture Fabric conventions once in version control, and every AI-assisted change in that repository benefits from them.

Three distinct layers are emerging, and they are frequently confused. Getting the mental model right saves a lot of wasted design effort:

MCP: Fabric as a tool for any AI client

Model Context Protocol is becoming Fabric's standard integration surface for external AI clients — VS Code, GitHub Copilot, Claude, Foundry agents, and custom orchestrators. Rather than one monolithic endpoint, Microsoft is shipping several MCP servers, each scoped to a workload:

Recent and emerging capabilities

How to adopt this without regret

1. Invest in the semantic layer first. Agents amplify whatever quality your model already has. Clear names, documented grain, certified measures, and endorsements pay off far more than prompt tinkering.
2. Start read-only. Prove value with Data Agents before granting anything the ability to act.
3. Pick one domain and one audience for your first agent, and measure answer accuracy against a fixed question set before widening access.
4. Set governance before scale — tenant settings, cross-geo choices, sensitivity labels, Purview DLP, and capacity region alignment.
5. Treat instructions and example queries as code. Version them in Git, review changes, and promote through deployment pipelines like any other Fabric item.

• Copilot respects existing permissions: workspace roles, semantic model permissions, and data-level controls still matter.
• Sensitivity labels still apply: if content is protected and the user is not authorized, Copilot should not become a bypass route.
• Admin controls matter: review tenant settings and workspace/capacity rollout strategy before broad enablement.
• Audit logging is essential: monitor Copilot activity and AI-related access patterns as part of your compliance and support model.
• Human-in-the-loop remains required: Copilot can summarize and generate, but business owners must review high-impact outputs.

For deeper guidance on protection controls, labeling, audit, and defense-in-depth architecture, see the full Security guide.

Quick self-check

• Copilot tenant settings reviewed and approvedStart with a pilot if governance maturity is still low.
• Supported capacity confirmedValidate that the target workspaces use supported paid capacity.
• Key semantic models prepared for AIUse AI schema, descriptions, and stable measure definitions.
• AI instructions and verified answers addedFocus on the most common executive and analyst questions first.
• Security and labeling reviewedPermissions, labels, and DLP should be correct before broader rollout.
• Audit and support process definedKnow who monitors usage and who handles issue escalation.

Recommended companion pages in this guide

• Best Practices — Preparing Data for AI
• Security — defense-in-depth and AI protection controls
• Architecture — designing Fabric platforms for scale