Production-grade Fabric data agents: moving from Demo to Dependable
Getting a Fabric data agent to work in a demo is one thing. Supporting it once people depend on it is another. Using the Lakeshore Retail demo, this guide covers the practical work behind that transition: reliable data, ontology context, secure access, performance testing, guardrails, and day-two operations. Tutorial data - Lakeshore Retail. The inventory is a CSV reference, not an agent answer; benchmarks are proposed, not measured. 1. Define the service before tuning the prompt Start with verifiable questions: inventory below safety stock, inbound shipments, governed sales measures, and refrigeration readings over a defined window. Agree on definitions, units, time zone, snapshot selection, freshness, and an answer owner. Low stock is not a shortage forecast. Two high-temperature readings do not prove a continuous breach: cadence, gaps, quality, and boundaries matter. Store-level relationships do not identify which product occupied a refrigeration unit. Put durable calculations in governed measures, SQL, or KQL. Ordering and other write actions need separate authorization and approval. Figure 1. Reference design; guardrails do not replace authorization. Use the standard runtime for production. Ontology, preview runtime, Foundry integrations/agent guardrails, evaluation SDK, and data-agent source control have separate preview considerations. The core's GA status does not extend to every dependency. 2. Use ontology for meaning, not as a security boundary LakeshoreOntology is now attached to the LakeshoreDataAgent draft, with Standard selected. It supplies entities, relationships, and mappings. SQL, KQL, or DAX executes against underlying sources under user permissions. Figure 2. Tutorial ontology, not proof of query correctness. The integration is preview. Attachment here does not confirm a service-wide fix to the documented new-experience issue. Keep shared definitions in the ontology. Explicitly mount eligible underlying sources before adding source-specific instructions, descriptions, or examples. These settings do not write back to the ontology. 3. Establish one reference answer For the fixed 2026-08-28T18:50:00Z snapshot, select positions where: LocationType = STORE StorageClass = FROZEN OnHandQuantity < SafetyStockQuantity The 48-position inventory fixture has exactly three matches, all Vanilla Bean Ice Cream (P-FRZ-001): Figure 3. A calculation from tutorial files, not a live agent result. For test INV-001, assert exact Store/Product keys, count, quantities, filters, and timestamp, not just three city names. The fixture's InventoryStatus = 1 marks low stock; sample instructions call it healthy. Resolve this first; the reference uses quantities. Do not silently alter data or treat August as current. 4. Prepare and wire the sources Curate objects without losing keys, joins, dates, or measures. Smaller is not automatically better. Use governed Power BI measures, Prep for AI, and Verified Answers. DAX generation uses model metadata and Prep for AI, not agent instructions. SQL/KQL source instructions/examples are separate. AI scoping and hidden fields are not authorization. Column flags do not narrow a selected source table; use supported model configuration or curated objects, not destructive edits to shared models. In development: Check prerequisites: supported paid F2+/P1+ capacity, tenant settings, and same-region agent/source capacities. Use Sources > Add sources > Add an ontology to attach LakeshoreOntology. Review its entities and Ontology data sources. Mount eligible sources for SQL/KQL configuration; prepare the semantic model separately. Set routing, clarification, and response rules, including units, identifiers, and honest failures. Inspect the fixed inventory question's source, generated query, and result. Publish to a restricted test audience; repeat as real consumers. Figure 4. The supplied attached-source draft. It does not establish query, security, or performance success. Validate the published version; republish runtime changes. Standard does not freeze service-managed LLM upgrades. Model Read permits semantic-model queries; authoring needs broader rights. 5. Benchmark the whole request Schema width and preview runtime are experiments, not guaranteed gains. Measure authentication, planning, query generation, source execution, response generation, and wrapper/guardrail work. Fast engine execution does not establish that capacity will fix conversation latency. Figure 5. Proposed experiments, not benchmark results. Vary one factor before combinations: Import, Direct Lake, and DirectQuery have no universal speed ranking. Filter telemetry early. Advanced DAX value indexing currently needs Q&A enabled. Fix questions, data, identities, and versions. Separate new chats/follow-ups and cold/warm runs; interleave baseline/candidates. Never clear shared production caches for a test. Use approved synthetic load with representative volume, cardinality, skew, joins, and freshness; tutorial data cannot prove sizing. Record sample size, p50/p95, timeouts, failures, throttles, correctness, and resources. Count all attempted eligible requests when reporting correct completion within budget, including timeouts. Leave caching off until permission-aware keys, freshness, expiration, and revocation invalidation are proven. 6. Add Foundry without moving the authorization boundary A prompt/hosted agent can use Fabric for orchestration, safety, and escalation, not repair measures, grant access, or replace Fabric's query-generation model. Use defense in depth: Application: authenticate, allowlist tools/arguments, bound calls/concurrency/deadlines, and validate available structured results. Foundry: supported safety controls and orchestration. Fabric and sources: enforce the identity's permissions. Data/semantic layers: business meaning. Use delegated end-user identity for interactive access; test two differently entitled consumers through the whole route. Never silently use the owner's identity. The Fabric tool and Fabric IQ integration differ; the former requires the same tenant. Deployment-principal support does not establish query-principal support. The public published-agent MCP pattern is: https://api.fabric.microsoft.com/v1/mcp/workspaces/{workspaceId}/dataagents/{dataAgentId}/agent Verify OAuth, consent, and networking; private-link routes may need workspace-specific hosts. Keep tokens out of code/logs. Moderation is route-specific, not automatic for arbitrary MCP bridges or nested calls. Test input, tool calls, retrieved content, and output on your route. Safety approval does not prove accuracy or authorization. For hosted guardrails, prove filtering with negative tests. invocations needs invocations_moderation; invocations_ws has no content-safety moderation. Agent-level groundedness/spotlighting are unsupported. Implement and test any missing required control, or block release. Review Code Interpreter/action tools for isolation, retention, and approval. Exclude preview dependencies if policy requires it. 7. Test behavior, not convincing prose Use approved references and holdouts separate from tuning. Assert numbers, dates, filters, and authorized scope deterministically. Test ambiguity, no data, outages, expired identities, follow-up filters, threshold boundaries, gaps, injection, denied fields, and cross-user isolation. Check totals/errors for disclosures too. Test consumers: workspace Admin, Member, and Contributor bypass RLS. Admin success is not an RLS pass. The conversational cap is 25 rows by 25 columns. Compute totals in the source, not from truncated output; offer an authorized report/export route for complete datasets. The preview evaluation SDK uses question/expected_answer columns and a published target. Review detailed steps alongside assertions. Judge scores cannot override failed access checks. Example targets: all critical cases pass; broader correctness >=95%; no disclosures observed in the negative suite; 95% of attempted eligible requests correct within 30 seconds at five concurrent users. These are proposals, not measurements or guarantees. 8. Release a service someone can operate Figure 6. Proposed release gates, not an existing pipeline. Separate dev/test/prod. Version configurations, ontology/models, AI preparation, examples, policies, code, and evaluations. Data-agent source control is preview. Verify target bindings, permissions, region, and freshness. Publish and smoke-test consumers before expanding access. Practice rollback to a known-good release; it does not necessarily restore data, permissions, tools, or the service-managed model. Regress after service changes. Assign business, data, application, security, and operations owners. Monitor outcomes, p95, throttling, freshness, quality, and cost with correlation IDs/versions. Restrict trace access and retention; never log tokens or unrestricted results. Bound transient retries, honor Retry-After, and never retry denials as outages. Add deadlines, circuit breakers, and escalation. Distinguish no matches, no access, and failed queries. Review compliance/geographic boundaries for Foundry, external services, logs, and exports. Fabric's up-to-28-day history retention does not define external retention. Respect Purview/source policies. AI consumption includes instructions, examples, and history; source queries consume separately. Monitor AI Query and engines, budget Foundry/application costs, and compare cost per correct, authorized answer within target. Require evidence for scope, data quality, published bindings, consumer access, correctness, guardrails, load, rollback, ownership, and honest failures. Missing evidence blocks release. Dependable means useful within scope and supportable when things change.Is Your Semantic Model Ready for Copilot? A Fabric IQ Readiness Guide
For years, the Power BI semantic model had one main job: feed reports and dashboards. That job has changed. With Fabric IQ, your semantic model is becoming the place Microsoft 365 Copilot and your AI agents get their business answers from. If the model is messy, inconsistent or badly documented, Copilot's answers will be too. This guide explains what Fabric IQ is, why it matters, what it costs, and how to get your models ready in about 30 days. What is Fabric IQ? Fabric IQ is the semantic foundation over your structured business data. It is one of the four pillars of Microsoft IQ, was announced at Build 2026, and is now generally available. It brings three things together: your data in OneLake, the business meaning in your Power BI semantic models, and operational intelligence expressed as ontologies. Microsoft IQ is the umbrella. At Build, Microsoft presented it as the context layer that grounds AI agents in both general world knowledge and the organization's own knowledge. Work IQ covers people, emails, meetings and documents. Fabric IQ covers the numbers: revenue, margin, churn, inventory, and every KPI your business runs on. Medium Why this changes how people use data The biggest change is where people get their data answers. Instead of logging into Power BI to check a metric, business users can ask Copilot in Teams or Outlook a question in plain language and get an answer. Importantly, those answers come from your Power BI semantic models with existing row-level security and sensitivity labels applied. The reach keeps growing. Fabric IQ is integrated with Microsoft Agent 365 as a first-party MCP tool (in preview), and it is also extending into Microsoft 365 Copilot, including Cowork and Copilot Chat. Developers get it too: through Agent Skills for Fabric, Fabric IQ tools are available in GitHub Copilot CLI, so teams can query Power BI reports and semantic models from the command line. Microsoft Azure Put simply, one semantic model now answers questions in reports, in Teams, in Outlook, in custom agents and in the terminal. That is powerful when the model is good and risky when it isn't. This is Microsoft's stated direction, not a side feature. In a July 21, 2026 post on the Fabric Updates Blog about the future of conversational analytics, Microsoft described trusted business context in Fabric IQ that can be used consistently across Microsoft 365, Fabric, developer tools and future AI applications. The catch: reports have been hiding your model's gaps This is the point most teams miss. Fabric IQ skips the visualization layer and queries the model directly, so the model has to work on its own, outside the filter context of any specific report page. Think about how many of your reports quietly fix problems in the model: A page-level filter excludes test customers or cancelled orders A slicer defaults to "current fiscal year," so nobody notices the measure has no time logic A visual title explains what "Net Revenue" actually means Hidden columns and awkward field names only work because report authors know which ones to use When Copilot queries the model directly, none of those fixes apply. A user asks, "What was net revenue last quarter?" and gets a number that includes test data, the wrong calendar, or a measure nobody has used since 2023. Licensing: what you actually need You pay for this in two places: Microsoft 365 side: you need Microsoft 365 Copilot licenses to use Fabric IQ through Teams and Outlook. Fabric side: Fabric IQ grounding doesn't consume extra Fabric capacity from the Microsoft 365 side, but everything Fabric IQ grounds on still needs F-SKU capacity. For budgeting, this means heavier Copilot use doesn't directly raise your Fabric capacity bill for the grounding itself. You still need your models hosted on proper Fabric capacity, sized for the query load that conversational use brings. The 10-point readiness checklist Use this to review each semantic model before you expose it to Copilot. Clear business names. Rename tables, columns and measures in business language. fct_sls_amt_net should become Net Sales Amount. Copilot and your users both work better with plain names. Descriptions on everything that matters. Add descriptions to key tables, columns and measures. Say what each one means, what it includes and excludes, and the unit. This is the model's documentation for AI. One definition per metric. If you have Revenue, Revenue v2, Revenue (Finance) and Rev_Final, Copilot has to guess. Merge them into one certified measure and hide or remove the rest. Move report-level logic into the model. Any filter that must always apply, such as excluding test accounts or internal transactions, belongs in the model (in measures, RLS or the data itself), not on a report page. A proper date table. Mark it as a date table, include fiscal periods if your business uses them, and make sure time-intelligence measures work without a slicer. Hide the plumbing. Hide keys, technical columns, staging fields and helper measures. What stays visible is what Copilot considers fair game. Validate row-level security. Answers respect RLS, which is good. So test RLS properly with real user roles. A gap in RLS is now a gap in every Copilot conversation. Apply sensitivity labels. Label models that contain confidential or personal data so Microsoft's information-protection controls carry through to AI answers. Write AI instructions and version them. "Prep for AI" instructions are written on the semantic model, version-controlled with the model, and now shape Copilot's behaviour everywhere it grounds on that model. Use them to explain business rules, preferred measures and common terms (for example, "'customers' means active customers unless stated otherwise"). Test with real questions. Collect 20 to 30 questions your business users actually ask. Run them through Copilot and compare the answers with your certified reports. Fix any mismatch in the model, not in the report. A 30-day readiness plan Week 1: Inventory and prioritize. List your semantic models and choose two or three high-value, widely used ones, such as sales, finance or operations. Find each model's owner, check its current certification status, and identify which users will get Copilot access first. Week 2: Clean up the model. Work through checklist items 1 to 6: naming, descriptions, one version of each metric, moving report logic into the model, the date table, and hiding technical fields. This week delivers the biggest improvement in answer quality. Week 3: Security and AI instructions. Validate RLS against real roles, apply sensitivity labels, and write your first set of AI instructions. Put the model in source control (Fabric Git integration) if it isn't already, so instructions and changes are tracked. Week 4: Test, pilot and set up governance. Run your question set, fix the mismatches, then pilot with a small group of business users. Agree who owns each model, how changes get approved, and how users report a wrong answer. Governance: treat semantic models like products Once Copilot answers from your models, they are shared business infrastructure, no longer just a BI team's side project. A few habits help: Named owners for every model exposed to Copilot Certification so only reviewed models become the preferred sources Change control through Git and deployment pipelines, because a renamed measure can change hundreds of Copilot answers overnight Feedback loops so a wrong answer becomes a model fix within days, not months The bottom line Fabric IQ changes what a good semantic model is. It used to be a model that powered good reports. Now it has to answer business questions correctly on its own, in any tool, for anyone with permission to ask. Teams that clean up names, fix metric definitions, move logic into the model and write AI instructions now will have Copilot answers people trust. Teams that don't will spend 2027 explaining why Copilot and the dashboard disagree. Start with one model this month. The checklist above is enough to begin.🚀 Connecting AI Agents to Microsoft Fabric: MCP Servers
Ever wanted your AI agent to interact with Microsoft Fabric using plain English? That’s exactly what Model Context Protocol (MCP) servers enable. What is MCP? MCP is an open standard that gives AI agents a secure, unified way to access data and services—eliminating fragile custom integrations. It brings structured operations, discoverable capabilities, and a secure-by-design approach. Two MCP servers, different needs: 🔹Fabric Core MCP Server (remote) No setup required. API-based access with OAuth 2.0—ideal for quick, governed access to Fabric. 🔹Fabric MCP Server (local) Open-source and developer-friendly. Provides API docs and local file system access—great for hands-on development. Why it matters These capabilities allow teams to interact with Fabric naturally using AI—accelerating productivity from prototyping to production. 🔒Security remains key, with support for authentication and role-based access control. Whether you want speed or control, there’s an MCP server for your workflow. 👉Which approach works best for you—remote for simplicity, or local for flexibility? #MicrosoftFabric #AI #MCP #DataEngineering #ModelContextProtocol #AgenticAI #Microsoft Reference: https://learn.microsoft.com/en-us/rest/api/fabric/articles/mcp-servers/what-is-fabric-mcp-server Connect : www.linkedin.com/in/amish-s-sinha-582b0392 https://amishssinha.substack.com/ https://amishssinha.lovable.app/MCP vs. Plugins vs. Skills for Agents: The Path to Native Agentic AI Development
🚀MCP vs. Plugins vs. Skills for Agents: The Path to Native Agentic AI Development Every truly useful AI agent must go beyond its training data. To be effective in the real world, an agent needs to call APIs, query databases, operate infrastructure, understand domain‑specific workflows, and adhere to organizational standards and guardrails. The question is no longer whether agents should be extensible—it’s how that extensibility should be designed. By 2026, three distinct extensibility models have crystallized across the agentic AI ecosystem: Model Context Protocol (MCP) — a universal, open protocol that connects agents to external tools, services, and data sources Plugins — installable, distributable packages that bundle tools, instructions, configurations, and sometimes sub‑agents AI Skills — structured, reusable prompt artifacts that encode domain expertise and guide how agents reason, decide, and act These models are often discussed as if they compete with one another. They don’t. Each operates at a different layer of the agent stack, and the most capable agent architectures intentionally combine all three. The problem is that their roles are frequently misunderstood, which leads to poor design decisions, fragile agents, and unnecessary complexity. In this post, I’ll break down what each model actually does, where it fits in the architecture, and how to compose MCPs, Plugins, and Skills into a cohesive, production‑ready agentic system—one that scales across teams, tools, and environments. Blog :https://github.com/AmishSinhaMS/mcp-vs-plugins-vs-skills #mcp #plugins #extensibility #aiagents #githubcopilot #agentic-ai model-#context-protocol #ai-skills #microsoft-foundry #Skills for Fabric #Microsoft Fabric #CLI Connect : www.linkedin.com/in/amish-s-sinha-582b0392 https://amishssinha.substack.com/ https://amishssinha.lovable.app/Demystifying Microsoft’s AI Strategy: Work IQ, Fabric IQ, Foundry IQ, and More
With terms like Work IQ, Fabric IQ, Foundry IQ, Agent 365, and Copilot Studio flying around, it’s easy to get lost in the noise. However, there is a clear architecture behind it all. 🔹Work IQ → User context (how people collaborate) 🔹Fabric IQ → Data context (structured business data) 🔹Foundry IQ → Knowledge context (enterprise policies & intelligence) These aren’t products—they’re architectural layers that make AI useful at enterprise scale.Unifying Data into Intelligence: A Hands‑On Walk Through Microsoft Fabric IQ
If you’ve ever felt buried in fragmented datasets and mismatched schemas, my latest post on Microsoft Fabric IQ might be your cup of tea. I walk through how I coaxed Fabric’s new Ontology item into weaving store sales, product catalogs and freezer telemetry into a single, live business graph—complete with a hands‑on setup guide and runnable code. It’s a mix of practical steps, personal missteps and a few laughs, all in an approachable 10‑minute read. Check it out to see how Fabric’s semantic layer can turn chaos into clarity
