Weekly ML Roundup: Data Agents, Fabric Ops, and MLPerf Inference

by TechHub

This week's ML roundup focuses on how data agents are getting closer to production standards, from Fabric IQ and MCP-grounded Copilot Studio experiences to Databricks Genie evaluations that run as a continuous quality loop. On the platform side, Fabric shipped updates that reduce migration risk (BigQuery mirroring GA and an ODBC inventory tool for the ADBC cutover) and improve day-2 operations with bounded, read-only natural-language diagnostics for Fabric Data Warehouse. We also look at Azure's MLPerf Inference v6.1 results for DeepSeek-R1 on NVIDIA GB200 and GB300 systems, plus smaller governance and integration updates across Databricks and Fabric.

This Week's Overview

Fabric and Databricks data agents are getting more production-shaped

Copilot-style agents over OneLake data with Fabric IQ (ontology + MCP)

Building on last week's thread of moving agent access from ad-hoc prompts toward governed tools (including Fabric data agents in Copilot Studio and MCP-based access patterns), one walkthrough shows how to create a Copilot Studio agent that queries OneLake through Microsoft Fabric semantic models, using Fabric IQ Ontology exposed via MCP (Model Context Protocol) so the agent can ground questions in the same business definitions your BI layer uses.

A practical detail that stood out is the prompt-driven normalization step before retrieval, where the agent cleans up location inputs (misspellings, abbreviations) so semantic retrieval hits the right entities. For teams running global operations, this kind of light pre-processing can reduce false negatives without adding a separate data-cleaning pipeline. It is a good template for “agent UX” work where the hardest part is mapping messy human input onto curated dimensions.

Databricks Genie agent evaluation as a continuous loop (not a one-time test)

On the Databricks side, guidance this week focused on a point many teams still miss: if a data agent is not being re-evaluated, it is effectively running in production without monitoring. The Genie Agent Benchmarks approach frames evaluation as an ongoing workflow, with “Chat mode” scored via SQL-based checks and “Agent mode” using an LLM-as-judge to grade multi-step behavior.

The key implication is operational: you can treat agent quality as a metric with regression detection, not an occasional manual review, which fits the same production-guardrails direction we called out last week in Fabric (governance surfaces, telemetry, and repeatable ops). The post also calls out using Genie Code to structure these evaluations and improvements, which is useful if you need repeatable test runs as prompts, tools, and underlying data change.

Foundry IQ orchestration across Fabric, ERP data, docs, and web sources

This extends the end-to-end “retail assistant” style builds we highlighted last week (Azure AI Foundry + Fabric) into a broader decision-support pattern, using Azure AI Foundry (Foundry IQ) to orchestrate reasoning across Fabric IQ (including ontology), Dynamics 365 Finance & Operations via an ERP MCP server, SharePoint policy documents, and Web IQ, with Azure AI Search providing the retrieval backbone.

For developers, the interesting part is the explicit separation of sources and tool boundaries, which makes it easier to reason about permissions and governance. If you are designing assistants that need to combine structured ERP facts with policy constraints and unstructured documents, this is a concrete reference for how Microsoft expects those integrations to be wired together.

Fabric platform updates that reduce migration risk and improve ops visibility

BigQuery mirroring reaches GA (cross-cloud analytics without custom pipelines)

Mirroring for Google BigQuery in Microsoft Fabric is now generally available, which matters if your analytics reality is “some data is in BigQuery and it is not moving soon.” GA status signals production support and an enterprise SLA, and it is positioned as a way to bring BigQuery data into Fabric without building and maintaining ingestion pipelines.

For teams trying to standardize on Fabric for downstream modeling or AI workloads, mirroring can remove a lot of brittle glue code. It also changes how you plan governance: instead of owning a separate ingestion job, you manage the mirrored data as part of the Fabric estate.

Self-serve ODBC inventory for the ADBC cutover

Following last week's GA announcement and guidance to start validating the ODBC to ADBC (Arrow Database Connectivity) transition early, Microsoft added a practical migration tool: pq-adbc-advisor. It is a Fabric notebook-based scanner that inventories ODBC usage across Fabric workspace items, then generates a per-item risk report so teams can prioritize what to fix before announced ADBC cutover dates.

The implementation angle is important for admins and platform teams: it relies on Fabric workspace scanning (via the Fabric admin Scanner API) rather than manual surveys. If you have many semantic models, dataflows, and reports created over time, an automated inventory is the difference between an orderly migration and a last-minute outage.

Natural-language diagnostics for Fabric Data Warehouse via a bounded read-only skill (GA)

This continues last week's operations thread (capacity telemetry and runbook-friendly guidance) with a generally available “SQL DW operations skill” aimed at diagnostics through natural-language interfaces, including tooling like GitHub Copilot CLI. The capability is explicitly bounded and read-only, and it can correlate signals from Query Insights with Fabric Capacity Metrics to help explain workload slowdowns without giving an assistant the ability to mutate warehouse state.

For developers on call for data warehouse performance, this is a new interface to existing telemetry rather than a new telemetry source. The practical value is faster triage: instead of jumping between separate dashboards, you can query the operational view in a constrained way and then decide what to change in code, indexes, or capacity planning.

Inference performance and infrastructure signals

Azure published MLPerf Inference v6.1 results for DeepSeek-R1, benchmarking across Interactive, Server, and Offline scenarios on NVIDIA GB300 and GB200 NVL72 systems. The submission includes both 18-node and 72-node configurations, which helps teams reason about scaling characteristics rather than treating performance as a single number.

For ML engineers and platform owners, MLPerf remains one of the few comparable signals across vendors, and it complements last week's storage-focused MLPerf discussion (Azure Managed Lustre) by rounding out the infrastructure picture from checkpoint-heavy training to production inference. If you are planning large MoE (Mixture-of-Experts) deployments, these results provide a data point for what Azure is targeting with GB200/GB300 class hardware.

Other Machine Learning News

Several smaller platform updates this week focused on governance and day-2 operations for data + AI workflows. Azure Databricks added configurable retention for supported system tables (beta), letting you set st_retention from 30 to 3,650 days via the Databricks Account Settings API, with a grace period when you reduce retention and a planned GA cost model beyond 395 days.

On the integration side, Databricks Genie in Slack can now return rendered chart images (public preview), but existing installations need a reinstall to grant the files:write permission, and the post includes a SQL query to audit Slack-originated Genie requests. Fabric admins also got a safety net: soft delete for standard-mode on-premises data gateways (preview) keeps deleted gateways for 30 days so tenant and gateway admins can restore clusters and members, which aligns with last week's theme of adding operational safeguards (recency signals, policy auditing, and more observable capacity behavior) before issues become outages.

Finally, a Data Exposed episode introduced Rayfin (open-source SDK and CLI) for defining an application backend in code and deploying it into Fabric as a first-class item with inherited identity, governance, and compliance controls. If your org is experimenting with “app-in-Fabric” patterns, this gives a concrete toolchain to evaluate alongside more traditional deployment models.