When you first roll out the Fabric data agent, it usually feels like a big win. Suddenly, business users do not need to depend on SQL or data teams for every question. They just type what they want in plain English and get answers. Adoption tends to happen quickly, almost organically. Sales teams start exploring trends, operations teams dig into performance, and leadership begins asking more frequent, data-backed questions.
For a while, everything looks great.
Then you open the Fabric Capacity Metrics app and notice that usage has increased quite a bit. Not gradually, but in noticeable spikes. That is when the conversation shifts from capability to cost. You start asking a more practical question: what exactly is driving this usage?
To understand that, it helps to look at what actually happens when someone types a question into the data agent.
Each question asked triggers several steps:
- The natural language prompt is processed.
- A query (usually SQL) is generated.
- The query is executed.
- A response is generated and returned.
Every step consumes tokens. tokens are the unit of measurement here, a straightforward way to understand this is:
- Approximately 750 words equate to about 1,000 tokens.
- Both input (what you send) and output (what you receive) are counted.
Thus, even a simple question involves a chain of activities, each using tokens. So even if a query looks small on the surface, the actual processing footprint can be larger than expected.
What tends to catch teams off guard is not a single query, but the pattern of usage. Users naturally write longer prompts when they are unsure, adding more context than necessary. The system, in turn, often responds with detailed explanations, summaries, and recommendations. That increases both input and output tokens. On top of that, every generated query still needs to run on your data platform, which means compute is being consumed separately. So the cost is not just about AI usage. It is a combination of token processing and query execution.
Verbose prompts add up quickly: Users often write lengthy, descriptive queries. The more context included, the more input tokens are consumed.
Detailed responses increase output tokens: When the system provides explanations, breakdowns, and recommendations, output tokens rise sharply.
Query execution is a separate cost: Once the agent generates a query, it is run on your data platform, consuming compute capacity.
Therefore, your overall cost comprises both AI related and compute factors:
Tokens (input + output) + compute (query execution)
Over time, another pattern becomes visible. The same questions get asked repeatedly, sometimes worded slightly differently. This usually happens during review meetings or reporting cycles. The intent is the same, but each variation still triggers a full cycle of processing. That is where usage starts compounding quietly in the background.
The way to manage this is not by restricting access or discouraging usage. That approach rarely works and usually reduces the value of the platform. Instead, it comes down to shaping how the system is used. Small changes make a noticeable difference. For example, guiding users with simple, consistent ways of asking questions helps reduce unnecessary verbosity. Keeping responses concise unless more detail is explicitly needed also brings down token usage. And for frequently asked questions, optimising the underlying data model or query paths can reduce both processing effort and execution cost.
Another aspect that is easy to overlook is visibility. Without actively monitoring usage, it is difficult to know where the cost is coming from. The Fabric Capacity Metrics app becomes important here, not just as a reporting tool but as a way to understand behaviour. You start to see when usage peaks, how background AI workloads are impacting capacity, and which patterns are driving consumption.
Not every response requires detailed explanations. Concise answers by default help lower output token usage.
Handle repeated questions smartly: For frequently asked questions:
- Optimise the underlying model or views.
- Simplify query generation paths.
This approach reduces both token and compute costs.
Monitor, do not guess: The Fabric Capacity Metrics app is vital. Track:
- When usage spikes
- Trends in token consumption over time
- Impact of background jobs on capacity
Without monitoring, you are effectively operating blind.
There is also a subtle detail around billing that can have an impact. Costs are tied to the billing region, not necessarily where the workload is executed. In multi-region setups, this can influence the overall spend more than expected if it is not accounted for early.
What this all points to is a shift in how data platforms are consumed. With the data agent, cost is no longer driven purely by system design or query complexity. It is influenced by how people interact with the system on a day-to-day basis. The way questions are framed, how often they are asked, and how detailed the responses are all play a role.
The data agent itself is not inherently expensive. In fact, it can deliver significant value when used well. But without some level of guidance and visibility, usage can scale in ways that are not immediately obvious.
So the real change is this, you are not just managing data workloads anymore. You are managing interaction patterns. And that is where cost optimisation now sits.