A single dashboard—even packed with dynamic visuals and DAX—cannot respond to a user’s intent the way an agent can. With the introduction of Agent Skills in Microsoft Fabric, the analytics stack is not just surfacing data: it’s becoming responsive and interactive, folding routine tasks and guided analysis into reusable, composable components. By the end of this article, you’ll know where agentic analytics upends existing Power BI design patterns, what ‘Agent Skills’ mean for modelers, and why the trade-offs are not as simple as “add AI and go.”
Agent Skills Are Not Just ‘Copilot for Reports’
The naive assumption is that Agent Skills are another Copilot overlay—an AI chat that generates visuals on demand. This misses the main shift: Skills are discrete, composable actions that agents can perform on data models, pipelines, and user prompts. They are not report templates or DAX snippets, but functional building blocks that agents chain together to execute user requests in context. The distinction matters: Skills can be reused, permissioned, and versioned independently of any single report or workspace.
Take a constructed scenario: you have a Fabric Lakehouse, a semantic model with [Total Sales], and a set of recurring ad-hoc support requests—“show me sales by product in the last quarter,” “export these results to Excel,” “flag anomalies for Electronics.” Today, these are handled via a mix of dashboards, direct queries, and janky Power Automate flows. With Agent Skills, you model each as an explicit skill: a parameterizable DAX query, a data export routine, or an anomaly detection operation. The agent orchestrates them, chaining skills based on user dialog, context, and policy.
The gotcha: Skills are only as effective as the contract between agent and model. If you expose a skill that expects a contiguous date table but your data breaks in February, the agent cannot paper over the flaw. Skill design surfaces all the hidden assumptions that modelers could previously bury inside a manual report.
Designing for Agentic Analytics Breaks the Old “Report-Centric” Model
Most Power BI models are optimized for dashboard use: heavy on pre-aggregated measures, slicer-driven filters, and visuals tuned for the most common questions. Agentic analytics requires a shift in both data modeling and governance:
- Parameterization is non-negotiable. Skills must accept parameters (e.g., date ranges, product categories) and validate them, or the agent cannot chain them safely. Hardcoded filters—a common DAX shortcut—become brittle and agent-hostile.
- Security and RLS get more complicated. When an agent calls a skill, it executes in the user’s context. If your RLS rules depend on USERNAME() instead of USERPRINCIPALNAME(), or you have ambiguous bidirectional filtering, the agent may leak or block data in ways that never arose in classic report UX.
- Skills must declare dependencies and side effects. An export skill that triggers a Dataflow refresh or an anomaly detection skill that writes back results to a lake table must surface this in its manifest. The agent does not guess at intent—it orchestrates declared actions.
Where this bites: say you build a skill that generates a time intelligence report using TOTALYTD. If your Date table is not marked, or has gaps, the agent’s output will be wrong—but now, instead of a report designer catching the error, a user gets a misleading answer from an agent. Skill validation must be explicit, not assumed.
Worked Example: Building and Exposing a Skill (and the Hidden Failure)
Take a model with Fact_Sales (~20M rows), Dim_Product, and Dim_Date. You want the agent to answer: “What were the top 5 products by sales last month?” The naive approach is to wrap a DAX measure and call it a day:
// Naive Skill: hardcoded date filter, no parameterization
TopProductsLastMonth =
VAR LastMonth = EOMONTH(TODAY(), -1)
VAR StartOfMonth = DATE(YEAR(LastMonth), MONTH(LastMonth), 1)
VAR EndOfMonth = EOMONTH(StartOfMonth, 0)
RETURN
CALCULATETABLE(
TOPN(
5,
SUMMARIZE(
Fact_Sales,
Dim_Product[ProductName],
"TotalSales", [Total Sales]
),
[Total Sales], DESC
),
Dim_Date[Date] >= StartOfMonth,
Dim_Date[Date] <= EndOfMonth
)
This works in a static report, but as a skill, it cannot accept user-supplied months, localization, or fiscal calendars—nor can it signal when the date range is missing from the data. Worse, if the user’s RLS context only exposes certain products, the TOPN may produce fewer than five results, and the agent can’t explain why.
The agentic version must explicitly parameterize and validate:
// Agentic Skill: parameterized, RLS-aware, with validation
TopProductsByPeriod =
VAR StartDate = SELECTEDVALUE('SkillParameters'[StartDate])
VAR EndDate = SELECTEDVALUE('SkillParameters'[EndDate])
VAR CheckDates =
IF(
ISBLANK(StartDate) || ISBLANK(EndDate),
ERROR("Date parameters required."),
1
)
VAR ProductsTable =
SUMMARIZE(
FILTER(
Fact_Sales,
Fact_Sales[Date] >= StartDate && Fact_Sales[Date] <= EndDate
),
Dim_Product[ProductName],
"TotalSales", [Total Sales]
)
RETURN
IF(
CheckDates = 1,
TOPN(5, ProductsTable, [Total Sales], DESC),
BLANK()
)
Now, the skill can be chained by an agent with explicit parameters, and will error out—rather than silently fail—if context is missing. This pattern generalizes: agentic analytics demands that every skill surfaces its requirements, handles blanks, and aligns with RLS.
Agents Break the Illusion of Modeler Control
With classic reports, you can paper over model flaws—misnamed columns, missing relationships, half-baked calendars—by hiding them from visuals or using helper measures. Agents surface everything: they call skills, enumerate model objects, and may even generate DAX on the fly. If your model is ambiguous, your skills brittle, or your entity naming inconsistent, the agent will expose it to the user immediately.
For example, imagine an agent skill that invokes anomaly detection on sales by region. If your Fact_Sales table uses [RegionCode] and your Dim_Region table uses [RegionID], but the relationship is inactive, the agent may fail to join or apply the skill unless you explicitly use USERELATIONSHIP in your DAX—or, better, clean up the model. The agent cannot guess your intent or repair logic on the fly; it works only with what is declared and connected. This is not a Copilot issue: it’s a model governance problem laid bare by agents.
What Agent Skills Mean for Performance, Security, and Governance
There’s a real trade-off: agentic analytics is not free. Every agent call, skill execution, and data exchange adds latency, security risk, and governance burden:
- Performance: Skills that call DirectQuery sources or chain multiple DAX queries can trigger multiple roundtrips and bypass the VertiPaq cache. An agent chaining three skills—say, filter, aggregate, export—will not “merge” queries unless explicitly modeled that way.
- Security: Skills run in the user’s security context, but if a skill calls out to a Dataflow or external API, you must ensure that data never leaks across RLS boundaries. USERPRINCIPALNAME() is mandatory; USERNAME() is not reliable in the Service.
- Governance: Each skill is a governed object, with its own permissions, versioning, and audit trail. This adds a layer of lifecycle management that most Power BI teams have never had to do for DAX or M code. Expect to formalize skill deployment, review, and retirement policies.
This is not the same as old-school report governance. Skills are code, packaged and versioned, and require the same discipline as APIs: contract-first, with explicit error handling and permissioning. The agent does not “fix” bad code—it executes what it’s given.
For more on this shift, see the original Microsoft announcement.
Actionable Takeaways
- Review your semantic models for hidden assumptions—especially around dates, relationships, and RLS. Agents will expose weak spots immediately.
- Design skills as parameterized, contract-first components. Hardcoded logic or undocumented dependencies will break agent orchestration.
- Treat skills as governed code assets—versioned, permissioned, and auditable—not just “DAX helpers.”
- Expect to invest in validation, monitoring, and lifecycle management for skills. The cost is up front, but the payoff is a model that can be reliably automated and composed by agents.
The era of dashboards as the sole analytic surface is ending. Building for agents means exposing, not hiding, your model’s logic—and that demands a new standard of modeling discipline.