Power BI Reports Are Becoming Agent-Editable: What Fabric Skills Change for BI Teams

The distinction that matters: two different layers of Power BI, addressed by two different pieces of Microsoft tooling. This article is about the top half.

The request lands on a Tuesday:

You know the drill. New page. Drag a card, bind a measure, resize. Repeat three times. Add the bar chart, pick the field, sort it, fix the data labels. Trend chart. Table, choose columns, set the top N. Move the slicer. Apply the theme and discover two visuals didn't inherit it. Align everything. Look at it. Adjust.

None of that is hard. All of it is time. And if the same request arrives for eleven other reports, it's the same afternoon, eleven more times.

What happens when an AI agent can modify not just the data behind Power BI, but the report layer your users actually see?

That's what Microsoft's Power BI Report Authoring skill does. It's in preview, it ships in Microsoft's first-party Skills for Fabric catalogue, and it changes report development from an entirely manual craft into something closer to a reviewed engineering workflow.

Two Layers, Two Technologies

If you take one thing from this article, take this. Power BI development happens on two distinct layers, and they now have two distinct agentic technologies.

We covered the model side separately, in how AI agents are changing Power BI modelling. That's the Modeling MCP server: tables, columns, measures, relationships, DAX. This article is about everything above it — the pages and visuals people look at.

Most real business requests cross both lines. "Show gross margin by region on the executive page" means creating a measure and building the visual. Microsoft designed these to be used together: the skill's own documentation tells the agent to route model-side work to the modelling tooling and keep itself to report file mechanics.

What "Report Authoring" Actually Means

Plainly: changing what the user sees and interacts with. In practice, the skill covers

• creating and renaming pages, and setting page size, type and page-level filters;
• adding visuals, choosing the visual type, and binding fields and measures to the right roles;
• filters and slicers, at report, page and visual level;
• formatting — the properties you'd otherwise set one pane at a time;
• themes, including registering a theme and its colours, text classes and visual styles;
• layout: position and size of every visual on the canvas;
• bookmarks and navigation;
• validating the result and checking how it renders.

Microsoft's own example use cases are revealing about where this pays: re-theming an existing report with a full dark theme, converting legacy card and matrix visuals to their modern equivalents and reapplying formatting, and diagnosing a visual that renders as an error icon by fixing its underlying bindings. These are jobs that are tedious rather than difficult, and they're exactly the jobs that don't get done.

Skills, Tools, and What "Fabric Skills" Are

Microsoft's framing is unusually clear, so it's worth quoting: "Skills tell the agent what to do. Tools let the agent do it."

• Skills are folders of instructions, scripts and reference material that an agent loads on demand. They encode how to do something properly.
• Tools are the MCP servers and CLIs that actually inspect schemas, edit files, validate reports and drive Power BI Desktop.

Skills for Fabric is Microsoft's first-party catalogue of these skills. The powerbi-authoring plugin bundles the report authoring, design, planner and management skills, and registers the Power BI Modeling MCP server automatically. Microsoft describes it as a curated bundle you install into your agent, not a Power BI feature you switch on.

There's a technical point buried in this that explains why the skill exists at all. PBIR is JSON, and a capable language model will happily invent plausible-looking JSON. The skill explicitly forbids that: it instructs the agent not to guess PBIR structure from memory, and to look up visual types, data roles, formatting objects, property names and enum values through a dedicated CLI that acts as the source of truth. That's the difference between an agent that writes JSON which looks right and one that writes JSON Power BI accepts.

It's optimised for GitHub Copilot CLI, with compatibility for VS Code Copilot, Claude Code, Cursor, Codex/Jules and Windsurf. The capabilities are the same; the polish varies by client.

Why It Needs PBIP and PBIR

This is the practical catch, and it's worth being precise because it's the single most common misunderstanding.

Microsoft's documentation states it directly: the skill works only with PBIP files. You cannot point it at a .pbix.

The reason is structural. A PBIX is a packaged file — convenient for humans, opaque to tools. A PBIP project stores the same work as folders of files, and within it the PBIR format breaks the report into individual definitions: one file per page, one per visual, plus report-level settings and themes.

Sales.Report/
├── definition.pbir            which semantic model this report uses
└── definition/
    ├── report.json            themes, settings, resources
    └── pages/
        ├── pages.json         page order and active page
        └── [pageId]/
            ├── page.json      name, size, page filters
            └── visuals/
                └── [visualId]/
                    └── visual.json   type, position, query, formatting

The PBIR layout the skill works with. Every page and every visual is an addressable file — which is precisely what makes agent editing possible.

That structure is what makes "add a KPI card to page two" a file operation rather than a mouse operation. It's also why the PBIP and PBIR formats suddenly matter more than they did when they were pitched as a source-control feature. They weren't built for AI — but a project of readable, addressable definitions turns out to be exactly what an agent needs.

Does this mean PBIX is finished? No. Microsoft has been explicit elsewhere that PBIX remains the primary file format for Power BI developers. What's true is narrower: this particular workflow requires PBIP. If you want agent-assisted report authoring, that's the entry ticket, and Power BI Desktop can save an existing report as a project.

The Edit → Validate → Verify Loop

An agent editing JSON it can't see the results of would be a bad idea. The workflow closes that gap.

The agent doesn't declare success until validation passes and the rendered page has been looked at. Microsoft's guidance is explicit on that point.

Two pieces make this work. A validation command checks the PBIR against its schema and structure, catching invalid visual types, wrong role names and malformed formatting before they reach Desktop. Then the Power BI Desktop Bridge — a local server inside the Desktop process, also in preview — lets the agent reload the file and capture a PNG of any page. The agent can literally look at the result.

It also knows when not to act: the bridge reports whether Desktop has unsaved changes, and the guidance is to stop and ask you to save rather than reload over your work.

Example: Building That Executive Page

Back to Tuesday's request. Here's the same work, two ways.

The agent's sequence is worth spelling out, because it's not one big leap. It reads the semantic model to find the right measures, follows the skill's instructions for PBIR mechanics, looks up the exact visual types and formatting properties rather than guessing them, writes the page and visual files, runs validation, reloads Desktop, captures the page, and only then reports what it did.

Example: Changing a Report That Already Exists

Creating new pages is the easy story. The more valuable one is modification.

Four changes, four different kinds of edit: a position change, a visual type change, a new field binding, and a formatting sweep. A chatbot answers this with instructions — "select the visual, open the Format pane, then…". An agent with this skill edits the underlying definitions, validates them, reloads your Desktop and shows you the page.

"Make the KPI cards consistent" is the interesting one. It's a request that's trivial to state, tedious to perform, and easy to get subtly wrong by hand across eight cards. It's also the kind of change that never makes it up the priority list, which is why so many reports drift into inconsistency.

The Companion Skills: Design and Planning

Report authoring handles the mechanics. Two companion skills handle everything before that.

The Report Design skill decides what a report should look like and why: page archetypes, chart selection, colour, typography, layout and accessibility, plus anti-pattern detection. It doesn't write files. It produces a structured design brief, which Microsoft describes as the contract between the two skills — the brief says what to build, and the authoring skill works out the pixel coordinates and PBIR encoding. Notably, it's built to stop and offer options when a request is vague, rather than guess.

The Report Planner skill wraps the whole thing in a guided workflow: define → inspect → brief → approve. It gathers requirements, inventories the semantic model, produces a locked brief and plan, and builds nothing until you explicitly approve. There's a fourth skill for publishing report items to Fabric workspaces.

Before and After

None of which means every task is autonomous. It means the repetitive middle of report development can be delegated, and the judgement stays with you.

What It's Actually Worth

Why Human Review Still Matters

Validation proves a report is structurally valid. It does not prove the report is any good.

A page can pass every check and still be wrong: a chart type that obscures the pattern, a layout that buries the number people came for, labels that make sense to the person who built it and nobody else, colour that fails on a projector, a visual so dense it's decorative. And underneath all of that, the question no validator can answer — did the agent interpret the business request the way the business meant it?

This is why the screenshot step exists, and why it isn't sufficient on its own. The agent can confirm something rendered. Whether it communicates is your call, and it stays your call.

Limitations Worth Knowing

• Everything here is in preview. The skills, the Desktop Bridge, and the surrounding tooling. Behaviour and APIs may change.
• PBIP only. No PBIP project, no agent authoring. And reports still in the older PBIR-Legacy format aren't supported by these skills.
• PBIR is the source of truth. If you have unsaved changes open in Power BI Desktop and ask the agent to iterate, it works from the files on disk and your unsaved work isn't included. Save first.
• Some visuals are on the way out. Microsoft flags Q&A, Bing maps and filled maps as deprecating soon, and advises against having an agent create them.
• Client experience varies. It's optimised for GitHub Copilot CLI, with compatibility shims for other agents.
• The Desktop Bridge is local and single-threaded. It talks to Power BI Desktop on your own machine, one operation at a time, and isn't a remote automation service.
• Publishing is deliberate. Edits stay local until you explicitly ask for them to go to a Fabric workspace, and entity names have to match the target model.
• Validation is not correctness. Schema-valid, rendered, and right are three different things.

Governance, Briefly

None of this ships with governance attached. That part is yours to design, and the questions are familiar ones:

• Commit a baseline first. Microsoft's own advice: put the report in source control before you let an agent modify it, so you can revert.
• Decide who can point an agent at what. A development copy is not a production workspace.
• Keep review in the path. The same pull request discipline you'd apply to code applies here, and now it's possible because reports are files.
• Remember report definitions carry content. Filter values, field names and themes can be commercially revealing; consider what your AI provider sees.
• Control the publish step separately from the authoring step.

FAQ

Can the Report Authoring skill edit a .pbix file?

No. Microsoft's documentation states the skill works only with PBIP files. It edits the PBIR report definition inside a Power BI Project. A packaged .pbix has to be saved as a PBIP first, in Power BI Desktop.

How is this different from the Power BI Modeling MCP server?

They work on different layers. The Modeling MCP server changes the semantic model: tables, columns, measures, relationships and DAX. The Report Authoring skill changes the report layer: pages, visuals, filters, slicers, formatting and themes. Most real requests touch both, and they're designed to be used together.

What is the difference between a skill and a tool?

Microsoft puts it simply: skills tell the agent what to do, and tools let the agent do it. Skills are folders of instructions an agent loads on demand; tools are MCP servers and CLIs that inspect schemas, edit files, validate reports and drive Power BI Desktop.

Does the agent check that the report actually looks right?

Partly. The workflow validates the PBIR files, reloads Power BI Desktop through the Desktop Bridge and captures screenshots of the pages. That catches structural errors and broken visuals, but whether a page communicates the right business message is still a human judgement.

Is it safe to point an agent at our production reports?

Treat it as a development capability, not an unattended process. Microsoft recommends committing a baseline to source control before letting an agent modify PBIR files. Everything stays local until you explicitly approve publishing, and all of these skills are in preview.

Not sure whether your reports are in a state an agent could work with? We can review a representative report and tell you.

The Change Underneath

For most of Power BI's life, the development cycle has been click, configure, repeat. Every page built by hand, every visual bound by hand, every format set in a pane.

What's emerging is different: describe, generate, validate, review. The report becomes something an agent can inspect, author, modify and check — with a human deciding whether the result is right.

That's a bigger claim than "AI can make charts", and a smaller one than "AI builds your reports now". The mechanics can be delegated. The judgement — what to show, to whom, in what form, and whether it tells the truth — hasn't moved anywhere. Which means the teams that benefit are the ones whose models are clean, whose standards are written down, and whose review processes already work. The tooling amplifies what's there; it doesn't supply it.

Fabric Skills, the Power BI Report Authoring skill and the Power BI Desktop Bridge are all in preview and changing quickly. Check Microsoft's documentation and the Skills for Fabric repository for current capabilities and limitations before relying on any specific detail here.

Sources & Further Reading

1. Power BI Report Authoring skill, Microsoft Learn
2. Power BI Agentic overview (skills and tools), Microsoft Learn
3. Power BI Report Design skill, Microsoft Learn
4. Power BI Report Planner and Management skills, Microsoft Learn
5. What is the Power BI Desktop Bridge?, Microsoft Learn
6. Skills for Fabric marketplace, Microsoft on GitHub
7. The powerbi-authoring plugin and its skills, Microsoft on GitHub
8. Power BI Desktop project report folder (PBIR format), Microsoft Learn