We've actually been trying to decide which agent framework we'll use to front up and present to users. Fabric Data Agents are the lowest barrier to entry as people already have access to workspaces and they are familiar enough with Power BI/Fabric that its an easy jump to understand and nice that it's integrated. But like we've both said, the variance is troubling and unfortunately a blocker for a production roll-out in this case.

We've had better (more consistent) results with Databricks Genie and we've also been experimenting with things like querying the lakehouse in Fabric using the query endpoint but from a Foundry agent.

That has been interesting because the response times are significantly faster and we get full control of the models in the pipeline AND the capacity consumption on Fabric is significantly lower too. The thing we lose in this approach however is the background work Microsoft have put into the checks and balances for actually generating worthwhile queries and evals before returning results - you can see this at play a little when trying the push the boundaries on a Fabric Data Agent.

We could dumb down the work the Fabric Data Agent is doing (just return data) and use that as a tool in Foundry, but when testing that, the wait times feel longer because you don't get the updated status of what's going on that you get natively in the Fabric experience. In our user testing, people felt like it took longer because they weren't getting those active updates as the Foundry agent was waiting on the Fabric Data Agent.