October 20, 2026Microsoft Fabric, Podcast Episodes, Power BI

Episode 331 – FabCon Europe 2026 Top 10: Fabric IQ, F0, Project Osmos & Fabric Apps

Episode 331 picks up a few exits after Episode 330, recorded October 7th, 2026, as John and Jason roll through Cuba, Missouri past the airstrip, a fudge factory in a town whose name Jason refuses to pronounce the same way twice, and the Jesse James Wax Museum on the way to Steelville. The destination is St. Louis and lunch with a friend of the show. The topic is FabCon & SQLCon Europe, which wrapped the week before. The hosts were busy working and speaking at it, so the two-hour keynote is saved for a future flight. In the meantime they’ve been living in the blogs and announcements, and this is their top ten.

Conference announcements tend to be marketing-heavy, so the goal here is finding the nuggets of realism inside each one. Jason reads. John drives. John is reminded, more than once, to keep his hands on the wheel.

1. Fabric IQ in Microsoft Copilot Chat and Cowork

Fabric IQ is generally available inside Microsoft 365 Copilot Chat and Copilot Cowork, on by default for Fabric and Power BI customers. Business users ask Copilot a question and get answers grounded in governed Power BI semantic models and reports, using the definitions and metrics the organization already trusts, with row-level and object-level security respected. The framing from FabCon Europe: there’s no additional AI token cost for Copilot customers, which shifts the question from “should we adopt it?” to “is our semantic layer ready for the questions people will ask?”

John reached back to the early days for the comparison: remember Power BI answers through Cortana on Windows? This is that, except it works. Under the hood it behaves like a read-only MCP server over your Power BI content, and the Fabric IQ MCP server is GA in its own right. You don’t need an ontology for this to work; it answers from your semantic models, though an ontology can tighten what things mean in your business.

The hosts had questions, and the docs answer a few. Data agents and ontologies don’t plug into Copilot Chat automatically; they need an explicitly published Microsoft 365 agent. Users need a Microsoft 365 Copilot license plus access to the reports in question. And Power BI Pro, PPU, Premium, and Fabric capacities are all supported, while Embedded A and EM SKUs are not. “No additional token cost” also doesn’t mean no cost anywhere, and the show’s working assumption is that capacity consumption will show up somewhere. The bigger point stands regardless: ask a question of bad data and you get a bad answer, faster. Status: generally available. See Fabric IQ in Microsoft 365 Copilot Chat and Prepare your data for AI.

2. Project Osmos: The Data Engineering Agent

Built on technology from Microsoft’s January acquisition of Osmos (covered in Episode 319), the Fabric data engineering agent takes on long-running work like migrations, schema harmonization, ETL, and performance tuning. Engineers define the outcome and the guardrails; the agent plans the work, runs it on Fabric Spark, and validates the results. The task keeps running in Fabric after your laptop closes. It’s the clearest example yet of Fabric moving from agents that answer questions to agents that do the work.

John’s take is that this is construction, not just observation. He’s been doing similar things outside Fabric with Claude and GitHub Copilot, using the Fabric skills plus the Superpowers skills that wrap development governance around agent work, like making sure everything has tests. Guardrails are what make agents useful and reliable, and here the compute burns your capacity instead of your token budget. He got so animated explaining it that he took both hands off the wheel. Jason is getting him a cape.

Fittingly, Osmos is driven from a local agent (GitHub Copilot CLI, Claude Code, or Codex) through the Skills for Fabric plugin, not from Copilot in the Fabric portal. You review settings for permissions, write safety, rerun behavior, and schema evolution before anything executes. Status: preview. See What is the Fabric data engineering agent (Project Osmos)?

3. On-Demand Billing and the F0 Capacity

The one Jason was most excited about. On-demand billing extends pay-as-you-go consumption across Fabric workloads, so you pay for what actually runs, for as long as it runs, rather than for a capacity sitting powered on. It can mix with provisioned capacity: spiky or occasional jobs bill on demand while steady workloads stay on reserved capacity. The F0 is a zero-provisioned starting point that costs nothing until something runs, a natural fit for dev environments and proofs of concept.

John traced the lineage: this grew out of on-demand billing for Spark, which offloads Spark jobs to serverless compute billed separately. That concept now extends to other workloads like Eventhouse and Eventstream, and taken to its logical conclusion, you get no capacity at all and pay for everything as you use it. Jason, deep in prototyping work these days, sees an immediate use.

The open questions are real, though. Can you cap an F0 at, say, $1,000 a month for a dev environment, or at least get notified at a threshold? Is it something you spin up in Azure, or a new option in the workspace license dialog alongside Pro, PPU, Trial, and Fabric? Is it billed by CU or by workload? And since pay-as-you-go already costs more than reserved, expect on-demand rates to carry a premium too. The show’s read is that this is full of promise and needs serious guardrails before anyone flips it on across a tenant. Encouragingly, Spark on-demand billing already has a maximum CU limit, so a cap isn’t a stretch. Details are still emerging; the hosts will report back.

4. Observability in Fabric

Monitoring gets pulled into one observability story: capacity insights and health signals, workspace monitoring, the Monitoring hub, and Azure Monitor integration. Capacity signals help teams spot throttling and cost pressure early, and the Operations agent can watch those signals, run AI root-cause analysis, and take pre-approved actions when alerts fire.

John was most excited about the monitoring plumbing. A long-standing complaint on the show is that workspace monitoring stood up its own Eventhouse in every workspace, which made cross-workspace reporting painful and, on busy workspaces, kept an always-on Eventhouse chewing capacity in each one. Do the math across dozens of active workspaces on an F64 and it breaks down in a hurry. Now a workspace’s monitoring item can send telemetry to a central Eventhouse in another workspace in the same region, and the docs recommend isolating that central Eventhouse on its own capacity.

Even better, signals can go outside Fabric to Azure Monitor. Using Fabric to monitor Fabric has the status-page problem: when the thing is down, so is the page telling you it’s down. Capacity events can also be routed to you instead of living only in the Capacity Metrics app, which opens up real chargeback. Will customers actually do it? As John put it, just because you should doesn’t mean you can. Status: preview. See What is workspace monitoring? and the recommended monitoring architecture.

5. Policies in Fabric

Attribute-based controls that govern what people can do across the tenant: only data engineers can create notebooks on this capacity, only data stewards can share externally to approved domains, and so on. The keynote demo tied it together, with a capacity alert surfacing in Teams, the offending notebook identified, and a policy applied to block it going forward. Proactive governance instead of cleanup.

Jason is thrilled to finally say “this group can do this, that group can do that” and head off spreadmart sprawl before it starts. John’s summary: finally, real governance in Fabric outside the main admin portal. Policies live as Fabric items with Git and CI/CD support, don’t consume CUs, and currently cover item creation (capacity scope), external data sharing, and workspace settings editing (tenant scope). Region note: not yet available in West Europe, North Europe, or West US capacities. Status: preview. See What are Microsoft Fabric policies?

6. IQ Sharing in OneLake

Share live, governed data with another organization using an email address and an expiry date. Beyond tables and files, a share can include agent instructions and ontologies, the context that makes the data usable by an agent on the other side. No copies, and access can be revoked instantly. Jason’s reading: grant a partner time-boxed access, they point their own agent (Claude, say) at it over MCP, and they can ask questions of your data without it ever leaving your tenant.

John likes it a lot from the vendor side, especially the time-bomb nature, because it gives customers the confidence to expose data for a quick analysis. His caveat: make sure your data is in shape before you share it. This builds on Fabric’s existing external data sharing, which shares read-only via a shortcut in the consumer’s tenant. And yes, that was John’s Star Trek communicator ringtone you heard. He did not answer it.

7. The Database Hub Arrives

First teased back in Episode 324, the Database Hub is a single control plane for databases across Azure SQL, SQL Server (including Arc-enabled and Azure VMs), Azure Database for PostgreSQL, and Azure Cosmos DB alongside SQL database in Fabric. It’s positioned as an agentic control plane: one view and one management layer across a mixed estate, part of the broader FabCon and SQLCon theme of unifying operational databases and analytics.

Jason expected a new hub on the left rail next to Monitoring and OneLake; instead it lives under databases. He wants exactly this: his Azure SQL databases in the same place he does his heavy Fabric transformation work before pushing results back to the authoritative source. John wants Eventhouse in there. It is a database, after all. (“Not if you call it Azure Data Explorer.” “But I don’t.”) Current preview limits: inventory and monitoring depth vary by engine, and Fabric capacities in North and West Europe aren’t supported for the experience yet. Status: preview. See What is the Database Hub?

8. PBIP and PBIR Are Now the Default

Power BI’s developer mode grows up. PBIR, the enhanced report format, is now the default, and reports on the legacy format convert automatically when edited. Paired with Power BI Projects, reports save as folders of readable, source-controllable files, so Git diffs, merges, and code reviews work on report changes, not just models. The tenant opt-in goes away, no user action is required, and PBIX remains fully supported. It’s a good moment to refresh your CI/CD and governance guidance.

The hosts presented on exactly this the day before recording, so this one got a cheer. Worth knowing: Power BI keeps a backup before converting (30 days in Desktop, 28 days in the service, with a Restore as PBIR-Legacy option in report settings). The hosts have had it turned on so long they can’t say what a clean install looks like anymore. Status: generally available, rolling out. See PBIR format.

9 & 10. Fabric Apps GA and Agentic App Creation in Power BI Desktop

Fabric apps, the grown-up name for Project Rayfin, are generally available and picked up Postgres support, TypeScript backend functions, a secret store that keeps credentials out of app code, and direct connections to a warehouse. Jason wants to know where that secret store lives and whether Key Vault plays a part, but he’s glad secrets are handled by default, since agent-generated code rarely thinks about that up front. Microsoft is positioning Fabric apps as a primary way to build analytics applications going forward.

John jumped ahead to item ten because it’s the bigger news: agentic app creation inside Power BI Desktop. Describe the app in natural language, Power BI builds it on your semantic model with a live preview, apps can include write-back, and finished apps publish to Fabric. It’s available to Power BI Pro and Premium Per User, not just capacity-backed workspaces, and the FabCon Europe messaging included a Fabric database with 1 GB of storage per app for Pro users. That implies a grow-up story once an app outgrows a gig, and leaves open how many apps a Pro user can create.

On write-back, John’s advice: if you’ve been jamming Power Apps into Power BI reports to get write-back, you can pretty much stop. Translytical task flows remain the more flexible option for writing to other destinations, while this path writes to a Fabric database. And writing straight to SQL beats Dataverse, which, as longtime listeners of Episode 329 know, is not a high bar on this show.

Jason sees the upside clearly: regular people building working code that an architect can then take and turn into a real, scalable application. A gateway drug, in the best sense. For prototyping it’s amazing. Whether end users can build something long-term, sustainable, and trustworthy with enough guardrails is the open question on the show, the same one that’s always hung over Power Apps as an enterprise platform. John’s closing word: the tech is certainly there, so let’s see what happens. Status: Fabric apps are GA; agentic app creation in Power BI Desktop is preview, rolling out in the coming weeks. See Fabric Apps overview and Power BI data in Fabric Apps.

Up Next

The hosts are watching the full keynote over the next few days and expect to come back with deeper dives, and the October feature summaries should land shortly with even more to unpack. The plan, as always: record more often. For the bigger picture from the last FabCon, revisit the FabCon Atlanta 2026 keynote recap in Episode 322.

Links

Documentation

Previous Episodes

Subscribe: SoundCloud | Apple Podcasts | Spotify | TuneIn | Amazon Music

Tags: Azure Monitor, Copilot Cowork, data engineering agent, Database Hub, external data sharing, F0, FabCon 2026, FabCon Europe, Fabric apps, Fabric IQ, Fabric policies, Governance, MCP, Microsoft 365 Copilot, Microsoft Fabric, observability, on-demand billing, OneLake sharing, PBIP, PBIR, Power BI, Project Osmos, Rayfin, source control, SQLCon, translytical task flows, workspace monitoring, write-back