How to Build a Power BI AI Agent

Power BI's semantic models carry the definitions that matter: the measures finance signs off on, the relationships that make joins correct, and the row-level security that decides which regional manager sees which region. An agent that queries through those models gives answers consistent with every report built on them. An agent that bypasses them gives answers that start an argument. This guide covers building one that stays inside the model, drawing on FISTA Solutions' AI agents delivery on Microsoft data platforms. It complements how to build a looker ai agent and how to build an ai analyst agent.

What is the governed layer?

The semantic model. It defines measures with their DAX, the relationships between tables, hierarchies, formats, and row-level security roles. Reports are views over it; an agent should be another view over it.

Approach	Consistency with reports	Security	Verdict
DAX against defined measures	Matches	RLS applies with effective identity	Correct
DAX against raw columns	Frequently contradicts	RLS applies but definitions differ	Avoid
Direct query to source warehouse	Contradicts	Bypasses RLS entirely	Never
Export and re-analyse elsewhere	Drifts over time	Lost	Never

How does querying work?

Through the execute queries REST API, which accepts DAX and returns results from a published semantic model without rendering a visual. The agent constructs DAX that evaluates defined measures against dimension filters, such as summarising a revenue measure by region for a date range, and receives a table.

The DAX should reference measures and dimensions from the model, not reconstruct calculations from columns. A measure exists because someone decided how it should be computed; the agent's job is to select and filter it, not to reinvent it.

How is row-level security enforced?

By query identity. When a service principal calls the API, it must supply effective identity information declaring which user the query is for, so the model applies that user's RLS roles. Without it the service principal sees the whole model, which for most organisations means an agent that discloses restricted rows.

User-delegated tokens are the alternative where the agent acts in a user's own session. Either way, the permission test, querying as two users with different roles and confirming results differ correctly, runs before anything goes live and after every model change.

What grounds the agent?

Model metadata. Table, column, and measure names; descriptions; display folders; formats; and relationships, retrievable through the admin and scanner APIs or the XMLA endpoint. Descriptions are where quality is decided: an agent choosing between three revenue measures needs to know that one is net of returns, one is gross, and one is recognised revenue on a different date basis.

Most models have sparse descriptions. Enriching them for the models in scope is the highest-return preparation, and modelling teams typically find it improves the human experience as well.

How are questions translated?

Into DAX over defined measures with explicit filters, chosen using the metadata, with clarification when the question is ambiguous. The agent returns the number, the measure, the filters and date range, and a link to a report page showing the same thing where one exists.

The clarification behaviour matters more than the DAX generation. Which date table, whether to use fiscal or calendar periods, and which of several similar measures applies are questions the agent should ask, because a silently chosen wrong basis produces a confident wrong answer that a busy manager will act on.

How is capacity protected?

By treating the agent as a workload. Execute queries consumes capacity on Fabric and Premium, and an agent issuing unbounded queries in response to every question can degrade report performance for everyone sharing that capacity. Timeouts, row limits, per-question query budgets, and monitoring of duration and count are the controls, and a question requiring a heavy query should be confirmed rather than run silently.

What about Fabric and Copilot?

Microsoft ships conversational and AI capability across Fabric and Power BI, and where it fits the need it should be used rather than rebuilt. A custom agent earns its place where the organisation needs answers delivered inside other tools, combined with data from other systems, evaluated against its own reference questions, or handled with clarification and provenance requirements the platform feature does not meet. The custom agent still queries the semantic model; the difference is in what surrounds the query.

How is it evaluated?

Against real questions with answers verified in a report. Measure selection accuracy, filter correctness, and match with the report figure. Test as users with different RLS roles. Score clarification behaviour on ambiguous questions. Track query cost per question so the evaluation covers efficiency as well as correctness.

What does the build sequence look like?

Two to three weeks enriching measure and column descriptions for the models in scope. One week on API access with effective identity and the permission test. Two weeks on question translation with the BI team testing against their reports. One week on presentation with provenance and report links. Then expansion model by model.

What goes wrong?

Service principals without effective identity. DAX against raw columns. Sparse descriptions. Silent disambiguation. Unbounded queries on shared capacity. Answers without report links. And expansion treated as engineering when it is modelling and description work.

How should composite and DirectQuery models be handled?

With extra attention to cost and latency. Import models answer from memory and are fast; DirectQuery models push each query to the source, so an agent's DAX becomes source-side SQL with the latency and cost of the underlying warehouse. Composite models mix both.

For DirectQuery-backed models, the agent's query budget should be stricter, results should be limited, and the agent should prefer aggregation tables where the model defines them. It should also state the freshness basis: import models are as fresh as their last refresh, DirectQuery models are as fresh as the source, and a user deserves to know which applies to the number in front of them.

How FISTA Solutions helps

FISTA Solutions builds Power BI agents that query semantic models through defined measures with effective identity so row-level security holds, grounded in enriched descriptions, returning provenance and report links with every answer, and running under capacity budgets, through AI enablement, AI agents, and forward deployed engineers working with BI teams. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To make Power BI conversational without contradicting its reports, message FISTA on WhatsApp, or read how to build an ai analyst agent.