How are teams using AI agents to automate data science workflows?
I am exploring how AI agents can support modern data science workflows by automating repetitive tasks and improving collaboration between data teams. Some potential use cases: Automating data exploration and preprocessing steps Generating insights from datasets using natural language queries Assisting with feature engineering and model evaluation Triggering ML pipelines based on business events Monitoring model performance and identifying data quality issues I would like to understand how data science teams are combining Microsoft Fabric, notebooks, ML workflows, and AI agents in real-world projects. What approaches, tools, or architecture patterns are you using for AI-assisted data science workflows?How can AI agents improve decision-making with Microsoft Fabric IQ?
I am exploring how AI agents can work with modern data platforms to help businesses move from traditional reporting toward proactive decision-making. Some possible use cases: AI agents analyzing business data and identifying important trends Automatically generating insights from Fabric data models Triggering workflows based on detected patterns or anomalies Helping teams interact with enterprise data using natural language Combining AI reasoning with governed data sources I would like to understand how the community is approaching AI-powered analytics with Microsoft Fabric IQ. Are teams using AI agents, Copilot experiences, or custom automation workflows on top of Fabric data solutions? What architecture patterns and best practices have you found useful?
Data Agent fails to query Ontology
Hello, I’m experiencing an error when using the Data Agent in Microsoft Fabric to query my Ontology. Even when I ask very simple questions, the Data Agent fails every time with the following error: Failed to execute step (RAID: "GUID"). Error: Failed to generate NL2Ontology query with error "{"code":"InternalError","subCode":0,"message":"An internal error occurred.","timeStamp":"2026-04-20T13:00:42.7677176Z","httpStatusCode":500,"hresult":-2147467259,"details":[{"code":"RootActivityId","message":"GUID"},{"code":"Param1","message":"Failed to translate NL query to ontology query."}]}" This was working correctly until last week, but for the past four days it has consistently failed with the error above, without any changes on my side. The Data Agent works perfectly when querying: a Lakehouse (NL2SQL), and a Semantic Model (NL2DAX). The issue occurs only when the Ontology is used as the data source. Also I have "Support GROUP BY in GQL" inside the data agent's instructions. Could someone please help me understand what might have changed recently or how to troubleshoot this issue? Thank you in advance.Data Analytic Group Monthly Connect September 2026 : Building Smarter with Microsoft Fabric IQ
This session combines technical architecture with real-world examples to show how conversational AI is changing the way we work with data - directly inside Microsoft Fabric. organizations explore the next wave of AI, the question is no longer “Can we use AI?” - but “How can we use it meaningfully?” This session explores how Microsoft Fabric IQ and Data Agents enable new ways to access, understand, and automate data – without switching tools or writing custom code. You’ll learn how to: 1. Connect natural language interfaces to lakehouses, warehouses & semantic models 2. Use Fabric IQ ontologies to bring business meaning to technical data 3. Deploy Data Agents that retrieve, plan, and summarize based on user intent 4. Build agent-driven workflows that feel intuitive - and actually get things done This session combines technical architecture with real-world examples to show how conversational AI is changing the way we work with data - directly inside Microsoft Fabric. Speaker : Hanna Schwab,Data & AI Lead @ teccle group | Microsoft Foundry MVP Organizers: Rajendra Ongole, Koundinya Lanka,Shashi,Navya K COO: Charitha Reddy, Meghana,Sreekar T 𝑹𝒆𝒈𝒊𝒔𝒕𝒆𝒓 𝒂𝒕 𝑴𝒆𝒆𝒕𝒖𝒑: https://www.meetup.com/dataanalyticgroup/ 𝑱𝒐𝒊𝒏 𝒕𝒉𝒆 𝑾𝒉𝒂𝒕𝒔𝑨𝒑𝒑 𝑮𝒓𝒐𝒖𝒑: https://chat.whatsapp.com/CkMRYzyoKSNKbXUs2IN2MU 𝑱𝒐𝒊𝒏 𝒕𝒉𝒆 𝑾𝒉𝒂𝒕𝒔𝑨𝒑𝒑 𝑪𝒉𝒂𝒏𝒏𝒆𝒍 𝑳𝒊𝒏𝒌:https://whatsapp.com/channel/0029VaBgfAwDOQIeuTjGbF3u YouTube channel: https://www.youtube.com/@Dataanalyticgroup 𝑱𝒐𝒊𝒏 𝒖𝒔 𝒐𝒏 𝑭𝒂𝒃𝒓𝒊𝒄 𝑪𝒐𝒎𝒎𝒖𝒏𝒊𝒕𝒚 : https://community.fabric.microsoft.com/t5/Data-Analytic-Group/gh-p/DataAnalyticGroup 𝑨𝒍𝒔𝒐 𝒂𝒗𝒂𝒊𝒍𝒂𝒃𝒍𝒆 𝒐𝒏 Discord: https://discord.gg/CGvZ2Nu9 𝑨𝒍𝒔𝒐 𝒂𝒗𝒂𝒊𝒍𝒂𝒃𝒍𝒆 𝒐𝒏 Telegram: https://t.me/DataAnalyticGroup We look forward to having you attend the event!
Foundry Agent with Fabric data agent tool times out at 100s even in background mode
A Foundry agent with a Fabric data agent attached cancels any tool call that takes longer than 100 seconds, even with background mode enabled on a model that supports it. The documentation presents background mode as the supported path for MCP tool calls that exceed the synchronous timeout, but it does not lift the limit here. Setup Foundry project on Microsoft.CognitiveServices, West Europe Agent kind prompt, model gpt-5.6-luna (2026-07-09) metadata."microsoft.background-mode.enabled": "true" Requests to {project_endpoint}/openai/v1/responses with "background": true and an agent_reference Tested with both the fabric_iq_preview tool and the generic mcp tool, same server_url and same project_connection_id (authType: UserEntraToken) Behaviour Background mode is genuinely active: the response returns status: queued immediately and stays in_progress well past 100 seconds, so the model does support it. But the MCP tool call inside the run is still cancelled at exactly 100 seconds: { "code": "tool_user_error", "message": "TaskCanceledException encountered while invoking tool DataAgent_<name>: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.. The remote MCP server did not complete the request within the configured timeout." } Same failure both ways — fabric_iq_preview failed at 115s, generic mcp at 108s. The response output shows a single mcp_call with status=failed. Why this looks like a Foundry-side gap The Fabric data agent MCP server advertises task support on initialize: "capabilities": { "tools": { "listChanged": false }, "tasks": { "list": {}, "cancel": {}, "requests": { "tools": { "call": {} } } } } and per tool in tools/list: "execution": { "taskSupport": "optional" } Calling that same server directly as a task, rather than through Foundry, completes the exact query Foundry cancels — in 81 to 173 seconds depending on the run. So the data agent can answer these questions; only the call made by Foundry is constrained. One detail that may explain it: the server advertises tasks as a top-level capability and accepts a task via a task field in the request params — an earlier form of the extension, rather than the current capabilities.extensions["io.modelcontextprotocol/tasks"] negotiation. A client following the current draft would not find the capability where it expects it and would fall back to a blocking call, which matches what we see. Questions Is background mode expected to lift the 100-second tool-call timeout for a Fabric data agent today, or is that combination not yet supported? Does Foundry's MCP client negotiate tasks with a server advertising them in this older form? If not, is alignment planned? Is there any setting, api-version, or tool property that makes Foundry request a task instead of blocking? Nothing in the agent definition or the portal changed the behaviour for us.Fabric Data Agent: “Query cancelled” on aggregations
Good evening, I’m trying to build a Data Agent for my organization, even though the feature is still in preview. Its source is an ontology. I’m currently working with only six tables, but they are very large. I’m having an issue when asking the Data Agent questions that require grouping and aggregation, such as COUNT or SUM. In those cases, I often get the following error: "Query cancelled by upstream caller Status Code: Cancelled" The agent suggests that this may be caused by the amount of resources required by the query, which seems plausible. I also tried using smaller tables in the ontology. This improved things somewhat, and some queries now work, but aggregations are still extremely slow and I still frequently receive the same error. Is this expected behavior with large ontologies and aggregation queries, or could there be some configuration or setting that needs to be changed? Is there anything I can do to improve the performance of GROUP BY, COUNT, and SUM queries over an ontology-backed Data Agent? EDIT: I also found the following error in one of the question's execution log: 'The request was canceled due to the configured HttpClient.Timeout of 300 seconds elapsing.'Microsoft Fabric Data Agent – HttpClient.Timeout after 300 seconds: where is it configured?
Hi everyone, this post is a follow-up to a previous discussion I opened about Fabric Data Agent queries being cancelled during aggregations: https://community.fabric.microsoft.com/t5/IQ/Fabric-Data-Agent-Query-cancelled-on-aggregations/td-p/5357096 After further testing, I believe I have isolated the issue more clearly, so I am opening a new post with a more specific title and description. The goal is also to make the issue easier to find for anyone searching for HttpClient.Timeout, 300 seconds, or Microsoft Fabric Data Agent timeout problems. The main issue is the following: Some Microsoft Fabric Data Agent requests fail after approximately 300 seconds because of HttpClient.Timeout. I am using a Fabric Data Agent with a Microsoft Fabric Ontology as its data source. The problem mainly appears on expensive queries, especially aggregations and queries involving larger portions of the ontology. However, further experiments suggest that this is not simply a query-performance or capacity issue. I have different Data Agents using the same underlying Ontology. One agent can execute queries for much longer than 5 minutes, in some cases close to 20 minutes. Another agent consistently fails after approximately 5 minutes with an HttpClient.Timeout. Fabric Capacity does not appear to be close to saturation when the timeout occurs. Individual entities can be queried correctly. This makes the fixed approximately 300-second behavior particularly confusing. The question I am now trying to answer is very specific: Which component in the Microsoft Fabric Data Agent architecture is enforcing this HttpClient.Timeout? For example, is the timeout defined in: the Data Agent orchestration layer, the MCP server associated with the published Data Agent, an internal Fabric service calling the ontology or graph engine, the client consuming the agent, or another intermediate HTTP layer? And, most importantly: Is this 300-second HttpClient.Timeout configurable anywhere? I have found other timeout-related settings in the surrounding architecture, but I have not found documentation identifying a setting that clearly corresponds to this specific timeout. There is also another important behavior that I would like to understand. If the published Data Agent is consumed programmatically, for example from a notebook or through its MCP endpoint, does the same 300-second HttpClient.Timeout still apply? Or does that use a different execution path with different timeout constraints? At this point I am specifically trying to identify the architectural source of the timeout rather than optimize the generated GQL query. The most useful clarification would therefore be: Where exactly is the 300-second HttpClient.Timeout enforced, and is there any supported way to configure it or use an execution path that does not have the same limit? This is related to my previous thread about query cancellation during aggregations, but the additional tests seem to narrow the issue down specifically to the HTTP timeout layer.Fabric Agent consistently fails: backend-error "Bearer token not provided"
Hello, I have configured a Fabric agent using only a few tables from a single semantic model. I set up the agent instructions by following Microsoft's recommendations and added the Code Interpreter tool. Each time I ask a question ("Test the agent's responses" area, the agent is not published), even a very simple one, the same scenario occurs: The agent quickly starts an analysis and then proposes a DAX query that is correct. During this analysis phase, I can even see that the output is correct. However, it always ends with an error similar to the one below, which appears in the notifications: backend-error" Status code RequestTimeout: Request to https://agents.francecentral.hyena.infra.ai.azure.com/agents/v2.0/subscriptions/xxx/resourceGroups/AgentServiceProdEUVNet/providers/Microsoft.MachineLearningServices/workspaces/asfrclmln@asfrclmln@AML/openai/files?api-version=1.0 timed out" When I follow the URL from the notification, I get the following message: { "error": { "code": "UserError", "severity": null, "message": "Bearer token not provided.", "messageFormat": null, "messageParameters": null, "referenceCode": null, "detailsUri": null, "target": null, "details": [], "innerError": { "code": "AuthorizationError", "innerError": null }, "debugInfo": null, "additionalInfo": null }, "correlation": { "operation": "a47975e7212fb2eb4011d15654c85245", "request": "f98696fc72828139" }, "environment": "francecentral", "location": "francecentral", "time": "2026-08-28T07:52:40.3322903+00:00", "componentName": null, "statusCode": 401 } Thank you in advance for your help.
