Fabric Agent Performance Observation and Optimization Guidance

Rajeev Ranjan 0 Reputation points
2026-11-03T13:40:53.4033333+00:00

We are experiencing performance concerns with our Microsoft Fabric Agent and would appreciate your guidance on whether the observed behavior is expected and if there are additional optimization opportunities.

Our setup consists of:

  • Approximately 20 tables
  • Total data volume of only ~1 MB
  • A semantic model built on the dataset
  • An ontology configured for business context
  • A Fabric Agent with well-defined instructions to answer user questions

Despite the relatively small dataset size, we are observing the following:

  • Simple queries typically take 10-20 seconds to return a response.
  • More complex queries, requiring deeper reasoning, aggregations, or multi-step analysis, take significantly longer.

Given the small data footprint and the semantic model/ontology already in place, we would like to understand:

  1. Is this response time expected for Fabric Agents?
  2. What are the major components contributing to the overall latency (query planning, ontology retrieval, semantic model execution, LLM reasoning, response generation, etc.)?
  3. Are there any recommended best practices or configuration changes that could further optimize performance?
  4. Have we potentially reached the practical performance limits of the current architecture, or is there still scope for meaningful improvement?

Any guidance on expected performance benchmarks and optimization recommendations would be greatly appreciated.

Thank you for your support. We are experiencing performance concerns with our Microsoft Fabric Agent and would appreciate your guidance on whether the observed behavior is expected and if there are additional optimization opportunities.

Our setup consists of:

  • Approximately 20 tables
  • Total data volume of only ~1 MB
  • A semantic model built on the dataset
  • An ontology configured for business context
  • A Fabric Agent with well-defined instructions to answer user questions

Despite the relatively small dataset size, we are observing the following:

  • Simple queries typically take 10-20 seconds to return a response.
  • More complex queries, requiring deeper reasoning, aggregations, or multi-step analysis, take significantly longer.

Given the small data footprint and the semantic model/ontology already in place, we would like to understand:

  1. Is this response time expected for Fabric Agents?
  2. What are the major components contributing to the overall latency (query planning, ontology retrieval, semantic model execution, LLM reasoning, response generation, etc.)?
  3. Are there any recommended best practices or configuration changes that could further optimize performance?
  4. Have we potentially reached the practical performance limits of the current architecture, or is there still scope for meaningful improvement?

Any guidance on expected performance benchmarks and optimization recommendations would be greatly appreciated.

Note: We are using fabric capacity - F8.

Thank you for your support.

Microsoft Foundry
Microsoft Foundry

A unified Azure platform for creating and managing AI models, agents, and applications with built‑in enterprise security, monitoring, and governance

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-11-03T13:42:11.9766667+00:00

    There is no published Microsoft latency benchmark guaranteeing a particular response time for Fabric data agents on F8, so isolate agent orchestration, generated-query execution, and capacity delay before considering a capacity upgrade.

    A 10–20-second end-to-end response is plausible for this multi-stage pipeline, but it cannot be classified as either normal or an F8 limit from data size alone. Fabric supports data agents on F2 or higher, but that prerequisite is not a response-time SLA.^1^

    Where the time is spent

    For a semantic-model question, the documented flow includes:

    1. Azure OpenAI parses the question.
    2. The orchestrator selects a data source using schema information and instructions.
    3. The DAX generation tool examines model metadata, Prep for AI configuration, and conversation history.
    4. The generated DAX runs against the semantic model.
    5. The agent formats the result into a response.^2^

    Ontology adds another interpretation and routing layer. It supplies entities, relationships, synonyms, mappings, and bindings; the agent then selects an underlying source and generates DAX, SQL, or KQL, while that underlying source performs the actual execution.^3^

    Consequently, reducing the stored data from several megabytes to 1 MB does not remove planning, metadata processing, model inference, validation, or response-generation time. Complexity of the schema, measures, relationships, ambiguity, conversation history, and required reasoning can matter more than row volume.

    Measure the bottleneck first

    Run a controlled test with 10–20 representative questions, separating simple lookups from aggregations and multi-step questions.

    1. Open the data agent test experience and submit each question.
    2. Open its run steps.
      • Record the selected source.
      • Copy the generated DAX.
      • Note whether the agent retried, refined, or performed multiple steps.
    3. Run the generated DAX directly against the semantic model using DAX Query View.
    4. Compare direct DAX duration with total agent duration:
      • Fast DAX, slow agent: most latency is in orchestration, context selection, query generation, or response generation.
      • Slow DAX: optimize the semantic model, measures, relationships, or storage path.
      • Wrong source or unnecessary complexity: reduce ambiguity in ontology mappings, source descriptions, and schema scope.

    The ontology run steps are specifically intended to expose the selected source, generated query, and source errors.^3^

    Optimize the semantic-model path

    Apply these changes in this order:

    1. In Power BI Desktop or Power BI service → Home → Prep data for AI → Simplify data schema, expose only the tables, columns, and measures needed by this agent.
    2. Select the same tables in the Fabric data agent.
    3. Remove unnecessary columns and measures from the AI-visible scope—not necessarily from the physical model.
    4. Use descriptive business names and descriptions for tables, columns, and measures.
    5. Add Verified Answers for common or expensive questions.
    6. Put semantic-model business terminology and query-generation guidance under Prep for AI → Add AI instructions.

    The DAX generation tool relies on semantic-model metadata and Prep for AI and ignores data-agent-level instructions for DAX generation. Microsoft also states that a focused AI schema reduces ambiguity and response latency.^2^

    This is particularly relevant to a 20-table model: 1 MB is small, but exposing all 20 tables and many overlapping fields still increases the metadata and routing search space.

    Validate the ontology configuration

    Ontology context is currently preview. For ontology-backed questions:

    • Keep entity definitions, synonyms, relationships, mappings, and bindings precise.
    • Remove duplicate or ambiguous business terms.
    • Ensure each entity maps to the intended underlying source.
    • Download the ontology context and check what the agent actually received.
    • Refresh the context after changes.

    A notable limitation is that Power BI semantic models do not support supplemental data-agent-specific context in this integration, and query generation might not use some ontology context.^3^

    Determine whether F8 is contributing

    Use the Fabric Capacity Metrics app and correlate timestamps with slow requests:

    • CU utilization
    • Interactive delay and rejection
    • Concurrent workloads
    • Semantic-model operations
    • Refreshes, notebooks, pipelines, or other workloads sharing F8

    If there is no interactive throttling at the relevant times, capacity throttling is not the cause; increasing the SKU might add concurrency headroom without materially reducing fixed LLM/orchestration latency. If interactive delay aligns with the tests, first isolate competing workloads, then test a temporary scale-up. Fabric recommends optimizing, scaling up, or scaling out when utilization and throttling establish capacity pressure.^4^

    Test the preview runtime separately

    For a semantic model and ontology, the preview runtime provides advanced DAX generation and improved ontology cross-source handling. Advanced DAX uses multiple reasoning steps, so it can improve complex-query accuracy and sometimes latency, but it is not guaranteed to make every request faster.^5^

    A/B test standard and preview runtimes with the same questions, recording median and p95 latency plus answer correctness. Preview behavior can change between releases, so validate it before production adoption.

    Practical conclusion

    You have not established that F8 or the architecture has reached its performance limit. Meaningful improvement remains possible if latency comes from:

    • oversized AI-visible schema;
    • inefficient DAX or measures;
    • ambiguous source selection or ontology mappings;
    • multi-step retries;
    • F8 contention or throttling.

    If direct DAX is fast, capacity is unthrottled, the AI schema is already minimal, and repeated tests still cluster around 10–20 seconds, that remaining duration is primarily agent-pipeline overhead. Scaling capacity should then be treated as an experiment for concurrency—not as a guaranteed single-request latency fix.

    References

    1. Create a Fabric data agent - Microsoft Fabric | Microsoft Learn
    2. Semantic model best practices for data agent - Microsoft Fabric
    3. Use Ontology as context in Fabric data agent - Microsoft Fabric
    4. Evaluate and optimize your Microsoft Fabric capacity
    5. Fabric data agent runtime
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.