Forum Discussion
Fabric Data Agent Limitations of 25 items
There's no way for Fabric Data Agent to give more than 25 items of a list. And this is quite confusing.
I have a dataset with the States and Presidents of USA. It is full with 50 states and 47 presidents.
As you can see here, when asking for the list, it only contains the 25 first.
When looking at the DAX query, it gives the 50 in result.
// List all U.S. states with their abbreviations, sorted by state name.
EVALUATE
SELECTCOLUMNS(
// Use SUMMARIZE to ensure distinct state rows if duplicates exist
SUMMARIZE(
'america_states',
'america_states'[nom],
'america_states'[abréviation]
),
"State Name", 'america_states'[nom],
"Abbreviation", 'america_states'[abréviation]
)
ORDER BY
[State Name] ASC
No TOPN here, or any filter/limitation.
When asked, Agent says there are 50 lines in the table (good answer), but says that the "tool" gives only 25. Obviously, the "tool" is not DAX because it is correct. It's another mysterious tool.
I understand that, to maintain a "conversation context", the "tool" is limited on answers with 25 items.
My colleagues and I are looking for use-cases when Fabric Data Agent could be relevant. But this limitation of 25 (which is very small, he can't even give the 50 states of USA) is a bad argument for us to use this Fabric Artefact.
When trying to build cool agents for the company, and when testing them, users may ask some lists of items. They could have a warning for the partial results.. but 25... gasps !!!
Of course, when you ask Copilot for the Web, you get a list with more than 25 items
"Here’s the full list of the 50 U.S. states and their capitals in English:
- Alabama – Montgomery
- Alaska – Juneau
- Arizona – Phoenix
- Arkansas – Little Rock
- California – Sacramento
- North Carolina – Raleigh
- South Carolina – Columbia
- Colorado – Denver
- Connecticut – Hartford
- North Dakota – Bismarck
- South Dakota – Pierre
- Delaware – Dover
- Florida – Tallahassee
- Georgia – Atlanta
- Hawaii – Honolulu
- Idaho – Boise
- Illinois – Springfield
- Indiana – Indianapolis
- Iowa – Des Moines
- Kansas – Topeka
- Kentucky – Frankfort
- Louisiana – Baton Rouge
- Maine – Augusta
- Maryland – Annapolis
- Massachusetts – Boston
- Michigan – Lansing
- Minnesota – Saint Paul
- Mississippi – Jackson
- Missouri – Jefferson City
- Montana – Helena
- Nebraska – Lincoln
- Nevada – Carson City
- New Hampshire – Concord
- New Jersey – Trenton
- New York – Albany
- New Mexico – Santa Fe
- Ohio – Columbus
- Oklahoma – Oklahoma City
- Oregon – Salem
- Pennsylvania – Harrisburg
- Rhode Island – Providence
- Tennessee – Nashville
- Texas – Austin
- Utah – Salt Lake City
- Vermont – Montpelier
- Virginia – Richmond
- West Virginia – Charleston
- Washington – Olympia
- Wisconsin – Madison
- Wyoming – Cheyenne"
Does anyone agree that the limitation is too smal ?
Thanks
Hi jFloury , Thank you for reaching out to the Microsoft Community Forum.
From your screenshots I can now see the difference you’re seeing isn’t coming from your data or your prompt. Your agent is using the earlier table display, which shows a simple static grid and still trims longer outputs to around 25 rows. In my environment the agent uses the newer table view, which includes the row count, search box and full-result rendering, so all 50 rows show up.
Both views run the same query and retrieve all rows, the only difference is the UI layer that renders the tool output. Since Agents are still in preview, some parts of the experience can appear at different times across regions or workspaces and once the updated table view is active in your tenant, I am sure you’ll see the full result the same way without needing to change anything.
8 Replies
- jFlouryFrequent Visitor
Just in case, I asked the agent not to hallucinate with precendent knowledge
I want only tool-based result, don't use precedent knowledge. - v-hashadapu
Community Support
Hi jFloury , Thank you for reaching out to the Microsoft Community Forum.
I tested this scenario on my side using a table with all 50 U.S. states and asked the Agent the same question you used. In my case, the Agent returned all 50 rows. The difference seems to come from how the Agent decides to format the output rather than how it retrieves the data. When the Agent formats the result as a table, it returns the full dataset without any truncation. When it formats the result as a natural language list (like in your screenshot), the current Agent design limits list style responses and only surfaces part of the dataset, which is why you saw 25 items.
The underlying query is not being limited, the Agent still detects all 50 rows in your table. The truncation happens only when the model shifts into list formatting. This formatting decision can vary depending on the prompt wording, which explains why you and I received different output shapes from the same data.
If you want to consistently get the complete dataset, the most reliable workaround is to explicitly request table-only tool output, for example: “Return the tool output only as a table, with no list formatting.” This forces the non-truncated format every time. Paginating manually (“next 25 rows”) also works if you prefer list output.
- jFlouryFrequent Visitor
Hi v-hashadapu ,
Thank you so much for you reply. Unfortunately, the Agent is stubborn.
It stops at 25 items, even in a a table format (which is lovely, thanks).
Can you screenshot your prompt and results please ?
Did you use a semantic model as source, or a lakehouse with the table ?
- v-hashadapu
Community Support
Hi jFloury ,
I initially tested this using a lakehouse table and the Agent returned all 50 states for me. I tried the same test again using a semantic model as the source and I saw the same result, the full set of 50 rows came back. I’m attaching the screenshots below so you can compare the prompts and the output.
My output from using lakehouse:
My experiment with semantic model:
I hope i understood your issue clearly and answered it. Please try this and share the results.
- MahadevanpRegular Visitor
Any update on this or this is still a limitation?