How to Estimate Microsoft Fabric Capacity for Data Agent Usage

Data Agent capacity planning starts with a different question

Most Microsoft Fabric capacity conversations begin with familiar workload inputs. How many pipelines run each day? How long do Spark jobs stay active? How many warehouse queries overlap at month-end? What is the refresh window for the semantic model?

Those questions still matter when a Fabric Data Agent enters the architecture. They are just no longer enough.

A data engineering workload usually has a schedule, a duration, and a measurable compute profile. A Data Agent is driven by people asking natural-language questions. Each question carries a variable amount of context, produces a variable-length answer, and can generate a SQL, DAX, or KQL query whose cost depends on the source it reaches.

That changes the unit of estimation. You cannot scope Data Agent usage from user count alone, and you cannot treat one question as one fixed capacity charge.

The useful model is:

Data Agent demand = AI processing + generated query execution + existing Fabric demand

Keeping those three layers separate is the difference between a capacity estimate and a guess.

One question can produce two capacity signals

When someone asks a Fabric Data Agent a question, Fabric constructs a prompt from more than the sentence the user typed. The input can include schema information, Data Agent instructions, data source instructions, example queries, and conversation history. The agent then selects a source, generates and validates a query, executes it, and formats the result.

Microsoft reports the language-model portion in the Fabric Capacity Metrics app as AI Query under the LlmPlugin item kind. At the time of writing, the published consumption rates are:

AI Query component	Consumption rate
Uncached input prompt	100 CU seconds per 1,000 tokens
Cached input prompt	10 CU seconds per 1,000 tokens
Output completion	400 CU seconds per 1,000 tokens

Fabric applies prompt caching automatically when requests reuse a recent prefix, such as system instructions, schema context, or conversation history. Output tokens are more expensive than uncached input tokens, and forty times the rate of cached input tokens. That makes verbose responses a real sizing variable.

The AI portion of one request can be estimated as:

AI CU-seconds per request =
    (uncached input tokens / 1,000 × 100)
  + (cached input tokens / 1,000 × 10)
  + (output tokens / 1,000 × 400)

But this is only the first signal.

If the agent generates and executes SQL, DAX, or KQL, that execution is billed separately to the corresponding query engine item. A warehouse question can therefore appear as both an AI Query operation for the agent and a Warehouse Query operation for the generated T-SQL. A semantic-model question can add an Interactive query operation. A KQL question adds its own Eventhouse query consumption.

Do not estimate the agent and forget the engine underneath it.

Why a request count is not enough

Suppose two users each ask ten questions.

The first user asks short, independent questions against a focused semantic model and receives concise answers. The second has a long conversation, asks ambiguous questions across several sources, and requests detailed explanations. The request count is identical. The capacity profile is not.

Five variables change Data Agent consumption materially:

1. Questions per active user. Licensed users are not active users, and active users do not all ask questions at the same rate.
2. Prompt context. Instructions, selected schema, examples, and conversation history contribute tokens even when the visible question is short.
3. Output length. Detailed narrative answers consume more than concise answers.
4. Question mix. A lookup, a grouped comparison, and a multi-step analytical question should not share one average.
5. Generated query cost. The same natural-language question can produce very different engine consumption depending on model design, data volume, filters, DAX measures, SQL shape, and KQL time range.

This is why early estimates should use scenarios rather than one universal “CU per question” assumption.

Build a three-scenario request model

Start with three request classes: simple, standard, and complex. Use measured token and query-engine values when you have them. Before a pilot, use explicit planning assumptions and label them as assumptions.

Here is an illustrative worksheet. The query-engine numbers are examples, not Microsoft-published rates.

Scenario	Uncached input	Cached input	Output	AI CU-s	Measured query CU-s	Total CU-s
Simple	1,500	500	300	275	30	305
Standard	2,500	1,500	600	505	90	595
Complex	5,000	3,000	1,200	1,010	300	1,310

The first row, for example, is calculated as:

(1,500 / 1,000 × 100)
+ (500 / 1,000 × 10)
+ (300 / 1,000 × 400)
= 275 AI CU-seconds

Add the measured query execution of 30 CU-seconds and the request total becomes 305 CU-seconds.

Now estimate monthly request volume:

Monthly requests =
  active users
  × questions per active user per working day
  × working days per month

If 500 active users ask six questions per working day across 22 working days, the estimate is 66,000 requests per month.

Assume the request mix is 50% simple, 35% standard, and 15% complex:

Weighted CU-seconds per request =
  (305 × 50%) + (595 × 35%) + (1,310 × 15%)
= 557.25 CU-seconds

Monthly Data Agent CU-hours =
  66,000 × 557.25 / 3,600
= 10,215 CU-hours

That is the combined agent and generated-query estimate for this example. It is not yet the SKU recommendation.

Translate consumption into capacity headroom

An F SKU provides its stated number of CUs continuously. An F64, for example, provides 64 CUs. Across a 24-hour day, that is 1,536 CU-hours of capacity budget.

Fabric classifies the Data Agent’s AI activity as a background operation and smooths background consumption over 24 hours. That helps absorb bursts, but it does not create free compute. Sustained usage still draws down the same capacity budget, and generated source queries retain the operating characteristics of their own engines.

To translate the monthly model into a planning signal:

Average incremental CUs =
  monthly Data Agent CU-hours / active capacity hours in the month

For a capacity running continuously over a 30-day month:

10,215 CU-hours / 720 hours = 14.2 average CUs

Do not conclude that an F16 is sufficient. The 14.2 CUs must fit alongside the current platform baseline, peak query concurrency, refreshes, pipeline windows, and acceptable headroom. It also represents an average produced from assumptions. Real adoption can cluster around Monday mornings, executive meetings, quarter-end reviews, and incidents.

A more useful decision test is:

Required capacity envelope =
  existing smoothed baseline
  + incremental AI Query demand
  + incremental source-engine demand
  + operating headroom

Run the calculation for an expected case and a high-adoption case. Capacity planning is stronger when it shows a range and its assumptions than when it presents one precise-looking SKU.

How this differs from scoping Fabric data engineering

The difference is not that Data Agents use a completely separate platform. The difference is what drives demand and how confidently it can be predicted before deployment.

Sizing dimension	Data engineering workloads	Fabric Data Agent workloads
Primary driver	Data volume, runtime, schedule, throughput	Active users, questions, context, answer length
Work pattern	Planned and repeatable	Adoption-driven and conversational
Useful preproduction input	Job duration, nodes, activity runs, refresh windows	Request mix, token distributions, source routing
Secondary compute	Downstream activities in an orchestrated flow	Generated SQL, DAX, KQL, or Graph access
Peak concern	Concurrent jobs and processing windows	Bursty adoption plus source-query concurrency
Optimization lever	Partitioning, parallelism, job scheduling, pool size	Focused schema, concise instructions, answer length, source design
Best validation	Representative job runs	Representative questions and conversations

For Spark, you can often begin with node size, vCores, node count, and active duration. For pipelines, you can count activity executions and data movement. For Eventstream, uptime and traffic matter. For a warehouse, representative query behavior and concurrency matter.

Those workloads are mostly system-shaped. A Data Agent workload is behavior-shaped.

This also means adoption success changes the estimate. A pipeline normally does not decide to run ten times more often because people like it. A useful agent can spread rapidly through Teams, Microsoft 365 Copilot, Copilot Studio, Foundry, or an MCP-enabled application. The architecture must account for that path before broad rollout.

The pilot is part of the estimate

The first worksheet gives you a hypothesis. A controlled pilot turns it into evidence.

Use a representative group and a question set that includes common lookups, comparisons, follow-ups, ambiguous requests, and complex questions. Do not test only the five prompts used in the demo.

In the Fabric Capacity Metrics app:

1. Filter the item kind to LlmPlugin and the operation to AI Query.
2. Record CU-seconds, operation count, and unique users for the pilot window.
3. Calculate measured AI CU-seconds per request.
4. Identify the queried warehouse, semantic model, or KQL item and record its incremental query consumption over the same period.
5. Segment the test questions into simple, standard, and complex classes.
6. Capture p50 and p90 consumption, not only the mean.
7. Repeat long conversations separately because history changes prompt size.

The Capacity Metrics app provides a 14-day compute view, hourly ribbons, 30-second timepoints when filters are applied, and an item-and-operation matrix. Usage normally appears with a processing delay, so do not expect every test to show immediately.

Then replace the planning assumptions in the worksheet with measured values and extrapolate using the expected adoption curve.

Configuration is also a cost control

Data Agent optimization is not just about reducing tokens. The goal is to reduce unnecessary work without making answers worse.

• Limit the agent to relevant sources and tables. A focused schema reduces ambiguity and helps the agent choose the right objects.
• Keep instructions specific. Long, conflicting instructions add context and can make routing less predictable.
• Use examples where they resolve recurring ambiguity. More examples are not automatically better; they also become part of the context used to answer questions.
• Prepare semantic models for AI. Clear names, a focused AI data schema, explicit measures, verified answers, and efficient DAX improve both accuracy and query performance.
• Set response expectations. If users need a number and a short explanation, do not default to an essay.
• Optimize the source engine. A cheaper prompt does not compensate for an inefficient DAX measure or an unbounded KQL query.

Good configuration improves accuracy, latency, and capacity efficiency at the same time. That is a better target than minimizing one meter in isolation.

Should AI usage have its own capacity?

By default, Fabric bills Data Agent AI usage to the capacity that holds the content. Microsoft also supports designating a Fabric Copilot capacity and assigning groups of users to it. Their Copilot and Data Agent AI usage is then charged to that designated capacity, which centralizes monitoring and billing.

This can be useful when AI adoption spans many workspaces or when platform teams want a clearer AI budget. It does not remove the second half of the calculation. Microsoft documents generated query execution as a separate charge to the corresponding query engine item, so source-engine demand still needs to be measured and planned.

Treat a dedicated Copilot capacity as a routing and governance decision, not as a shortcut around end-to-end sizing.

The estimation checklist

Before approving capacity for a Fabric Data Agent, capture these inputs:

• Active users by rollout phase, not just the eligible population
• Questions per active user per day
• Working days and known peak periods
• Simple, standard, and complex request mix
• Uncached input, cached input, and output token distributions
• Generated query CU-seconds by source type
• Existing capacity baseline and peak windows
• Expected adoption growth and external invocation channels
• Headroom target and throttling tolerance
• Pilot results from the Capacity Metrics app

Then keep two numbers visible: AI Query consumption and source-engine consumption. Combining them into one unexplained average makes troubleshooting and optimization harder later.

The better sizing question

The wrong question is, “How many Data Agent users fit on an F64?”

There is no durable answer because users, questions, context, outputs, and generated queries are not uniform.

The better question is:

What request mix do we expect, what does each class consume end to end, and how much room remains after the platform’s existing workload?

That is how Data Agent capacity planning differs from traditional Fabric scoping. You are not only sizing compute. You are sizing adoption, conversation, and the query work hidden behind a natural-language interface.

Consumption rates and product behavior can change. Verify the current Data Agent consumption guidance, Fabric operations reference, and Capacity Metrics app documentation before using the formulas for a production decision.