Conversational analytics makes omission difficult to see. A first answer can be correct for the 25 rows it displays, while a follow-up such as “which of those declined fastest?” silently reasons over that limited set instead of the complete source result. The generated query, formatted answer, retained context, and user's interpretation can each be locally plausible while the final decision is wrong.
Microsoft documents that Fabric Data Agent chat outputs are capped at 25 rows and 25 columns, previous chat history can influence later responses, and follow-ups can be answered from already limited context. Microsoft recommends starting a new chat in such cases. It also notes that conversation history might not always persist. These are product-contract issues, not prompt-writing details.
Can you prove whether a follow-up used the complete source result, a 25-row display, or a prior summary? If not, do not treat the answer as decision-ready.
Define an approved conversation contract
For every high-impact question family, define the authoritative source, expected query, full row and column population, permitted summary, required disclosure, follow-up semantics, session boundary, user identity, retention expectation, reset behavior, target clients, and the point at which the agent must ask for clarification or direct the user to a governed report.
| Contract element | Failure risk | Required evidence | Safe control |
|---|---|---|---|
| Source population | The displayed 25 rows are mistaken for the complete query result. | Executed query, source row count, returned row count, ordering, filters, and user permissions. | Aggregate at the required grain, disclose the limit, or link to a governed dataset. |
| Column population | Omitted fields hide denominators, units, dates, identifiers, or decision caveats. | Expected schema, returned 25-column boundary, selected fields, and excluded-field rationale. | Request only decision-critical fields or use an approved report/export path. |
| Follow-up scope | “Those,” “them,” “same period,” or “compare again” binds to stale or limited context. | Resolved references, rewritten standalone question, query diff, and approved interpretation. | Restate the scope, confirm assumptions, or start a new chat. |
| Session state | History is reset, unavailable, or retained differently than the workflow assumes. | Client, tenant setting, geography, elapsed time, clear-chat behavior, and persistence test. | Store approved assumptions outside chat and make each critical request reproducible. |
| Identity and policy | A follow-up crosses source, RLS, CLS, DLP, or access boundaries unexpectedly. | Effective user, source permissions, generated query, policy outcome, and audit evidence. | Fail closed, reauthenticate, narrow scope, or route to a governed workflow. |
| Decision meaning | A concise summary overstates completeness, causality, confidence, or freshness. | Ground-truth answer, as-of time, full population, caveats, and reviewer interpretation. | Human review, approved language, or prohibit the question family. |
Treat the 25-row and 25-column boundary as part of the answer
Microsoft says Fabric Data Agent is designed for conversational insight rather than complete dataset delivery. Chat responses can be limited or summarized and currently return no more than 25 rows and 25 columns. A request to “show all rows” does not remove that ceiling. The interface may therefore answer a broad request with a narrow representation while preserving fluent language.
Test 24, 25, and 26 rows; 24, 25, and 26 columns; unsorted and explicitly ordered results; ties at the boundary; nulls; duplicate labels; permission-filtered populations; and summaries whose conclusion changes when the omitted records are included. Record the source result and displayed response separately.
Do not solve the problem by asking the agent to paginate conversationally unless the complete ordered population and state transition are independently controlled. For complete datasets, reconciliation, regulatory evidence, or repeatable operational handoffs, use an approved query, report, export, API, or application workflow rather than chat output.
Test single-turn truth and multi-turn drift separately
| Test family | Test sequence | Pass condition | Remediation |
|---|---|---|---|
| Boundary fidelity | Ask questions returning 24/25/26 rows and columns with deterministic controls. | Limit behavior is known, stable, disclosed, and doesn't alter the approved conclusion. | Aggregate, narrow, reorder, disclose, or use a non-chat delivery path. |
| Pronoun resolution | Use “those,” “same,” “remaining,” and “compare them” after limited responses. | Each reference resolves to the intended full or explicitly limited population. | Rewrite as standalone questions or require scope confirmation. |
| Context contamination | Introduce an incorrect premise, then ask a valid follow-up in the same and a new chat. | The agent rejects the premise or produces the same grounded answer after reset. | Instructions, clarification rules, reset guidance, examples, or blocked use case. |
| Sequence invariance | Ask the same target question after different preceding conversations. | Material query logic and answer remain correct across approved histories. | Standalone request templates, context isolation, or workflow redesign. |
| History loss | Clear chat, revisit later, and test service/runtime changes in the target client. | The workflow detects missing context and never invents continuity. | External state, explicit restart, session indicator, or user confirmation. |
| Security drift | Repeat sequences across allowed, restricted, RLS, CLS, DLP, and denied personas. | Every turn uses the current user's effective permissions and fails closed. | Permission correction, policy update, source split, or rollout block. |
| Regression | Replay approved multi-turn suites after configuration, source, runtime, or model changes. | Query, result, disclosure, and decision metrics stay within release thresholds. | Rollback, retune, update controls, or restrict affected question families. |
For semantic models, Microsoft states that DAX generation can use schema, metadata, Prep for AI context, and conversation history. That makes sequence testing essential: a query that passes in isolation can differ after a prior turn changes the inferred metric, period, region, or comparison set. Keep both the generated query and source result in the evaluation evidence.
Separate analytical context from history retention
Conversation context affects answer quality; history retention determines whether that context is available later. Microsoft notes that history might be reset or lost during some backend infrastructure changes, service updates, or model upgrades. The Clear chat control erases history and starts a new session, and deleted history can't be retrieved.
Microsoft's tenant-setting documentation also describes cross-session storage for as long as the user allows, up to 28 days when the relevant cross-geo setting applies. Do not convert that into a universal retention promise. Verify tenant settings, capacity geography, client behavior, policy, user deletion, and the current service release for the exact deployment.
Never use chat history as the system of record for definitions, approvals, incident evidence, or operational state. Persist approved assumptions, queries, evaluation traces, and decisions in governed systems. A critical follow-up should be reproducible as a standalone request even when the chat history is empty.
Run a two-to-four-week context drift assessment
- Select one Data Agent, target clients, decision owners, user personas, critical question families, prohibited uses, and source owners.
- Map chat limits, generated-query visibility, history behavior, tenant settings, geography, permissions, retention, clear-chat flow, and current failures.
- Create single-turn and multi-turn ground truth with approved questions, standalone rewrites, source queries, full results, expected summaries, and caveats.
- Run row and column boundaries, ordering, ties, pronouns, changed assumptions, conflicting premises, new-chat controls, history loss, permissions, and client-path tests.
- Classify failures by source, query generation, truncation, summarization, reference resolution, stale context, missing context, identity, policy, client, or user interpretation.
- Refine data shape, instructions, examples, question templates, reset UX, non-chat fallbacks, retention guidance, and release thresholds.
- Deliver the conversation contract, evaluation suite, history lifecycle matrix, approved-use boundaries, monitoring, rollback rules, runbooks, and go, limit, or stop recommendation.
Frequently asked questions
What is the Fabric Data Agent chat output limit?
Microsoft currently documents a maximum of 25 rows and 25 columns for Fabric Data Agent chat outputs. Responses can be limited or summarized, so an apparently complete answer might represent only part of the executed result. Teams should test row counts, column counts, ordering, summaries, and disclosures against a trusted control.
Can previous Fabric Data Agent chat history affect a follow-up answer?
Yes. Microsoft states that previous chat history can influence subsequent responses and that follow-up questions might be answered from already limited context. A request to show all rows still returns no more than 25 rows. High-impact follow-ups should be tested both in sequence and in a new chat.
Does Fabric Data Agent conversation history always persist?
No. Microsoft notes that conversation history might be reset or lost during some backend infrastructure changes, service updates, or model upgrades. Workflows should not use chat history as the system of record or the only place where analytical assumptions are retained.
How long can Fabric Data Agent conversation history be stored?
Microsoft's tenant-setting documentation says cross-session conversation history can be stored for as long as the user allows, up to 28 days when the relevant cross-geo setting applies, and users can clear it. Exact behavior depends on tenant configuration, geography, client, and current service behavior, so verify the target environment.
How long does a Fabric Data Agent context drift assessment take?
A focused assessment commonly takes two to four weeks for one agent, target clients, representative multi-turn questions, and critical user roles. It covers 25-row and 25-column boundaries, follow-up dependence, new-chat controls, history persistence, permissions, query fidelity, regression testing, release gates, and monitoring.
Official implementation references
- Fabric Data Agent conversation history and 25-by-25 output limitations
- Fabric Data Agent clear-chat behavior and query transparency
- Fabric Data Agent tenant settings and conversation-history storage
- Semantic model query generation and conversation context
- Fabric Data Agent configuration and example-query guidance
Start with the follow-up that would cause the largest decision error if “those” meant only the displayed 25 rows. Datrick can reproduce the sequence, reconcile every query, test history and reset behavior, and define a reliable conversation contract.