Building a Power BI report has, for fifteen years, meant the same thing: open Desktop, drag a field onto the canvas, pick a visual, nudge it, repeat a few hundred times. It's slow, it's manual, and the output is a binary .pbix file you can't diff, review, or generate. So when Microsoft published a walkthrough this month of an agent that builds a full report from a sentence — "create a page with four KPIs for Revenue Won, Pipeline, Lost, and Opportunities" — the interesting question isn't whether the demo is slick. It's why this is suddenly possible at all, when text-to-report has been a graveyard of half-working features for years.
The answer is that two unglamorous format changes turned Power BI reports and models into code — and code is the one thing agents are genuinely good at producing. On top of that substrate sits Skills for Fabric: a plugin for GitHub Copilot CLI that lets an agent plan, design, author, and publish reports, with a clever screenshot loop so it can see what it built. I'll cover the substrate, the skills, the workflow, where the semantic model still decides everything, and the honest limits. (For the engine-level BI background, my Power BI semantic models and VertiPaq internals pieces are the foundation this builds on.)
Why now: PBIR and TMDL made reports code
For an agent to author a report, the report has to be something it can write — a text artifact with a known schema, not an opaque binary. That's exactly what changed. Power BI moved its report and model definitions to open, text-based formats:
- PBIR (the enhanced Power BI report format) stores a report not as one binary blob but as a folder of JSON files — one per page, per visual, with the layout, fields, and formatting all expressed declaratively. A report is now a directory you can read, diff, and generate.
- TMDL (Tabular Model Definition Language) does the same for the semantic model — tables, relationships, measures, and roles as readable text rather than a binary model.
This is the whole unlock, and it's easy to undersell. Once a report is a set of schema-defined JSON files, generating one is a structured-output problem an LLM handles well — the same reason agents are good at writing code and bad at clicking through GUIs. It also means the output is diffable and source-controllable: you can put a report in Git, review a pull request that changes a measure, and see exactly what an agent did. The shift from .pbix to PBIR is what moved report authoring from "automate a mouse" to "generate a file."
The mental model that makes the rest of this click: the report is now code, the agent is the author, and you are the reviewer. Everything below — skills, the MCP server, the screenshot loop — is machinery for generating correct PBIR and TMDL and then proving it looks right. If you've used an agentic coding tool, you already understand the shape of this; Power BI authoring just became another thing a coding agent does.
Skills for Fabric: agent skills over Copilot CLI
Skills for Fabric is a first-party catalog of agent skills — reusable instruction sets that teach GitHub Copilot CLI how to work with Microsoft Fabric. A skill isn't a model; it's curated guidance (conventions, schemas, best practices, the right API calls) that an agent loads to perform a class of task correctly. You install them as a plugin and then talk to Copilot CLI in plain language:
# Add the catalog and install the Power BI authoring plugin
/plugin marketplace add microsoft/skills-for-fabric
/plugin install powerbi-authoring@fabric-collection
# Authenticate to Fabric, then just describe what you want
az loginThe powerbi-authoring plugin bundles a handful of skills, each targeting a phase of the report lifecycle. They map cleanly onto how a competent BI developer actually works:
| Skill | What it does |
|---|---|
powerbi-report-planning | Requirements gathering and strategy — what the report needs to answer before anything is drawn |
powerbi-report-design | Produces a structured design debrief, applying report-design best practices (layout, hierarchy, accessibility) |
powerbi-report-authoring | The core: generates schema-correct PBIR from natural language |
semantic-model-authoring | Creates and edits the underlying semantic model (TMDL) |
powerbi-report-management | Organization, sharing, and lifecycle operations |
check-updates | Keeps the skill definitions current |
The split matters more than it looks. A common failure of "AI report generators" is jumping straight to pixels — a pretty page that answers the wrong question. Separating planning and design from authoring forces the agent to decide what the report is for and how it should be structured before it emits a single visual, which is exactly the discipline that separates a useful dashboard from a decorated one.
The authoring loop: how a report actually gets built
Here's where it goes from "LLM writes JSON" to something that actually works. Generating PBIR blind would produce plausible-but-wrong layouts — overlapping visuals, mis-scaled axes, KPIs that don't render. The capability closes that gap with a Desktop bridge: a local component that captures screenshots of the report in Power BI Desktop and auto-reloads it as files change, without a restart. The agent writes PBIR, the bridge shows it what rendered, and it refines — the same see-then-fix loop a person runs, but automated.
graph TD
NL["Natural-language prompt
'a page with 4 revenue KPIs'"]
PLAN["Planning + design skills
requirements & design debrief"]
AUTHOR["Authoring skill
generates PBIR (JSON files)"]
MODEL["Semantic model (TMDL)
via Modeling MCP server"]
BRIDGE["Desktop bridge
screenshot + auto-reload"]
SEE{"Looks right?"}
PUBLISH["Publish to Fabric"]
NL --> PLAN --> AUTHOR
MODEL -.->|"measures, fields"| AUTHOR
AUTHOR --> BRIDGE --> SEE
SEE -->|"no — refine PBIR"| AUTHOR
SEE -->|"yes"| PUBLISH
The design-to-deployment loop. Planning and design skills decide what the report is for; the authoring skill emits PBIR against the semantic model; the Desktop bridge screenshots the rendered result and feeds it back so the agent can refine. Only once it looks right does it publish to Fabric. The screenshot feedback is what turns blind generation into something that converges.
A schematic PBIR fragment makes the "it's just files" point concrete — this is the kind of declarative definition the authoring skill produces and the bridge renders:
// definition/pages/opportunities/visuals/kpi-revenue-won/visual.json
{
"name": "kpi-revenue-won",
"visualType": "card",
"position": { "x": 0, "y": 0, "width": 280, "height": 140 },
"query": {
"fields": [
{ "measure": { "table": "Sales", "name": "Revenue Won" } }
]
},
"format": { "title": { "text": "Revenue Won" } }
}The Modeling MCP server
Reports don't exist without a model, and the agent authors that too. A Modeling MCP server gives the agent live access to create and modify the semantic model — adding tables, relationships, and measures — through the Model Context Protocol. This is the pattern I keep seeing across the agent tooling world: skills supply the knowledge (how Power BI authoring works), and an MCP server supplies the live hands (actually mutating the model via its API). The same standard interface that lets an agent drive a database or a filesystem now lets it drive a semantic model.
Where this fits: Copilot, and the wider Fabric skills
It's worth being precise about how this differs from the Copilot you already have in Power BI. Copilot in Power BI (in the Service and in Desktop) is an in-product assistant — it writes narratives, suggests measures, and can draft a report page from inside the app. The agent-CLI approach is a different shape: it lives in your editor and terminal, treats the report as files in a repo, and runs the iterative author-screenshot-refine loop from outside the app. One is a helper inside the GUI; the other makes the report part of a code workflow with version control and review.
And report authoring is just one plugin. The broader Skills for Fabric catalog covers the rest of the platform — fabric-authoring (REST APIs, notebooks, T-SQL, KQL, Dataflows Gen2, semantic models), fabric-consumption (read-only exploration across warehouses, lakehouses, and the catalog), and fabric-operations (performance diagnostics, slow-query investigation). The direction is clear: the same agent that builds your medallion pipeline can build the report on top of it, because both are now code-shaped tasks behind a skill.
The semantic model is still 80% of the job — and an agent will happily build a beautiful report on a broken one. This is the trap I'd warn every team about. If your measures are wrong, your relationships fan out, or your model has no clear grain, an authoring agent doesn't fix that — it renders the wrong numbers faster and more confidently, wrapped in a polished layout that looks authoritative. I've made this point about semantic views feeding Cortex agents and it's identical here: the AI is only as good as the model underneath it. Generated report polish is not a substitute for a correct, governed semantic model — review the measures and the TMDL diff, not just the screenshot.
What it changes, and what it doesn't
What genuinely changes: the grunt work of report construction collapses. Standing up a first draft, modernizing a legacy report to current design standards, replicating a layout across regions, keeping a report in source control with reviewable diffs — these go from hours of clicking to a prompt and a review. For a consultancy that builds dozens of similar reports, that's real leverage, and the git-native workflow finally brings BI artifacts into the same review discipline as everything else.
What doesn't change: someone still has to know what a good report is, whether the numbers are right, and whether the model is sound. The agent is a fast, tireless author working from your design principles and your model — it is not a replacement for the judgment that decides which four KPIs belong on the page, or for the governance that says this measure is the blessed definition of revenue. As of mid-2026 this is early and evolving (preview-grade, fast-moving), so treat it as a powerful draft-and-iterate tool with a human reviewing the diff, not an autopilot.
Frequently asked questions
Why can AI author Power BI reports now when text-to-report failed before?
Because the report format changed. Power BI's PBIR format stores a report as a folder of schema-defined JSON files instead of a binary .pbix, and TMDL stores the semantic model as text. Generating a structured file is something an LLM does well, whereas automating clicks in a GUI never worked reliably — so the move to code-shaped artifacts is what made agent authoring practical.
What is the Desktop bridge and why does it matter?
The Desktop bridge is a local component that captures screenshots of the report in Power BI Desktop and auto-reloads it as the files change. It lets the authoring agent see what its generated PBIR actually rendered and refine it — turning blind file generation into a see-then-fix loop that converges on a correct layout.
Does an authoring agent replace a good semantic model?
No. The agent authors reports (and can edit the model via the Modeling MCP server), but it does not make a bad model correct. If measures or relationships are wrong, the agent renders the wrong numbers in a polished layout. The semantic model remains the foundation, and the TMDL and measures still need human review.
What to carry away
AI-powered Power BI reporting works now for one structural reason: PBIR and TMDL turned reports and models into code, and generating code is what agents are good at. Skills for Fabric supplies the agent the know-how — planning, design, authoring, semantic-model skills — over GitHub Copilot CLI; a Modeling MCP server gives it live hands on the model; and a Desktop bridge closes the loop by letting it see and refine what it rendered before publishing to Fabric.
Adopt it as what it is: a draft-and-iterate author that collapses the manual construction of reports and brings them into a git-native, reviewable workflow. Keep your attention where it always belonged — on a correct, governed semantic model and on whether the report answers the right question. The agent makes building fast; it doesn't make being right automatic. For the substrate beneath all of it, start with Power BI semantic models, and for the protocol powering the live model access, the MCP deep-dive.