Microsoft Fabric IQ · Strategic Service Provider Plan

Becoming the Leading Fabric
Semantic Intelligence Partner

Technology advantage, delivery readiness, market positioning, and competitive differentiation — the complete strategic plan for Microsoft Fabric IQ leadership in 2027.

Updated: October 2026 Source: FabCon Barcelona · Build 2026 · 35 signals Focus: Fabric IQ · Ontology · Data Agents · Ossie GA target: Q1 2027 · Old experience retires Jan 31

35 signals indexed

| Last updated: October 2026 | FabCon Barcelona · Build 2026 · 17 Microsoft Learn docs Current

Executive Summary

Three things that changed at FabCon Barcelona

1. Fabric IQ is in M365 Copilot — GA

Business context from Fabric semantic models now grounds Copilot Chat and Cowork at zero extra AI token cost. This is no longer a preview — it's live for every M365 Copilot customer with Fabric. 22M+ Power BI semantic models are candidates for this integration today.

2. Ontology + Agents: six consumption paths

Every Fabric IQ Ontology item now exposes six integration paths: Ontology Agent, Data Agent, Operations Agent, Foundry IQ Agent (Azure AI Foundry), Copilot Studio, and a live MCP server endpoint. Any MCP-compatible client — Claude, GPT-4.1, Gemini 2.5 Pro — can query a governed Fabric ontology without writing integration code.

3. Apache Ossie: the semantic layer goes open

Microsoft co-founded Apache Ossie — a vendor-neutral semantic interchange standard. One Ossie document can define a semantic model deployed simultaneously to Snowflake Semantic Views AND Power BI. The semantic layer is becoming infrastructure, not proprietary capability.

Microsoft IQ (Sept 25, 2026): Fabric IQ is now a component of the broader enterprise intelligence brand "Microsoft IQ" — extending to ground Copilot Chat, Dynamics 365, and Power Platform. The FabCon Barcelona keynote title: "The Data Foundation for AI".

Architecture

The Fabric Semantic Stack — five layers

Each layer builds on the one below. Existing Power BI and OneLake investments stay valid; Ontology and agents ride on top.

Agents & Copilot Data Agent GA Others Preview

Consumers of semantic context — Data Agent, Operations Agent, Data Engineering Agent, M365 Copilot, Agentic Apps. All read from L3/L4, not raw tables.

↑

Fabric IQ Ontology Preview → GA imminently

Business entity graph — Customer, Product, Order, Machine — with properties, relationships, natural-language rules, metrics (DAX proxy), namespaces, inheritance, graph execution. Extends L3 semantics into real-time and operational scenarios.

↑

Fabric IQ — Unified Context Layer GA

Combines OneLake + Power BI semantic models + Ontology + Real-Time Intelligence. Powers M365 Copilot (GA, zero extra token cost). IQ Sharing (Preview) distributes governed context across workspaces as tables, files, agent instructions, and RDF ontologies.

↑

Power BI Semantic Models GA · 22M+ daily

The world's most widely adopted semantic layer. DAX measures, certified metrics, RLS/OLS, relationships. NL2DAX GA: +3.0% accuracy, −48% P50 latency. Agentic Apps (Preview): describe → generate → publish from semantic models.

↑

OneLake + Eventhouse + Databases GA

Unified multi-cloud data lake. Sources: Lakehouses, Warehouses, KQL/Eventhouse, SQL Database, mirrored databases (BigQuery GA, Salesforce Data Cloud Preview), shortcuts, views, materialized views.

Deep Dive

Fabric IQ Ontology — what it actually is

The Ontology item is a machine-understandable business model stored inside Fabric IQ. Not a data store — a virtual semantic and context layer over existing sources.

Critical distinction: Source data stays where it is (Lakehouse, Eventhouse, Warehouse, semantic model). Ontology holds the definitions and mappings only. No data duplication.

Core Modeling Concepts

Entity Type — reusable business concept (Customer, Machine, Shipment)
Property — named characteristic with data type + source mapping
Relationship — "Customer places Order" — explicit and reusable
Metric — governed DAX proxy from source semantic model
Rule — natural-language business logic (NL only, not executed)
Namespace — domain scoping for large multi-team models

Supported Data Bindings

Power BI Semantic Models — DAX stays in source; metrics proxied, not copied
Lakehouses, Warehouses, SQL Databases
Eventhouses (KQL — real-time + historical)
Mirrored Databases
OneLake shortcuts, views, materialized views
Graph: delta tables from lakehouses/mirrored DBs only — semantic model and KQL sources not supported

Ontology Agent Preview

Plan mode (default): discover, draft, validate, query — zero changes applied
Act mode: applies proposals after confirmation
Attach files as context (10 files max, 5MB each): data dictionaries, business glossaries
Queries: DAX (200 rows), KQL/SQL/GQL (1,000 rows)
24-hour conversation limit; 2-day data retention
Multi-model: use Act mode to combine multiple semantic models; agent resolves entity conflicts

Governance & Lifecycle

Fabric workspace permissions govern access
OneLake security + source RLS/OLS/CLS respected
Git integration for version control of definitions
Deployment pipelines: dev → staging → production
Programmatic access + CI/CD support
Named version history with restore

New in 2026 Experience

Keyless entity types and join-free relationships
Type hierarchies and inheritance (single-parent)
Shared properties across entity types
DAX measures as metrics (proxy, not copy)
RDF/Turtle/OWL import-export (Ossie alignment)
Calculated columns included in semantic model import

Migration: Old → New Experience

Old experience: no new items can be created (deprecated)
Old experience retires Jan 31, 2027
In-product "create copy in new experience" action available
Preserves entity types, properties, bindings, relationships
Must manually reconnect agents, dashboards, integrations
Activator rules must be recreated separately

Implementation Guide

Building an Ontology — technical anatomy

Creation flow

Generate Ontology from Power BI semantic model ribbon — requires Read and Build permissions
Fabric creates entity types (tables), properties (columns), relationships, metrics (DAX measures)
Post-generation: bind time-series/real-time data; define entity type keys; add descriptions, synonyms, KV metadata; name relationship types
Add natural-language business rules (e.g. "Frozen product safety stock is 200 units")
Optionally enable Graph for multi-hop traversal (lakehouse delta tables only)
Validate → publish → Git → deploy via pipelines

Metrics: proxy, not copy

Ontology stores a link to the source DAX measure, not the expression
Edit metric description in ontology: stays in ontology, doesn't change the semantic model
Metrics do not auto-update when source DAX changes — manual refresh required
"Resolve underlying DAX" requires Write permission on the source semantic model

Rules: governance layer only

Natural language only — the ontology does not execute rules against data
Retrieved by agents via MCP tool list_ontology_rules
Rule metadata: category, region, policyFamily, owner (key-value pairs)
Activator integration not available in new experience — configure separately

MCP Server + Foundry IQ

Live endpoint: api.fabric.microsoft.com/v1/mcp/dataPlane/workspaces/…/ontologyEndpoint
VS Code setup: add to mcp.json; user identity auth (Service Principal not yet supported)
Confirmed orchestrators: Claude Sonnet 4.5, GPT-5, GPT-4.1, Gemini 2.5 Pro
Foundry IQ: add "Fabric IQ" knowledge source in Azure AI Foundry; requires Azure AI Search with Search Index Data Contributor role

Reference architecture — Lakeshore Retail

Lakehouse CSV + Eventhouse KQL + Power BI semantic model bound into one ontology
Entities: Store, Product (Frozen Product, Perishable Product), Inventory, Refrigeration Unit, Refrigeration Telemetry, Shipment, Sale, Supplier, Location
Query enabled: "Which high-priority stores in the West have frozen products below safety stock, a refrigeration exception, AND on-shelf availability below target?"
BFSI analogue: replace refrigeration with LCR threshold, safety stock with minimum liquidity buffer, shipment with collateral position

Known limitations (Oct 2026)

Querying parent entity to return inheriting-entity instances: not yet working
Business rules not currently considered in agent responses (though MCP-retrievable)
Graph does not support semantic model or Eventhouse sources
Service Principal auth on MCP Server not yet supported
No CMK (Customer-Managed Keys) for Ontology Agent data retention

Ontology Integration Patterns

Six ways to consume an Ontology

Every Ontology item exposes six distinct agent integration paths. This is the full architecture for building services on top of ontology.

Path	Best for	Primary audience	Status
Ontology Agent	Creating, testing, improving — Plan/Act mode. DAX/KQL/SQL/GQL queries inside the Ontology item.	Ontology authors	Preview
Fabric Data Agent	Conversational Q&A over governed Fabric data — up to 5 data sources including Ontology.	Business users, analysts	GA (agent); Preview (ontology source)
Fabric Operations Agent	Real-time monitoring against business goals; 5-min rule evaluation; Teams notifications + actions.	Operations teams	Preview
Foundry IQ Agent	"Fabric IQ" knowledge source in Azure AI Foundry; custom agents with full tool calling + enterprise system integration.	Developers	Preview
Copilot Studio Agent	Low-code conversational agents grounded in Ontology via Fabric IQ MCP tool.	Business makers	Preview
Custom MCP Client	Live MCP endpoint — Claude Code, VS Code, GPT-4.1, Gemini 2.5 Pro, any MCP client. Zero integration code.	Any MCP-compatible AI	Preview

The MCP server changes everything for regulated clients. Enterprises that cannot use Microsoft LLMs (DORA, FCA, SEC restrictions) can still ground their own model deployment — Claude, GPT-4.1, or Gemini — in governed Fabric business context through the MCP endpoint. No integration code. Just identity and endpoint configuration.

Agent Landscape

The Fabric Agent Catalog — October 2026

+12.1%NL2SQL accuracy

−30%P95 latency

+3.0%NL2DAX accuracy

−48%NL2DAX P50 latency

1Mchars per SQL topic

5max data sources

Data Agent

Conversational Q&A over governed OneLake data
Sources: Lakehouse (NL2SQL), Warehouse, Semantic Model (NL2DAX), KQL/Eventhouse (NL2KQL), Ontology, Microsoft Graph
6-layer context engineering: instructions → descriptions → schema → data source rules → example queries → topics
Integrates with M365 Copilot, Copilot Studio, Azure AI Foundry, Teams
Read-only; Purview DLP + access restriction enforced

Operations Agent

Preview

Real-time operational monitoring + actionable decisions
Sources: Eventhouse KQL, Ontology
Rule evaluation every 5 minutes; state and transition conditions
Teams notifications + pre-approved action execution
Microsoft Entra Agent ID — first-class governable identity

Data Engineering Agent

Preview

Built on Osmos acquisition (Jan 2026)
Autonomous migrations, lakehouse modernisation, ETL, perf optimisation
Human-in-the-loop oversight model
Direct challenge to manual migration delivery work

Power BI Agentic Apps

Preview

Natural language → data application from a semantic model
Generate, preview, edit, publish — no blank canvas
Announced at FabCon Barcelona; "coming weeks" from announcement

Data Agent Creator Agent

Preview

AI-assisted Data Agent setup (SQL and Eventhouse only in preview)
Schema exploration, query history mining
Auto-generates: instructions, data source descriptions, few-shot examples
Proposal-first: suggests → user accepts → applies

Fabric IQ in M365 Copilot

Grounds Copilot Chat + Cowork in Fabric business context
No additional AI token cost
IQ Sharing (Preview): distribute context + ontologies across workspaces
Copilot Code + Fabric IQ: arriving via Frontier program
Dynamics 365 + Power Platform data in Copilot: public preview Oct 2026

Context Engineering is the new semantic modelling. The 6-layer context model for Data Agents is complex enough to be a consulting discipline. NL2SQL accuracy improvements (+12.1%) come almost entirely from richer context, not model upgrades. This is where service firms differentiate.

Open Standards

Apache Ossie — the cross-platform semantic bet

What is Apache Ossie?

Open, vendor-neutral spec for exchanging semantic models
Datasets, fields, relationships, metrics — JSON/YAML serialisation
Entered Apache Incubator July 10, 2026
Co-founded by Microsoft and Snowflake
Goal: analytics + AI + BI platform interoperability

Microsoft's specific commitments

Establish DAX as an Ossie-recognised query language
Extend Ossie support for Ontologies (beyond basic semantic models)
One Ossie doc → Snowflake Semantic View + Power BI semantic model
Semantic Views in OneLake (early look): governed metrics in OneLake, reusable cross-platform

Why this matters for IT Services firms: Ossie breaks the assumption that semantic layer = Power BI only. BFSI clients co-existing on Snowflake and Fabric can define business metrics once and deploy across both. The tooling is nascent and the guidance vacuum is large — early mover advantage is significant.

Readiness Matrix

GA / Preview status — October 2026

Feature	Status	Notes
Fabric IQ (overall platform)	GA	Announced GA at Build 2026
Fabric IQ in M365 Copilot	GA	Zero extra AI token cost; FabCon Barcelona
Data Agent	GA	Supports Ontology as data source; F2+ capacity
Fabric IQ Ontology (new experience)	Preview	Docs updated Oct 6 2026; GA "in coming months" per Build 2026
Fabric IQ Ontology (old experience)	Retiring Jan 31, 2027	Cannot create new items; migrate now
Ontology Agent	Preview	Plan/Act modes; 24h conversation; 2-day data retention
Ontology MCP Server	Preview	Live endpoint per ontology item; Service Principal not yet supported
Foundry IQ Agent	Preview	Requires Azure AI Search with Search Index Data Contributor role
Operations Agent	Preview	5-min rule evaluation; Entra Agent ID; Teams notifications
Data Engineering Agent (Project Osmosis)	Preview	Built on Osmos (acquired Jan 2026); autonomous ETL/migrations
Power BI Agentic Apps	GA	NL → app from semantic model; agentic developer experiences confirmed GA Sept 2026
Data Agent Creator Agent	Preview	SQL and Eventhouse only; AI-assisted setup
IQ Sharing	Preview	Distributes governed context + RDF ontologies across workspaces
Graph Execution on Ontology	Preview	Optional; delta tables from lakehouse/mirrored DB only; no KQL/semantic model sources
Semantic Views in OneLake	Early Look	Governed metrics in OneLake, cross-platform reuse
Apache Ossie Integration	Early Look	Import/export JSON/YAML; DAX as Ossie query language — roadmap
Google BigQuery Mirroring	GA	Announced FabCon Barcelona
Salesforce Data Cloud 360	Preview	Announced FabCon Barcelona
Microsoft IQ (broader platform)	GA (Fabric IQ component)	Fabric IQ inside enterprise-wide Microsoft IQ — Dynamics 365, Power Platform, M365 in Copilot
Copilot Code + Fabric IQ	Frontier Program	Code-first Copilot grounded in Fabric semantic context; Sept 25, 2026
Dynamics 365 + Power Platform in Copilot	Preview (Oct 2026)	CRM and workflow data in Copilot
Microsoft Purview DLP in Fabric Warehouse	GA	Governs what Data Agents can surface
Purview Access Restriction (KQL/SQL/Warehouse)	Preview	Agent governance; sensitivity label enforcement
Notebook Agentic Toolkit	Preview	Python notebooks with built-in agentic loops for Fabric development; Sept 2026
Claude Code in Fabric DE VS Code	Preview	Native Claude Code + Codex integration in Fabric Data Engineering VS Code extension; Sept 2026
Business Events (Real-Time Intelligence)	GA	Event-driven triggers for Operations Agent patterns; Sept 2026
SQL DW Operations Skill	GA	NL warehouse diagnostics — storage, perf, locks; Sept 2026
Remote Power BI Authoring MCP Server	Preview	External MCP server for remote semantic model authoring; Power BI Sept 2026
Per-Semantic-Model Copilot Access Control	GA	Owner decides whether agents/Copilot can read the model; enabled by default; Power BI Sept 2026

Sources reviewed (35)

Strategic Context

2027 — The Year of Pilots and Proofs of Concept

The engineering teams that enter 2027 with a context engineering capability — semantic layers built, domain-specific synthetic data ready, ontology expertise in place — will run meaningful pilots from day one. Those that don't will deliver fast-generated code feeding semantically unprepared agents. 2027 is also the year engineering delivery shifts its primary output: from pipelines and dashboards to governed semantic context layers that agents can reason against. The roadmap below is the minimum plan to be ready.

Delivery Planning

What the delivery team does in the next 15 months

Five quarters, five modes: Foundation → Operationalise → Expand → Scale → Mature. Each quarter has a forcing function, a forcing deadline, and specific deliverables. This is not aspirational — it is the minimum viable plan to be credible in this space by end of 2027.

Burning deadline right now: Fabric IQ Ontology old experience retires January 31, 2027. Any client on the old experience needs a migration conversation started this week. This is a sales trigger and a delivery commitment simultaneously.

How each quarter maps to the commercial gate structure — see Market tab for the full flow

Q4 2026 · Foundation

Sprint Ready

Pre-Sprint

Q1 2027 · Operationalise

Sprint → Gate 1

Evidence

Q2 2027 · Expand

Gate 2 → Context Build

Budget Approved

Q3 2027 · Scale

Gate 3 → Live

Agent Accepted

Q4 2027 · Mature

Recurring Revenue

CLaaS / Managed

Q4 2026

Foundation

Oct – Dec 2026

Certify architects on Fabric Analytics Engineer; complete all 17 official Ontology docs (done for this brief)

Internal PoC: build one Ontology item from an existing Power BI semantic model — use domain-specific synthetic data to represent entities accurately without real customer data

Deploy a Data Agent on internal data using the full 6-layer context engineering model — document the methodology

Package the assessment: define scope, deliverables, and price for the Semantic Readiness Assessment; soft-launch with one existing account

Identify migration candidates: any client on old Ontology experience — initiate conversation now

⚠ Jan 31 deadline in 90 days

Q1 2027

Operationalise

Jan – Mar 2027

Complete old-to-new Ontology migrations for all clients before Jan 31

Deliver first paid Semantic Readiness Assessment — produce gap analysis + roadmap deliverable; this funds the next SOW

First production Data Agent deployment with a client — 6-layer context engineering in a real governance framework

Operations Agent pilot: a pilot client from a domain with deep expertise, one focused use case — e.g. liquidity threshold monitoring, clinical alert escalation, or energy grid anomaly detection

Multi-model Ontology: build first ontology combining 2+ semantic models using Ontology Agent Act mode — document the entity-conflict resolution process

Watch for: Ontology GA announcement — removes "Preview" caveat from all client conversations

Q2 2027

Expand

Apr – Jun 2027

MCP integration delivery: connect a client's Claude or GPT-4.1 deployment to their Fabric Ontology via MCP — the "bring your own LLM" pattern for regulated BFSI

Foundry IQ Agent: build first custom agent in Azure AI Foundry grounded in Ontology — deliver the Azure AI Search + IAM setup as a repeatable pattern

Launch the accelerator product: "Fabric IQ in 8 weeks" — fixed-price, defined deliverables, Azure Marketplace listing

Ossie advisory: first engagement for a client with Snowflake + Fabric co-existence — define a cross-platform semantic governance model

Build context engineering capability from existing staff — Power BI semantic model authors are the closest skill match; pair with domain SMEs from priority sectors

Q3 2027

Scale

Jul – Sep 2027

Full semantic services practice: Ontology Engineering, Data Agent Deployment, Operations Agent Templates, MCP/Foundry integration running simultaneously

First managed services contract: ongoing ontology governance + agent monitoring — shift from project to retainer

Domain entity type libraries: reusable ontology templates across BFSI (IRB, LCR/NSFR, trade lifecycle), Healthcare (clinical pathways, patient journey), Manufacturing (asset hierarchies, OEE), Energy & Utilities (grid topology, consumption forecasting) — commercial IP, not custom re-build per client

Data Engineering Agent (Osmosis): position the oversight/governance model — humans approve, monitor, audit; your firm makes agentic engineering trustworthy

Target: multiple active ontology engagements across domains; first managed services contract live; domain accelerators generating repeatable revenue

Q4 2027

Mature

Oct – Dec 2027

Context Layer as a Service (CLaaS): first vertical context layer subscription signed — BCBS 239, clinical pathways, or OEE; recurring revenue, not project billing

Cross-domain ontology reuse: entity types and business rules built in one engagement applied across two or more clients in the same vertical — proof the IP model works

Agent fleet governance: Entra Agent ID policies, token budget governance, and audit-trail stack operational across all live client agents — not per-deployment, practice-wide

Expand into multi-agent orchestration: at least one engagement delivering an orchestrator + sub-agent topology with documented A2A handoff contracts

Practice P&L: measure and report context engineering revenue separately from classic data engineering — the two are no longer the same practice

🏁 End of 2027 — credible, recurring, scalable

Team Readiness

Who does what — role map for the delivery team

Semantic / Ontology Engineer

Hire/train now

Build and maintain Fabric IQ Ontology items
Generate ontologies from Power BI semantic models
Design entity types, properties, relationships, inheritance
Write business rules in natural language
Source from: existing Power BI semantic model authors — closest skill match

Context Engineer

Hire/train now

Design and tune the 6-layer context model for Data Agents
Write agent instructions, data source descriptions, topic libraries, example queries
Measure and improve NL2SQL/NL2DAX accuracy through context quality
Source from: data engineers who already write good query documentation

Agent Integration Architect

Build Q2 2027

Design the agent topology for each engagement (which of 6 patterns, for which use case)
Configure MCP endpoints; set up Foundry IQ Agent; govern Copilot Studio integration
Manage Entra Agent ID governance across agent fleet
Source from: solution architects with Azure AI Foundry experience

Fabric Data Engineer

Existing role — evolves

Existing pipelines and lakehouse work remains valid — this role doesn't disappear
Evolution: take responsibility for ontology data binding quality (the post-generation tasks)
New skill: understand entity type keys, graph eligibility, delta table requirements for graph execution
Risk: Data Engineering Agent (Osmosis) will gradually reduce demand for manual ETL work from 2027 onward

Engineering Transformation

Syntax to Semantic — The 12-Month Delivery Motion

Engineering teams today use AI at the syntax layer — generating code, tests, and data pipelines faster. The next motion is semantic: encoding domain knowledge as a governed, agent-queryable context layer. This is not a tooling adoption program; it is a capability transformation. The output shifts from code to context — and the accuracy of every agentic outcome depends on how well that context is built.

This motion applies across domains. The speed at which a team can build a credible semantic layer is directly proportional to the depth of domain knowledge already inside the firm.

Prerequisite Before Any Pilot: Domain-Specific Synthetic Data

Customers are not ready to run AI against live regulated or operationally sensitive data. Before any pilot begins, domain-specific synthetic data — built to mirror the schema, statistical properties, and business rules of the customer's real environment — must be in place. Without it there is no safe test environment, no accuracy baseline, and no internal stakeholder confidence before real data is committed. Synthetic data preparation is a gate before the pilot, not a task inside it.

Where existing domain depth accelerates the motion

Synthetic data and ontology accelerators are only credible when grounded in real domain knowledge. These are the sectors where that depth already exists and where the motion starts fastest.

BFSI

Regulatory reporting — BCBS 239, IFRS 9, LCR/NSFR, IRB
Trade lifecycle, position management, customer 360
Liquidity monitoring, credit risk, stress testing

Healthcare & Life Sciences

Clinical pathways, patient journey, care episode entities
Drug trial data models, adverse event tracking
Compliance with HL7/FHIR-aligned data structures

Manufacturing

Asset hierarchies, work orders, maintenance records
Production metrics — OEE, downtime, yield rates
Supply chain entities — BOM, supplier, inventory

Energy & Utilities

Grid topology, asset management, outage patterns
Consumption forecasting, demand response entities
Regulatory reporting — FERC, OFGEM, emissions compliance

13–18 Months: Capability Hardening

Pre-built domain accelerators (BFSI, Healthcare, Manufacturing, Energy & Utilities) reusable across accounts. Retainer model live — monthly ontology governance and agent accuracy management. The firm is positioned not as a Fabric IQ implementer but as the domain-depth play: governed semantic context layers with validated domain knowledge already encoded.

The failure mode to design against

Auto-generating the ontology and skipping the domain SME pairing produces a fast but semantically wrong layer. The result: agents that give confident, incorrect answers on domain-specific questions. The discipline this requires is deliberate domain knowledge encoding — it cannot be automated. An LCR calculation definition, a clinical adverse event rule, a grid outage classification — these require a domain expert to validate. Engineering speed without domain depth is the failure mode.

Governance Checkpoints

What to verify at each stage

Stage	What to verify	Why it matters
Before generating ontology	Confirm Read + Build permissions on each source semantic model	Generation silently fails or produces incomplete output without Build permission
After generation	Check entity type key assignments; verify relationship type bindings; confirm metric proxy links resolve	Graph execution and multi-hop queries require entity type keys; metrics without valid proxy links return null
Before deploying Data Agent	Test 6-layer context with representative questions from real users; measure baseline NL2SQL accuracy	Context quality determines accuracy — 12.1% accuracy gap between poor and rich context is a client-visible failure
Before adding to MCP	Confirm user identity auth is set up; validate Service Principal restriction (not yet supported); test with the target orchestrator	MCP Service Principal gap means per-user auth only — relevant for service accounts and automation
At Jan 31, 2027	All client ontology items migrated to new experience; agents and dashboards reconnected; Activator rules recreated	Old experience shuts down — any items not migrated become inaccessible

Industry Shift Analysis

What is actually changing — and for whom

This is not a tooling upgrade. The arrival of Fabric IQ Ontology + agents marks a genuine architectural discontinuity in data engineering. Two things are happening simultaneously: the output of data work is changing, and the primary skill that produces value is changing.

The central thesis: Context Engineering is becoming the new Data Engineering. The team that writes the best ontology definitions, the best agent instructions, and the best business rules will produce better AI answers than the team with more compute or better models. This shift favours IT services firms over hyperscalers — it requires domain expertise and business knowledge, not infrastructure.

Engineering Shift

Syntax Is the New Assembly

Assembly language was once the primary skill of a software engineer. Then compilers automated it — and the engineers who thrived were the ones who moved up to writing C, FORTRAN, and eventually Python. The ones who stayed in assembly became a niche. That same abstraction shift is happening now, one layer higher: LLMs are automating syntax. Python, SQL, PySpark — the languages engineers write today — are becoming what assembly was in 1985. Generated, not authored.

1940s – 1950s

Machine Code

Human wrote

01001000
10000101
11000000

Replaced by: Assemblers — wrote binary from symbolic mnemonics

→

Assembler writes binary

1950s – 1980s

Assembly

Human wrote

MOV AX, BX
ADD AX, 5
JMP loop

Replaced by: Compilers (FORTRAN, C) — wrote assembly from high-level syntax

→

Compilers write assembly

1970s – 2024

Syntax Languages

Human wrote

Python · PySpark
T-SQL · DAX · KQL
Java · Scala

Being replaced by: LLMs (Claude Code, Copilot, Cursor) — write syntax from structured intent

→

LLMs write syntax

2025 →

Semantic Context

Human writes

Ontologies · Business Rules
Entity Definitions
Agent Instructions

Cannot yet be automated — domain meaning requires human judgement and SME validation. This is the current frontier.

The new engineering craft

The implication is not that engineers disappear — they move up the abstraction ladder, as they always have. The engineer who writes Python today will prompt an LLM to write Python tomorrow. The engineer who defines what the code should mean — who encodes business concepts, relationships, and rules into a layer agents can reason against — is the next generation of the craft.

What this shift looks like in practice

Two disciplines side by side. The left is being automated. The right is where engineering value moves.

Being Automated · Syntax Layer

Data Engineering

Instructions for machines to execute

Human Craft · Semantic Layer

Context Engineering

Instructions for agents to interpret

Languages

PythonPySparkT-SQLKQLDAXScala

Languages

Structured NLJSON SchemaRDF / JSON-LDSPARQLDAX (as proxy)Ossie Schema

What you build

Pipelines, lakehouses, warehouses, ETL transformations, semantic models, dashboards

Output

What you build

Entity graphs, ontology items, agent instructions, topic libraries, business rule assertions, example query sets

Output artifact

Pipeline runTable / ViewReport

Artifact

Output artifact

Ontology itemContext layerAgent instruction set

Who consumes it

BI users, analysts, downstream applications, automated reports

Consumer

Who consumes it

AI agents — Data Agent, Operations Agent, Copilot, MCP clients, Foundry IQ Agent

Quality metric

Did it run? Is the data correct? Is the query fast? Zero errors.

Quality

Quality metric

Did the agent answer correctly? NL2SQL / NL2DAX accuracy score. Domain SME validation of answer quality.

Who writes it

Software / data engineer — solo authorship; LLMs now handle significant portions of this

Authors

Who writes it

Engineer + domain SME — joint authorship is mandatory. Engineer provides structure; SME provides meaning. LLMs cannot substitute for the SME.

Mental model

Data flows: source → transform → destination. The pipe is the product.

Model

Mental model

Knowledge flows: domain expert → context layer → agent reasoning. The context is the product.

Where they meet

Power BI Semantic Model

Shared language

DAX lives in both worlds

Platform bridge

Microsoft Fabric IQ

Old World vs New World

What is going away — what is taking its place

❌ Going Away

🔴

ETL as the primary value delivery vehicle. Pipelines were the product. Data engineering meant moving, transforming, and loading data correctly. The pipeline was the deliverable.

🔴

SQL as the primary interface for data consumers. Analysts needed SQL. Reports required BI tools. Business users were downstream recipients of pre-built dashboards.

🔴

The semantic model as the terminal layer. Power BI models were the destination — the final semantic layer that humans queried through visuals.

🔴

"Build a report, ship a dashboard" as the data team's output. Value was delivered as visualisations. BI development was the last mile.

🔴

Schema-first design. Architecture started with the data model. Business concepts were derived from tables, not the other way around.

🔴

Documentation as an afterthought. Descriptions, business rules, and metric definitions lived in Confluence, emails, or nowhere. They were human artefacts, not machine-readable assets.

🔴

Manual data discovery. Engineers spent weeks understanding what data existed, what it meant, and how entities related. Discovery was a precondition, not a capability.

✅ What Takes Its Place

🟢

Context Engineering as the primary value delivery vehicle. The ontology definition, the agent instructions, the business rules, and the topic libraries are the product. Pipelines become infrastructure.

🟢

Natural language as the primary interface for data consumers. Business users ask questions directly. Agents translate intent to DAX, SQL, and KQL. SQL fluency remains necessary — but only for the engineers, not the consumers.

🟢

The ontology as L4 in a 5-layer stack. Semantic models become L2 — foundational but not terminal. The ontology sits above them, consuming their metrics and extending their semantics into real-time and entity-relationship domains.

🟢

"Deploy a governed agent" as the data team's output. A Data Agent, Operations Agent, or Copilot integration is the deliverable. The business user gets an interface, not a dashboard.

🟢

Entity-first, business-concept-first design. Architecture starts with what the business calls its objects — Customer, Position, Instrument — and binds data sources to those concepts. The ontology IS the architecture document.

🟢

Semantic metadata as first-class engineering artefacts. Descriptions, synonyms, business rules, and KV annotations are machine-readable and agent-retrievable via MCP. The business glossary is now executable infrastructure.

🟢

AI-assisted ontology discovery. The Ontology Agent in Plan mode explores, maps, and models entities from existing semantic models and data sources. Discovery becomes a conversation, not a weeks-long archaeology project.

Developer Lens

For the individual practitioner — what changes day to day

Skills that stay critical

Keep

Data modelling intuition: understanding entities, relationships, cardinality — this is the foundation of ontology design
SQL and DAX fluency: still needed to verify what agents are generating and to write example queries that train the context model
Domain knowledge (BFSI/HCMI): the ontology is only as good as the business concepts it models — deep domain understanding is a moat
Data quality thinking: garbage-in-garbage-out applies to context just as much as to pipelines

Skills being automated — not just declining

Structural shift

Syntax authorship as a primary skill: LLMs write Python, SQL, PySpark, DAX from structured intent. The engineer who types code line-by-line is doing what assembly programmers did before compilers arrived. This is not a gradual decline — it is a structural shift in what engineering value means
Low-level pipeline orchestration: Data Engineering Agent (Osmosis) handles complex ETL and migrations autonomously by 2027 — not just assists with them
Manual schema documentation: Ontology Agent Plan mode discovers and drafts entity types, properties, and relationships from existing semantic models
BI report development: Agentic Apps generate Power BI applications from natural language descriptions — the "build a dashboard" deliverable is automated
Ad-hoc query writing for business users: Data Agents replace the analytics engineering layer for routine Q&A — the "write me a SQL to answer this" request disappears

New skills to build now

Invest

Ontology modelling: entity types, inheritance, shared properties, namespace design — analogous to data modelling but for business concepts not tables
Context engineering: writing agent instructions, data source descriptions, example queries, topic libraries that measurably improve NL2SQL/NL2DAX accuracy
MCP protocol basics: endpoint configuration, auth patterns, tool discovery — needed for custom agent integration work
Agent prompt design for structured data: different from chatbot prompting — precision matters because the agent generates executable queries
Business rules authoring: translating business policies into natural language rules that agents can retrieve and apply as reasoning context

The daily workflow — before vs after

Before

Write Spark/Python, build ADF pipelines, maintain delta schemas, write DAX, publish semantic models, hand off to BI

After

Author ontologies, write context (the 6-layer model), configure MCP endpoints, validate agent responses against expected business answers, govern the semantic definition lifecycle

The translation

Context engineering is the new ETL — raw business knowledge (domain expertise, data dictionaries, business rules) transformed into machine-executable intelligence

Architect Lens

For the solution architect — the structural shifts

Before

"Where does the data live, what schema does it need, and how do we move it?"

Output: data in the right place. Architecture = ERD + pipeline.

Now

"How does an agent understand this business domain, and what can it safely ask of the underlying data sources?"

Output: governed agent with sourced answers. Architecture = ontology graph + agent topology.

Five decisions the architect now owns

📐

Ontology as Architecture Doc

ERD is replaced. Fabric IQ Ontology is machine-readable, version-controlled, consumed directly by agents. Glossary + data dict + semantic layer = one Fabric item.

⑂

Agent Topology

6 patterns per use case. Decision: consumer type, latency, governance constraint, allowed LLM. Regulated clients → Custom MCP. Monitoring → Operations Agent.

🔌

MCP as the New API

Every ontology item is an MCP server. Build once; all AI clients connect. Ontology surface = public API of the business knowledge layer. Treat it as such.

⬡

The Graph Decision

Graph execution enables multi-hop traversal but adds hard constraints: delta tables only, entity type keys required. Decide per-ontology which entities need it.

🛡

Governance Redesigned

Entra Agent ID: agents have identity alongside humans. Purview governs what agents surface. Semantic layer is now inside the security perimeter.

Agent Harness — the new infrastructure layer

Design now

Skip this and end up with agent sprawl. The harness is what makes agents governable at scale.

⬡

SPAWN

›

🔧

›

▶

EXECUTE

›

📊

MONITOR BUDGET

›

⚠

FALLBACK

›

👤

ESCALATE

Orchestration

Orchestrator → sub-agent patterns; architect defines handoff contracts and tool access per agent identity

Tool Registry

Fabric IQ MCP · code sandbox · document store · external APIs — access enforced per Entra Agent ID

Token Budget

Per-query cost ceiling; route to cheaper model before budget exhausted — agents have real cost

Frameworks

Semantic Kernel · LangGraph · AutoGen · AI Foundry — abstract the harness; framework must be swappable

AgentOS — what is being assembled

Emerging concept

No single product is AgentOS yet. Microsoft is assembling it piece by piece. Understand the analogy; design to it now.

OS Concept

Agent Equivalent in Fabric IQ

Process

managed execution unit

Agent + Entra Agent ID — managed identity, permissions, resource limits. Not a stateless function call.

Memory

persistent state, file system

OneLake + Fabric IQ Ontology — OneLake = file system; Ontology = shared read-memory for all agents in the workspace.

IPC

inter-process communication

MCP + A2A protocols — MCP for tool access; A2A for agent-to-agent delegation and task handoff.

Scheduler

when and what runs

Orchestrator + Operations Agent — which agent runs, when, triggered by what event. Operations Agent = 5-min evaluation scheduler.

Kernel

shared trusted core

Fabric IQ Semantic Layer — lowest trust layer all agents read from. Treat as kernel: versioned, pipeline-deployed, never ad hoc.

Well-Architected Agents — six pillars

No standard yet — own it

No vendor has formalised this. The firm that publishes a Well-Architected Agents review framework owns the CDO conversation whenever a pilot delivers inconsistent results.

🎯 Accuracy

Semantic context quality. NL2SQL / NL2DAX baselined. SME validated.

Risk: confident wrong answers

🛡 Safety

Guardrails active. Purview labels enforced. No unauthorised data surfaced.

Risk: sensitive data leaked

🔍 Observability

Full trace: tools called, cost, reasoning. Audit trail for regulated use.

Risk: audit fails, no trace

⟳ Reliability

Fallback patterns. Graceful degradation. Retry and timeout budgets explicit.

Risk: agent timeouts, no fallback

⚖ Governance

Entra Agent ID active. Ontology pipeline-deployed. Version history kept.

Risk: shadow agents, no identity

💰 Cost

Token budget per query. Model routing: complex → expensive; lookup → cheap.

Risk: budget exhausted mid-query

Domain Lens

Business domain awareness — the hidden accuracy variable

In the old world, domain knowledge was useful but not causal. A data engineer could build a correct pipeline without deeply understanding what "LCR ratio" or "PD model" meant — the pipeline moved data correctly or it didn't, and technical correctness was the measure. In the agentic world, domain knowledge is directly causal to accuracy. The ontology is only as good as the business concepts it models. The agent is only as accurate as the rules it has been taught. The context is only as useful as the example queries written with real business intent.

The ontology models business concepts — not tables

Generating an ontology from a Power BI semantic model is a mechanical step. Defining it correctly is domain work.

You cannot correctly define a Credit Exposure entity type — its relationship to Counterparty, Netting Set, and Collateral, its relevant regulatory metrics — without knowing what those terms mean in a BCBS 239 context
A "technically valid" ontology built by someone without domain knowledge will answer the wrong questions accurately — the worst kind of failure because it looks correct
The entity type key, relationship directionality, inheritance structure, and metric proxy choices all embed domain assumptions. Wrong assumptions compound across every agent query that consumes the ontology
Rule of thumb: the ontology design review should always include a domain SME — a risk officer, treasury analyst, or compliance lead — not just a data architect

Business rules require domain fluency to be agent-useful

Natural-language rules are only as useful to an agent as they are domain-accurate.

"LCR exception = ratio below 110% for more than 2 consecutive reporting days" can only be written correctly by someone who knows the regulatory threshold, the calculation basis, and what "exception" means in that firm's specific risk framework
A rule written without domain knowledge is worse than no rule — agents will retrieve it, treat it as authoritative, and reason from a false premise
This applies equally to HCMI: a rule like "Patient at-risk = length of stay > clinical benchmark for DRG" requires clinical domain knowledge to set the benchmark correctly per diagnostic group
Implication: business rules authoring is not a data engineering task — it belongs to a collaboration between the domain expert and the ontology engineer

Context engineering is domain translation

The 6-layer context model for Data Agents is the act of translating deep business knowledge into machine-readable form. The accuracy improvement (+12.1% NL2SQL) comes from this translation quality.

Agent instructions require knowing what this agent should and should not answer — a boundary that only a domain expert can draw correctly
Example queries must reflect the real vocabulary and intent of the business user — "What is our net open position in EUR rates as of yesterday close?" cannot be written without knowing what NOP means in that trading context
Topic libraries (up to 1M chars per SQL source) are only useful if they contain the right business context — regulatory definitions, product taxonomy, organisational hierarchy — all domain artefacts
The accuracy gap between a generalist and a domain-aware context engineer is not a skill gap — it is a knowledge gap. The tool is the same; the domain understanding is not

The hybrid profile — the most valuable new hire

The talent implication of domain-as-accuracy-variable is a specific hiring priority that most firms are not yet acting on.

The profile: a domain analyst (risk, treasury, trading, clinical operations) who understands data platforms — or a data engineer who has spent 3+ years embedded in a BFSI or HCMI business function
This hybrid is rarer and more expensive than either a pure domain SME or a pure data engineer — but one hybrid produces more accurate ontologies than three pure technical engineers
For BFSI specifically: former risk analysts, quant researchers, or regulatory reporting leads who have learned Python/SQL are the highest-value profiles for semantic engineering work
Sourcing: look inside existing client delivery teams — the most domain-fluent data engineers are already there, doing manual work that the agentic layer will eventually automate. Identify them before they become redundant
IT services firms with deep BFSI or HCMI domain knowledge have a structural advantage over hyperscalers and generalist SIs — this is the moat that platform companies cannot replicate with headcount or compute

Market Motion

Context Engineering market motions — a catalogue

The market is forming now. Most IT services firms are selling the same thing: a large, vague, T&M AI transformation programme with no defined proof point. These motions are built on a different principle — prove value first, then propose production. Every motion is fixed-price, time-boxed, and leads to a gate. What makes each one distinct is stated explicitly below.

ENTRY — quick proof

DOMAIN IP — use-case led

ARCHITECTURE — structural

COMMERCIAL — business model

Entry · 2–4 weeks 🧪

Context Lab Sprint

"Prove the improvement before I commit to production."

What sets this apart

Guaranteed before/after accuracy proof on synthetic domain data — before any budget commitment. Cloud co-funding via Azure MACC cuts net cost to near zero. Gate: scoped production proposal at Day 10, not a PowerPoint at Day 60.

Semantic Clarity

~$20–25K

2 weeks · 1 data source · NL2SQL baseline proof

Connected Data

~$30–40K

3 weeks · multi-source · ontology + agent integration

Audit-Ready

~$40–55K

3–4 weeks · Purview governance + MCP endpoint

CDO / Head of AI Trigger: failed pilot Cloud-fundable

Entry · 1 week 🔬

Agent Autopsy

"Our AI pilot produced inconsistent results. We need to understand why before going further."

What sets this apart

Every IT firm sells new projects. No one enters via an acknowledged failure and earns trust through diagnosis. The Autopsy is a structured 5-day post-mortem of a stalled or failed GenAI pilot: context gap analysis, ontology audit, agent query trace review. Deliverable: a root cause report with a remediation path. The only firm that can credibly run this is one that understands why context engineering fails — not just how to build it.

CTO / CDO Trigger: stalled pilot Fixed $10–15K

Entry · 1 day ⚡

One-Day Benchmark Challenge

"Show me the difference before I agree to anything."

What sets this apart

Run the prospect's own query set against their current AI and against a context-enriched version built overnight on synthetic data. Measure NL2SQL accuracy, hallucination rate, and answer consistency. Present the delta in a one-page scorecard. Zero commitment ask from the customer. No other IT firm offers a one-day free proof as a structured sales motion — because no other firm has the pre-built context layer templates to do it in a day.

Data Engineering lead Trigger: Copilot skepticism Free / Loss-leader

Entry · 3 weeks 🔧

Copilot Remediation Sprint

"We bought Copilot licenses. Users tried it for two weeks and stopped trusting the answers."

What sets this apart

Microsoft sells the Copilot license. No one helps when the answers are wrong. The gap is always context — not model quality. This sprint adds a semantic layer under M365 Copilot / Copilot Studio in 3 weeks, targeting the specific query types that failed. Entry point: Copilot license owner who has a trust problem. Available to 22M+ Power BI clients already on Fabric — the largest addressable installed base in enterprise software.

M365 owner / CDO Trigger: Copilot distrust MACC-fundable

Domain IP · 3–4 weeks ⚖️

Regulatory Reasoning Agent

"Our agent is right. We just can't prove it to the regulator."

What sets this apart

Every AI vendor promises accuracy. Only semantic engineering can prove the reasoning chain to a regulator. The agent doesn't just answer — it cites the ontology paths it traversed and the business rules it applied. Deliverable: an audit trail stack (formal ontology + Purview lineage + Entra Agent ID log) that satisfies DORA, FCA, BCBS 239, or internal model risk governance. Applicable in BFSI, Healthcare, and any regulated vertical. No technology vendor builds this because they don't do domain-specific ontology.

CCO / Legal / Risk Trigger: DORA / FCA / BCBS $40–55K

Domain IP · 2 weeks 🧬

Synthetic Domain Data Lab

"We want to pilot AI but our data is too sensitive to expose."

What sets this apart

Most firms tell the customer to clean and stage their data before a pilot can begin. This motion skips that blocker entirely — deliver domain-specific synthetic datasets that statistically mirror production patterns but contain no real PII, no sensitive positions, no patient records. The AI pilot runs on synthetic data; the accuracy benchmark holds because the semantics are faithful. This is the unlock for BFSI and Healthcare where 2027 pilots will stall at the data-readiness gate. Built once per domain and reused across clients.

CDO / DPO Trigger: data governance blocker $20–30K

Domain IP · 2 weeks 📚

Domain Vocabulary Sprint

"Our analysts have 10 years of domain knowledge. We just can't encode it into AI."

What sets this apart

Most semantic projects start from database schemas. This one starts from people — domain SMEs — and reverses the usual order. Run structured vocabulary elicitation sessions with the client's senior analysts, convert their implicit knowledge into governed entity definitions, business rules, and metric proxies. The output is a domain entity library (BFSI: IRB, LCR/NSFR, trade lifecycle; Healthcare: clinical pathways, ICD-10; Manufacturing: asset hierarchies, OEE) that becomes the foundation for every agent. This is the motion that builds irreplaceable IP in the client's language, not a vendor's template.

Head of Analytics / COO Trigger: inconsistent definitions $20–35K

Domain IP · 4 weeks 🏭

Shadow AI Consolidation

"We have 12 ChatGPT and Copilot deployments across departments. They all give different answers to the same question."

What sets this apart

IT firms sell new tools. This motion enters by auditing what already exists — the shadow AI ecosystem that grew without governance. Map every active LLM deployment (ChatGPT, Copilot, internal tools), classify each by domain and risk, then consolidate them onto one governed context layer. The customer retains their AI investment while gaining consistency and control. Entry is always free: "let us audit your shadow AI for one week." The consolidation engagement follows from the audit findings, not a pre-sold package.

CIO / CISO Trigger: ungoverned AI sprawl $50–80K

Architecture · 1 week 🏗

Well-Architected Agent Review

"We've built three agents. How do we know if they're built right?"

What sets this apart

Microsoft Azure has a Well-Architected Framework for infrastructure. No vendor has formalized the equivalent for agents. This is a structured review against six pillars — Accuracy, Safety, Observability, Reliability, Governance, Cost — delivered in one week, producing a scored assessment and a prioritized remediation backlog. Free or low-cost because it creates the mandate for a paid remediation engagement. The firm that establishes this as a named framework owns the audit conversation before the Big 4 arrive with a version of their own.

Enterprise Architect / CDO Trigger: scaling agents Free → paid remediation

Architecture · 3 weeks ⑂

Multi-Agent Architecture Sprint

"We have five agents doing different things. They don't coordinate and we can't govern them together."

What sets this apart

Most firms help build individual agents. None help design the system they form together. This sprint designs the agent topology — orchestrator/sub-agent patterns, tool registry, A2A handoff contracts, token budget governance — before sprawl makes it ungovernable. Deliverable: an agent topology diagram, a harness design, and a governance model. This is infrastructure architecture, not application development. The entry: any organization with more than two live agents and no documented interaction design between them.

Enterprise Architect Trigger: agent sprawl $30–45K

Architecture · 4 weeks 🔌

API-to-Agent Conversion

"We've spent 10 years building APIs. How do we make that investment callable by AI agents?"

What sets this apart

Most AI implementations treat the existing API estate as a liability to work around. This motion treats it as the best asset — the business logic is already encoded and tested. Convert REST/GraphQL API surfaces into MCP-compatible tool definitions, register them in an agent harness, and ground them in a semantic layer that gives each tool its business meaning. No new core systems build. This is leverage, not replacement. Resonates strongly with engineering-led buyers who've invested heavily in API-first architecture and resist rebuilding from scratch.

CTO / Platform Eng Trigger: API-first org going agentic $45–65K

Commercial · Recurring 📦

Context Layer as a Service (CLaaS)

"We don't want to maintain a semantic layer. We want to subscribe to a maintained, improving one."

What sets this apart

Every other firm builds a semantic layer per client, charges T&M, and walks away. CLaaS is a pre-built, maintained context layer for a specific vertical — BCBS 239, clinical pathways, OEE, grid topology — delivered as a subscription. The client gets a maintained, versioned, improving entity library with a defined SLA on ontology coverage and update frequency. Recurring revenue, not project revenue. Built once, deployed to multiple clients in the same vertical. The business model is closer to a data product vendor than a services firm — and that's precisely the moat.

CDO / Finance Trigger: post-pilot scale $8–15K/month

Commercial · IP Play 🏛

Semantic Inheritance Play

"We've built hundreds of Power BI semantic models over 10 years. Do we throw all that away?"

What sets this apart

Most AI vendors treat the client's existing data estate as legacy to be replaced. This motion positions 10 years of Power BI semantic model investment as a competitive advantage — and converts it to agent-ready context through ontology generation. "You don't start from zero. You start from where your analysts already are." The psychology is entirely different: the buyer feels validated, not disrupted. Resonates most powerfully with orgs who've resisted AI modernisation because of sunk cost anxiety — which is most of the large enterprise market.

Head of BI / CDO Trigger: 100+ semantic models $35–60K conversion

Commercial · Funding play 💰

Cloud Credit Arbitrage

"We want to run this sprint. But there's no new budget available before Q2."

What sets this apart

No IT firm systematically structures cloud co-funding as a first-class commercial mechanism. Azure MACC (commits already in place) + Microsoft AI FastTrack credits can reduce a $25K sprint to near zero net cost. This is not a discount — it's a funding source the customer has already committed. The commercial innovation: every sprint proposal includes a co-funding breakdown showing list price, Azure credits applied, and net customer cost. The conversation moves from "can we afford this?" to "how much of our existing Azure commitment should we apply?" — a fundamentally different buying dynamic.

CFO / Procurement Trigger: budget freeze Net: ~$0–15K

Gate Structure

Every motion leads somewhere — the arc from sprint to production

The single biggest difference from a project-based selling model: each engagement is designed to end at a gate, not a deliverable. A gate is a decision point with evidence — the customer sees proof, then decides whether to proceed. There is always a natural next step.

Phase 1

Context Lab Sprint

2–4 weeks · fixed price · synthetic data

Gate 1

Before/after
evidence

›

Phase 2

Scoped Production Proposal

Maturity score readout · funded by evidence

Gate 2

Budget
approved

›

Phase 3

Context Build

4–8 weeks · production data · governed deployment

Gate 3

Agent
accepted

›

Phase 4

Live Agentic Use Case

Real data · real users · expansion motion

Campaign Triggers

When to reach out — the sales trigger events

Client ran a Copilot or ChatGPT pilot and got inconsistent answers — context gap, not model gap → Agent Autopsy or Benchmark Challenge

Client is renewing Microsoft cloud capacity (Fabric, Azure, M365) — semantic services are the next layer above capacity; Azure MACC credits are available

Client has M365 Copilot licenses but declining adoption — Copilot Remediation Sprint; Fabric IQ in Copilot is already GA and waiting

Client is on old Ontology experience — Jan 31, 2027 deadline is a forcing function; enter with the migration, upsell the context layer

Client has 100+ Power BI semantic models — Semantic Inheritance Play; the conversion is the entry

Client has Snowflake + Fabric co-existing — Apache Ossie cross-platform advisory; vendor-neutral semantic layer story

Client has a BCBS 239 / DORA / FCA compliance programme — Regulatory Reasoning Agent is the named offer; governance = urgency

Client is post-cloud migration asking "what's next" — context engineering is the answer; shadow AI audit is the entry

Client has more than two live agents with no documented interaction design — Multi-Agent Architecture Sprint; agent sprawl is the entry signal

Client's data is too sensitive for a live AI pilot — Synthetic Domain Data Lab; unblock the pilot without touching production data

Leadership Brief

The business case — why build this practice now

22M+

Power BI semantic models in daily use — every one an ontology candidate

Q1 '27

Fabric IQ Ontology GA target — preview deployments become production-ready at announcement

12mo

Window before Big 4 enter this space with budget and Microsoft field relationships

95%

of GenAI pilots deliver no P&L impact — context readiness, not model quality, is the root cause

This is not a technology trend to monitor. It is a service market forming right now — and the firms that establish semantic engineering practices in the next 12 months will own the accounts for the next 5 years. The addressable market is the entire installed base of enterprise Power BI. The window for first-mover advantage closes when the Big 4 arrive with budget — which is 2027.

The Competitive Window

Why the decision is now — not later

Now — First Mover

Build while the space is open

Sprint model defined and priced
Domain IP library under construction
Microsoft co-sell accessible
Reference accounts available to win
No named competitor in BFSI semantic engineering specifically

2027 — Late Entry

Competing without IP or references

Kanerika, Emergent, MILL5 have reference accounts
No domain ontology IP to differentiate on
Microsoft co-sell occupied by earlier partners
Clients ask for references you don't have
Winning deals on price, not value

2028+ — Closed Window

Big 4 arrive with budget

Accenture/Cognizant enter with BFSI-specific Fabric IQ offers
Client acquisition cost doubles
Microsoft shifts co-sell priority to scaled partners
Domain IP built now is the only moat against Big 4 scale

Investment Thesis

The 3-year trajectory — what to invest and what to expect

DE automation timeline · 2024 → 2027

AI task complexity is doubling roughly every 3–4 months (METR, 2026). Microsoft absorbed that trajectory directly into the Fabric platform — from limited Copilot previews in 2024 to the Data Engineering Agent (Project Osmos) in 2026. The window to position ahead of GA is open now.

Capability metric note (METR): "Task horizon" = human-hours of task difficulty an AI completes at 50% success rate — not continuous uninterrupted runtime. METR explicitly warns against that reading. Their measurement suite ceiling is ~16 h; values above that are extrapolated.

Period	Task horizon (METR)	Impact on data engineering	Fabric / Microsoft signal	Visibility
2024 H1	~4–10 min GPT-4o mid-2024 · METR May 2026 fit	Typing accelerator only. SQL completion, DAX drafts, docstring generation — all human-reviewed before use. No role impact.	Power BI Copilot preview Nov 2023. Limited GA announced May 2024 (Build). Only narrative-generation truly GA June 3 2024. Data Engineering, Warehouse, Data Science workloads remain preview. F64+ SKU requirement limits reach.	Low
2024 H2	~15–30 min o1-preview Sep · o1 full Dec 5 2024 · 48.9% SWE-bench Verified	First delegatable subtasks: unit test generation, dbt scaffolding, simple schema migration scripts. Still human-approved before deployment. Entry-level DE hiring begins to slow.	Fabric Copilot billing starts March 2024. Data Engineering, Warehouse, Data Science Copilot remain in preview. F64 SKU requirement remains a reach barrier for most customers.	Emerging
⚡ INFLECTION 1 2025 H1	~50 min–2 h Claude 3.7 Sonnet Feb 2025 · 62.3% SWE-bench Verified · Int'l AI Safety Report 2025	Fabric AI becomes broadly accessible. End-to-end pipeline drafting from requirements, AI-generated data contracts, automated test suites. Junior-level coding tasks fully delegatable. Entry-level DE openings shrink to ~2% of total DE postings.	April 2025: Copilot expands from F64 to F2+. The real adoption gate opens. AI Functions in preview. Data Science AI Skill conversational. Copilot on mobile (iOS/Android).	Moderate
2025 H2	~2–8 h estimated Extrapolated from METR ~105-day doubling rate · no confirmed datapoint for this window	First unattended pipeline runs for narrow tasks. AI-driven data quality monitoring, schema-change impact analysis run overnight. Headcount freezes on junior DE roles reported across industry.	Nov 2025: AI Functions GA. Pipeline expression Copilot in preview. Advanced LLM settings (reasoning effort, verbosity) added to Fabric AI workloads. Dataflow Gen2 AI Functions integration in preview.	Visible
⚡ INFLECTION 2 2026 H1	~16 h equivalent METR TH1.1: Claude Mythos Preview, Mar/Apr 2026 · 95% CI: 8.5–55 h · current suite ceiling	First DE-specific agentic tool lands in Fabric. Osmos acquired Jan 5 2026. Data Engineering Agent (Project Osmos) in Preview. Interprets requirements, writes ETL, validates, deploys — pending human approval. Supervised pipeline, not fully autonomous.	Jan 2026: Osmos acquired. Data Engineering Agent Preview announced at FabCon Europe. Steerable from VS Code, GitHub Copilot, Claude Code. April 2026: Copilot Studio A2A multi-agent live for eligible customers.	Strong
← NOW 2026 H2	~16–24 h estimated Above METR suite ceiling · no confirmed benchmark · extrapolated from trend	Data Engineering Agent still in Preview — no GA date confirmed as of Sep/Oct 2026. Power BI Agentic Apps GA. Routine migration coding under cost pressure. ~47% of Q1 2026 tech layoffs publicly attributed to AI; DE roles show more resilience than software generalists.	Power BI Agentic Apps GA · per-semantic-model access control GA. Copilot Studio enterprise agents in production. Data Engineering Agent remains Preview — no GA date announced.	High
PROJECTED 2027 H1	Beyond METR ceiling New task suite required to measure above 16 h	Practice bifurcation becomes structural. If Data Engineering Agent reaches GA, justification for manual greenfield ETL disappears. Governance, ontology, and context engineering become the defensible DE roles.	Fabric IQ Ontology GA target Q1 2027 (Microsoft roadmap). Data Engineering Agent → GA pathway (no confirmed date). A2A agent contracts expected standard.	Transformative ⚠ Conditional on GA
PROJECTED 2027 H2	Aspirational No benchmark data	Context engineering separates from classic DE P&L. CLaaS subscriptions plausible if ontology IP proves portable across clients. Human value = domain fluency, governance, client trust — not code volume.	Agent fleet governance standard. Multi-agent A2A orchestration expected production-grade. Vertical CLaaS subscriptions possible.	Platform-native ⚠ Aspirational

Sources

· METR: Measuring AI Ability to Complete Long Tasks (Mar 2025) · METR Time Horizon 1.1 (Jan 2026) · International AI Safety Report 2025 · Microsoft acquires Osmos — Redmond Channel Partner (Jan 2026) · Fabric Data Engineering Agent overview — Microsoft Learn · Fabric Copilot expands to all paid SKUs (Apr 2025) — Microsoft · FabCon Europe 2026 recap — Solv Systems · 78K tech layoffs, 47% AI-blamed: is DE safe? — DEV Community · Is data engineering dead? — 2026 job market reality

Year 1 · FY2027

Delivery-Led

Revenue target

10–15% of total annual revenue in net-new practice work from early-adopter BFSI and HCMI clients

What to invest

Semantic engineering capability (train from existing Power BI and data modelling talent)
Partner certification on Fabric Analytics Engineer path
Context Lab Sprint offer packaged and priced
Internal proof-of-concept on domain synthetic data

Success signals

3+ Onboarding Accelerator engagements delivered
1 Operations Agent in production with a client
Semantic Readiness Assessment sold to 5+ accounts

Year 2 · FY2028

Productise

Revenue target

Accelerate to 20–30% of annual revenue — accelerators, first managed service retainers; IP starts generating repeat revenue

What to invest

BFSI entity type library productised as commercial IP
Azure Marketplace listing (MACC-eligible transact offer)
Demand generation budget tied to Microsoft co-sell motion
Expand semantic capability into Healthcare domain

Success signals

3–5 managed services retainer clients live
Accelerator generating inbound pipeline independently
Domain ontology templates generating licensing revenue

Year 3 · FY2029

Scale

Revenue target

30%+ of annual revenue recurring — IP licensing + managed services; practice runs independently of individual delivery leads

What to invest

ISV programme and partner ecosystem
Potential acquisition of a domain semantic modelling firm
Cross-cloud Ossie advisory (Snowflake + Fabric)
Agentic engineering governance model as a named practice offering

Success signals

Recognised Microsoft preferred partner for Fabric IQ in BFSI
Pipeline sourced through Microsoft field, not only own BD
Practice identified as a market reference, not a delivery firm

Build / Partner / Avoid

Where to invest — and where not to

🏗

Build — own the IP

Semantic Engineering Methodology

Proprietary ontology design methodology for BFSI — entity typing conventions, relationship naming standards, metric governance framework
BFSI Entity Type Library: IRB credit risk, LCR/NSFR liquidity, trade lifecycle, customer 360 — reusable across every BFSI engagement
6-Layer Context Engineering Playbook with BFSI-specific example query libraries
These assets compound — each engagement enriches the IP for the next

🤝

Partner — leverage, don't duplicate

Microsoft + Azure Ecosystem

Microsoft co-sell: align all semantic services to Microsoft FY27 priorities; access field sales as distribution
Azure Marketplace: list accelerators as MACC-eligible transact offers — removes procurement friction for enterprise clients
Purview / Azure AI Search / Foundry: don't build governance or retrieval infrastructure — use what Microsoft has certified
Fabric Insider programme: early preview access is a competitive advantage, not optional

🚫

Avoid — don't waste resources

What not to build

Your own LLMs: MCP + Foundry IQ connects any approved model to Fabric Ontology — no model training needed
Your own semantic layer tooling: Fabric IQ, Power BI, and Apache Ossie cover the platform; build on top, not alongside
A generalist agent framework: agent runtimes are a hyperscaler commodity; value is in domain ontology and context, not the runtime
Migration delivery at scale past 2028: Data Engineering Agent (Osmosis) will automate this; don't build for a closing window

Risk Register

What leadership needs to monitor

Risk	Likelihood	Response
Data Engineering Agent (Osmosis) disrupts migration revenue	High — 2027/2028	Shift delivery to oversight and governance of agentic engineering — humans approve, monitor, and audit. Position as the firm that makes agentic engineering trustworthy. Start this transition in 2027, not after Osmosis goes mainstream.
Big 4 enter with budget and Microsoft relationships	Medium — 2027	Win on domain depth (BFSI entity type libraries, BCBS 239 experience) and speed (productized accelerators). Big 4 compete on trust and relationships; win by being demonstrably faster and more knowledgeable about the specific domain.
Ontology GA delayed beyond Q1 2027	Low-Medium	Don't hold the sales motion for GA. Preview = fully functional; GA = SLA and support. Most enterprise clients care about functionality, not support tier. Preview status doesn't affect their ability to deploy.
Microsoft professional services competes directly	Low — near term	Microsoft GPS focuses on hyperscale deployments, not domain-specific BFSI semantic engineering. Stay in the domain-specific lane where Microsoft does not compete.
NL2SQL/NL2DAX accuracy improvements commoditise context engineering	Medium — 3–5 years	Move up the stack: ontology design and governance is not automated. Even with perfect NL accuracy, someone must design the entities, define the rules, and govern the lifecycle. The methodology is the durable IP.

Practice Design

How to organise — positioning, structure, and differentiation

Practice Lead Profile

Presales architect + delivery background — sells AND governs technical delivery
Deep Microsoft Fabric + Power BI track record — credibility with existing clients
BFSI or HCMI domain fluency — discusses LCR, IRB, trade lifecycle without a domain expert in the room
MCP and Azure AI Foundry familiarity — speaks credibly on enterprise integration patterns

What the Practice Produces

Context Lab Sprints — proof-before-production entry points; the first engagement for every new client
Domain Ontology Libraries — BFSI, Healthcare, Manufacturing; reusable IP that compounds across engagements
Agent Deployment Patterns — 6 integration types documented and repeatable across verticals
Managed Context Services — ongoing ontology governance and agent accuracy monitoring; the retainer model

The Positioning Statement

Don't position as "Fabric consulting" — position as Agentic AI for Enterprise Data, with Fabric as the platform
The brand: the firm that makes enterprise data agent-ready — not just data-correct, but semantically governed and auditable
Differentiation: domain depth (BFSI, HCMI) + semantic engineering methodology + governed deployment = a complete story, not tooling installation
Target state by end of FY2027: the go-to firm for BFSI Fabric IQ in the Microsoft partner ecosystem

Sales Playbook

Where Sales and Presales focus — the complete playbook

The opener that reframes every conversation: 95% of GenAI pilots delivered no measurable P&L impact (MIT NANDA, 2026). 88% never reach production (Iris.ai 2026). Gartner: 60% of AI projects lacking AI-ready data will be abandoned. The root cause across all surveys is not model quality — it is context readiness. That is exactly what this practice solves. Lead with the stat, not the product.

Competitive Landscape

Who is strong on Fabric IQ — and where the gap is

The Big SIs (Cognizant, TCS, Accenture) are not yet in the Fabric IQ semantic space. Cognizant has 1,000 generalist context engineers and their own ContextFabric platform — cloud-agnostic, not Fabric-specific. TCS and Accenture have no published Fabric IQ ontology practice. The real competitive conversation is against the Microsoft-focused partners who are already here.

Forrester at FabCon 2026: "Enterprise AI needs a governed context layer, not just data." — the analyst framing that validates the category. Use it.

Kanerika

Fabric Featured Partner

What they're genuinely good at

Microsoft Solutions Partner for Data & AI. Their BI Audit service inventories semantic models, scores definition conflicts, and identifies ontology candidates. Strong Microsoft relationship — present at FabCon 2026 Atlanta. Good at telling clients what they have.

Where the gap is

Audit tool, not a build practice. Identifies ontology candidates but doesn't encode domain knowledge. No BFSI / Healthcare / Manufacturing entity libraries. No fixed-price sprint model — T&M delivery. Doesn't work in the domain language of regulated industries.

Your move

"Kanerika tells you what you have. We build what your agents need to understand. There's a difference between an ontology candidate list and a BFSI entity library your risk team will recognise."

Emergent Software / MILL5

Fabric-focused SIs

What they're genuinely good at

Early movers on Fabric IQ thought leadership. Emergent Software presented at FabCon 2026 on "Fabric IQ Ontology for Enterprise AI Agents." MILL5's positioning — "The Advantage Now Belongs to the Data Ready" — is sharp. Both publish credible Fabric IQ technical content and have delivery capability.

Where the gap is

Microsoft-only and platform-generic. No published domain-specific ontology IP for BFSI, Healthcare, or Manufacturing. Standard T&M consulting delivery — no sprint/gate commercial model. No proof-before-production commitment. Good at the Fabric layer; thin on domain layer.

Your move

"They can build the ontology structure. We bring the domain content — the BFSI vocabulary, the Healthcare clinical pathways — that your SMEs will actually trust. And we prove it works before you sign the production SOW."

Acuvate

FabCon presenter

What they're genuinely good at

FabCon 2026 presenter specifically on Fabric IQ Ontology for Enterprise AI Agents. Active content publisher on Fabric IQ. Microsoft partner with early Fabric IQ hands-on experience. Known in the Microsoft community space.

Where the gap is

Content marketing strength hasn't translated to a named, productized sprint offering. No domain ontology IP. No commercial model innovation (cloud credit co-funding, gate structure). Competes on awareness and breadth, not depth or proof.

Your move

"Acuvate can explain Fabric IQ. We can run a 2-week sprint and show you a before/after on your actual query types — before you commit to anything. The difference is evidence, not a presentation."

Kyndryl

Infrastructure + Fabric IQ

What they're genuinely good at

Credible at enterprise scale. Published a real Fabric IQ deployment case — using ontology to ground their own agents in live operational context. Microsoft partnership breadth. Can walk into any large enterprise account with existing relationships and credibility.

Where the gap is

Infrastructure firm, not a semantic consulting firm. Their Fabric IQ use is internal — they haven't productized it as a client-facing sprint. No domain IP (BFSI, Healthcare, Manufacturing ontology libraries). No pilot-to-production gate model. Sells managed services, not proof-first sprints.

Your move

"Kyndryl runs your infrastructure. We build the semantic layer that makes your agents intelligent on top of it. These are not the same practice. Ask them to show you a domain ontology for your industry — that's where the conversation shifts."

Cognizant

1,000 context engineers, ContextFabric platform — but cloud-agnostic (AWS/Azure/GCP). No Fabric IQ-specific practice. Competes on scale; counter with domain ontology depth and sprint speed.

TCS

No published Fabric IQ semantic/ontology practice found as of Oct 2026. Large Microsoft relationship, but Fabric IQ ontology delivery is not a named offer. Not yet in this specific race.

Accenture / Avanade

Accenture's semantic layer practice is AWS-focused (AWS Marketplace listing on Bedrock AgentCore). Avanade — their Microsoft JV — has no published Fabric IQ ontology sprint offer. Azure semantic space is open for Avanade; watch 2027.

Window: Big SIs arrive with budget in 2027. The next 12 months is the land-grab for domain ontology IP and reference accounts.

Qualification

Is this account worth pursuing?

Score 1 point per signal. 3+ = qualified lead. 5+ = prioritise immediately.

Is on old Ontology experience — Jan 31, 2027 deadline is a burning platform (highest urgency — score 2)

Has active Fabric capacity (F2+) or is in procurement

Has Power BI semantic models (certified or published, 50+)

Has M365 Copilot licenses deployed — especially if adoption or trust is low

Had an AI pilot that produced inconsistent or unreliable answers — named failure is the best entry signal

Has ungoverned shadow AI — multiple ChatGPT / Copilot deployments across departments giving conflicting outputs

Has an active BCBS 239, DORA, FCA, or SR 11-7 compliance programme

Co-exists on Snowflake + Fabric — Apache Ossie cross-platform advisory opportunity

CDO or CTO has said publicly or in a meeting: "we need to make our data AI-ready" or "our agents don't agree"

Has committed Azure MACC spend available — removes budget approval barrier for a sprint

Discovery

Ten discovery questions — and what the answer unlocks

"Tell me about your last AI pilot — what was it trying to do, and what happened?"

This is the highest-signal opener. If they had a pilot → surface the failure mode: was it the model (rare) or the context (common)? MIT data says 95% of pilots delivered no P&L impact. When they describe what went wrong, you are listening for: inconsistent answers, hallucinated metrics, agents that couldn't agree — all context failures. This opens the "Agent Autopsy" or "Context Lab Sprint" conversation naturally.

"Have you spoken to Kanerika, Emergent Software, MILL5, or any other Fabric IQ partner? What did they tell you?"

If yes → you now know what's already been proposed. If they spoke to Kanerika, they've seen a BI audit. If they spoke to Emergent/MILL5, they've had a Fabric IQ explanation. Your job is to show the next layer: domain-specific ontology IP and a proof-before-production sprint model. Never dismiss the competitor — acknowledge their strengths, then show what's different.

"When your M365 Copilot or data agents give wrong answers about business metrics, where does your team think the problem is coming from?"

If they say "the model" → educate: the +12.1% NL2SQL accuracy gain from Fabric IQ Ontology comes from context quality, not a better model. Reframes the conversation from an AI problem (which they can't fix) to a context engineering problem (which you solve). This is the single most useful reframe in the playbook.

"Do different teams in your organisation define the same metric differently? For example, does 'revenue' mean the same thing to finance as it does to sales?"

Almost always yes. This surfaces the semantic consistency problem without using technical language. Follow up: "That disagreement lives in people's heads and in Confluence today. What would it mean for your agents to share one definition that's governed and versioned?" → Domain Vocabulary Sprint conversation.

"Are you on the old or new Fabric IQ Ontology experience? Have you seen the January 31st retirement notice?"

If on old experience and unaware of the deadline → burning platform they didn't know existed. Immediate entry: "We can handle the migration in 4 weeks. More importantly, we can build your production-grade context layer while we're in there — at no incremental cost for the migration work."

"Where does your business glossary live today — Confluence, Excel, Purview, or people's heads?"

Confluence / Excel / nowhere → this is the ontology pitch: "We make that machine-readable so your AI agents understand what 'LCR ratio' means the same way your analysts do. The glossary you already have is the starting point — not a rebuild from scratch." Connects to the Semantic Inheritance Play.

"How many AI tools or Copilot deployments are active across your departments right now — do you know?"

Most enterprise clients don't know. Anything above 3 active deployments with no shared context layer is shadow AI sprawl. Entry: "What typically happens is Finance Copilot and HR Copilot answer the same question differently because they're grounded in different data. One semantic layer fixes this across all of them." → Shadow AI Consolidation motion.

"Do you have AI governance constraints on which LLMs you can use in production — internal policy, DORA, FCA, SR 11-7?"

If yes → unlocks the non-Microsoft LLM via MCP play: "Your approved model — Claude, GPT-4.1, or Gemini — connects to your governed Fabric Ontology through a standard MCP endpoint. You don't need to use Microsoft's models. The semantic layer is yours." Directly counters the "we can't use Azure OpenAI" blocker.

"Is your data currently ready for an AI pilot — or are there sensitivity or governance reasons that make you hesitant to expose it?"

If data sensitivity is the concern → Synthetic Domain Data Lab: "We run the pilot on domain-specific synthetic data that statistically mirrors your production patterns but contains no real PII or sensitive positions. You get proof of value without touching your actual data." This unblocks the single most common pilot stall in BFSI and Healthcare.

"If I could show you a business user asking a complex question — in natural language — and getting a correct, sourced, auditable answer in under 30 seconds, who in your organisation would care most about that?"

Identifies the economic buyer and the use case. CDO response → executive conversation. Risk team response → Regulatory Reasoning Agent. Trading desk / operations → Operations Agent. CFO / Finance → Copilot Remediation Sprint. The answer determines which motion to lead with in the follow-up proposal.

Objection Handling

How to respond — seven common plays

"Kanerika / Emergent / MILL5 already presented to us"

Acknowledge: "They're strong on the Fabric IQ platform layer — audit and implementation. That's valuable."
Differentiate: "What they haven't shown you is domain-specific ontology for your industry — a BFSI entity library or a Healthcare clinical vocabulary your SMEs will recognise."
Close: "Let us run a one-day benchmark against their proposal. We'll show you context-enriched agent output on your actual query types — before you sign anything."

"Cognizant is already pitching us context engineering"

Acknowledge: "Cognizant called this right — they've been saying 'context readiness is the constraint' since mid-2025."
Differentiate: "Their model is 1,000 generalist context engineers and a cloud-agnostic platform. It's a headcount play, not an IP play. Ask them to show you their BFSI entity type library or their Healthcare ontology — they don't have one."
Close: "We have domain ontology libraries that your risk team will recognise on first read. That's built once and improves over every engagement — it's not rebuilt from scratch for you."

"We'll build this ourselves — we have data engineers"

"The context engineering discipline is different from data engineering — it's about encoding domain knowledge, not moving data. These are different skills."
"The Fabric IQ Ontology tooling is very new. We've already built and tested the methodology across the 17 official Microsoft docs. Your team starts from zero."
Close: "Run a 2-week sprint alongside your team — at the end, you'll see exactly what it takes and what the output quality difference is. Zero commitment to production beyond the sprint."

"We're looking at Databricks AI/BI Genie instead"

"Genie is strong NL2SQL on Delta Lake. It doesn't integrate with your Power BI semantic models, your M365 Copilot, or your Teams environment — Fabric IQ does all three natively."
"If you run both — Databricks for engineering, Fabric for BI — Apache Ossie is the path to one semantic definition for both platforms. We support that too."
"Ask Databricks to show you how Genie connects to your existing Copilot Chat and Teams. That's where the conversation gets interesting."

"Fabric IQ Ontology is still in Preview — we'll wait for GA"

"Preview in Microsoft terms means fully functional with no SLA — not unstable. The Data Agent is GA and already supports Ontology as a source."
"Ontology GA is confirmed for Q1 2027. Firms in production at Preview become reference accounts at GA. Firms that wait compete with everyone who didn't."
"The old Ontology experience retires January 31, 2027 regardless. The migration has to happen. We convert it to a context engineering foundation at the same time."

"We don't have budget for this right now"

"A Context Lab Sprint is $20–25K fixed price, 2 weeks. The deliverable is a before/after proof that builds the internal business case — it funds the next phase from evidence, not a slide."
"If you have committed Azure MACC spend — which most Fabric clients do — this is MACC-eligible. No new budget approval: it consumes what you've already committed to Microsoft."
"The Jan 31, 2027 migration has to happen regardless. We bundle the sprint into the migration work at no incremental cost for the migration itself."

"Our data is too sensitive for an AI pilot right now"

"That's the most common blocker in BFSI and Healthcare — and it's a real one. We solve it with domain-specific synthetic data."
"We build a synthetic dataset that statistically mirrors your production patterns — correct entity distributions, realistic relationships, domain-accurate vocabulary — but with no real PII, no sensitive positions, no patient records."
"The pilot runs on synthetic data. The accuracy benchmark holds because the semantics are faithful. You get the proof of value without touching your actual data."

Deal Shape

How a typical engagement evolves — aligned to the gate structure

Gate	Engagement	Duration	Value	What it unlocks
Sprint	Context Lab Sprint (Semantic Clarity / Connected Data / Audit-Ready) — synthetic domain data, before/after agent output, AIRA maturity score	2–4 weeks · fixed price	$20–55K (net ~$5–30K after cloud credits)	Before/after evidence. Scoped production proposal at Day 10 milestone. Internal business case built from proof, not slides.
Context Build	Production ontology on real data — domain entity library, Data Agent deployment, Copilot / MCP integration, governance baseline (Purview + Entra Agent ID)	4–8 weeks	$60–120K	First production agent accepted by business users. Operations Agent pilot. Expansion motion to additional domains or agent types.
Expand	Additional domain ontology (second vertical), Operations Agent templates, MCP/non-Microsoft LLM integration, Multi-Agent Architecture Sprint	3–6 weeks per workstream	$30–80K per workstream	Second production agent type. Apache Ossie cross-platform advisory. Context Layer as a Service (CLaaS) subscription conversation.
Retain	Context Layer as a Service — maintained domain entity library, ontology versioning, agent monitoring, accuracy benchmarking, quarterly review	Monthly subscription	$8–20K/month	Predictable recurring revenue. Deep account lock-in through domain IP. Natural referral and reference account for next sprint in the same vertical.

Strategic Edge

Deep intelligence — competitive, regulatory, talent, partner, and platform angles

These are the signals and angles that don't fit neatly into delivery, marketing, or sales — but that a practice lead or strategy team needs to understand. They're the difference between being reactive and being ahead.

Competitive Intelligence

Fabric IQ vs the field — an honest map

Capability	Fabric IQ	Databricks AI/BI Genie	Snowflake Cortex Analyst	dbt Semantic Layer
Semantic modeling layer	Ontology (entity types, relationships, rules, metrics) + Power BI semantic model at L2	Unity Catalog (tables, views, metrics) + AI/BI Genie NL interface	Semantic Views in Snowflake + Cortex Analyst NL interface	dbt metrics layer (semantic models in YAML) — platform-agnostic
AI query interface	✓ Data Agent (NL2DAX + NL2SQL + NL2KQL) — GA; Ontology source Preview	✓ AI/BI Genie (NL2SQL) — strong; Delta Lake depth	✓ Cortex Analyst (NL2SQL) — strong; cross-cloud	✗ Not native — requires a BI tool on top
Real-time / streaming	✓ Eventhouse KQL + Operations Agent (5-min evaluation) — native	Structured Streaming via Delta Live Tables — engineering-heavy	Snowflake Streams + Dynamic Tables — capable but complex	✗ Batch only in dbt core
Microsoft 365 / Teams integration	✓ Native — Fabric IQ in Copilot Chat GA; Operations Agent Teams notifications	✗ None — separate Microsoft integration required	✗ None native	✗ None
MCP / Agent protocol	✓ Live MCP endpoint per Ontology item — Claude, GPT-4.1, Gemini 2.5 Pro confirmed	Databricks AI agent framework — capable but not MCP-native	Not confirmed as of Oct 2026	✗ Not native
Open semantic standard	✓ Apache Ossie co-founder; DAX as Ossie query language; RDF/OWL export	Delta Sharing (data, not semantic layer); not Ossie	✓ Apache Ossie co-founder; Snowflake Semantic View → Ossie	✓ YAML-native — already effectively an open standard; Ossie alignment likely
Enterprise governance	✓ Purview DLP + access restriction; Entra Agent ID; sensitivity labels; Fabric workspace IAM	Unity Catalog governance — strong but Microsoft-ecosystem integration weaker	Snowflake RBAC + column masking — strong for Snowflake-native; less so cross-platform	Governance depends on the BI/data platform underneath dbt
Where Fabric wins	Microsoft ecosystem clients; M365 Copilot grounding; real-time + BI unified; regulated governance with Purview + Entra	—	—	—
Where Fabric loses	Raw engineering flexibility (Databricks wins); multi-cloud neutrality (Snowflake wins); pure open-source credibility (dbt wins)	—	—	—

Presales implication: Databricks accounts are engineering-led; lead with the M365 Copilot and Operations Agent integration story — things Databricks cannot match. Snowflake accounts are data-platform-neutral; lead with Apache Ossie and the "define once, deploy to both" message. dbt accounts are open-standard advocates; lead with Ossie co-founding and RDF/OWL export — Fabric is the most open-standard-aligned Microsoft product ever shipped.

Talent Strategy

What to hire vs train vs watch

Hire externally now

Ontology / knowledge graph modeller: RDF/OWL background; academic or enterprise knowledge graph experience; rare but exists in BFSI data governance teams
Azure AI Foundry specialist: someone who has built production custom agents — the Foundry IQ path requires Azure AI Search architecture that most Fabric engineers haven't touched

Train from existing team now

Power BI semantic model authors → Ontology engineers: the closest skill match — they already think in entity types, relationships, and measures; ontology is the next step
Data engineers → Context engineers: the discipline is different but the rigour is the same; hardest part is writing good natural-language descriptions that improve AI accuracy
Solution architects → Agent topology architects: the 6-integration-path decision matrix is learnable in one intensive workshop; pair with the official Microsoft Learn docs

Watch — don't hire yet

MCP protocol engineers: skills are too scarce and expensive right now; the MCP configuration for Ontology is a config task, not a programming task — train existing engineers
Ossie specification authors: the standard is still in Apache Incubator and too nascent for a dedicated specialist hire; monitor for 2027
Data Engineering Agent (Osmosis) specialists: the tool is in Preview; skills don't exist yet; position for oversight, not specialisation, in 2026

Regulatory Angle

The BFSI compliance accelerator story

Fabric IQ governance features are not just technology capabilities — they are compliance evidence artefacts. This is the angle that elevates the conversation from IT to the risk function and the board.

BCBS 239 — Risk Data Aggregation

BCBS 239 requires documented, auditable lineage from source data to regulatory reports
Fabric IQ Ontology provides: entity definitions with source bindings (which lakehouse table, which semantic model measure), version history with restore, deployment pipeline audit trail
Combined with Microsoft Purview lineage: the chain from raw source to LCR/NSFR calculation to regulatory submission is documented and machine-readable
Pitch: "Your BCBS 239 lineage artefact is the ontology. We build it once; it satisfies both your AI grounding requirement and your regulatory documentation requirement."

DORA — ICT Risk & Operational Resilience

DORA (effective Jan 17, 2025, EU) requires ICT risk management documentation and real-time operational monitoring of critical functions
Fabric Operations Agent: monitors operational KPIs in real-time, triggers Teams alerts, maintains audit log of rule evaluations
Ontology-backed rules provide the "documented policy" evidence DORA requires — rules stored as named, version-controlled natural-language artefacts in the ontology
Pitch: "Your operational monitoring policy is the business rule in the ontology. Your Operations Agent is the enforcement mechanism. DORA requires both; we deliver both in the same engagement."

SR 11-7 — Model Risk Management

SR 11-7 (US Federal Reserve) requires that models used in risk decisions have documented definitions, consistent application, and independent validation
Fabric IQ Ontology metrics: every DAX measure used in a risk model is proxied through the ontology — same certified DAX expression used by every consuming agent, every time
The ontology's metric proxy pattern ensures model consistency across Data Agents, Operations Agents, and custom MCP clients — a single source of truth for the calculation
Pitch: "When your LGD model runs through a Data Agent, an Operations Agent, and a custom dashboard — they all use the same certified DAX. That's SR 11-7 model consistency by design."

Databricks Deep Dive

Databricks — the most important competitor to understand

Databricks is the most likely platform you will encounter alongside Fabric in enterprise accounts. Unlike Snowflake (data platform) or dbt (semantic layer tool), Databricks is building a full-stack agentic data platform — and it is moving fast. Understanding its trajectory is essential for both competitive positioning and identifying co-existence opportunities.

What Databricks is building — the semantic stack

Unity Catalog: the semantic foundation — tables, views, functions, ML models, volumes, and metrics all governed under one catalogue. The Databricks equivalent of Fabric's OneLake + Purview + Power BI semantic model combined.
AI/BI Genie: conversational NL2SQL interface over Unity Catalog data — users ask questions, Genie generates SQL and returns results. Strong accuracy on well-described Unity Catalog tables.
Mosaic AI: the agent runtime — tool calling, RAG pipelines, LLM serving (including external models), Agent Evaluation framework. The Databricks equivalent of Azure AI Foundry.
Lakehouse Monitoring: data quality, model drift, and pipeline health monitoring — the Databricks equivalent of Fabric Operations Agent but engineering-focused, not business-goal-focused.
Delta Sharing: open protocol for sharing live data across platforms — not a semantic layer standard, but relevant when clients need to share data between Databricks and Fabric.

Where Databricks is genuinely stronger

Engineering-grade compute and flexibility: Spark, Delta Lake, MLflow, DLT — unmatched for complex transformations, ML training, and large-scale data engineering. Fabric's engineering layer is improving but not at parity.
LLM agnosticism: Databricks serves any model — Llama, Mistral, GPT-4, Claude — with first-class tool calling. Mosaic AI does not favour Microsoft models the way Fabric IQ does.
Multi-cloud native: runs on AWS, Azure, and GCP with identical feature parity. Fabric is Azure-only. For clients on AWS or multi-cloud, this is a decisive advantage.
Open source credibility: Delta Lake, MLflow, Unity Catalog open source — Databricks is trusted by engineering teams that distrust proprietary lock-in.
AI/BI Genie accuracy: Genie performs strongly on well-modelled Unity Catalog tables — competitive with Fabric Data Agent on NL2SQL for structured data scenarios.

Where Fabric IQ wins against Databricks

Microsoft 365 integration: Fabric IQ grounds M365 Copilot Chat, Teams notifications (Operations Agent), and Outlook/Word Cowork — Databricks has zero native integration with the Microsoft productivity suite.
Business user interfaces: Power BI, Agentic Apps, and Copilot Chat are consumer-grade BI interfaces. Genie is still developer-adjacent — it requires well-structured Unity Catalog tables and technical setup.
Real-time + BI unified: Fabric's Eventhouse (KQL) + Power BI semantic model + Ontology in one platform is unique. Databricks requires external Kafka/streaming tooling and a separate BI layer (Tableau, Power BI, or Databricks SQL dashboards).
Ontology as a first-class item: Fabric's entity-relationship-rule-metric model with natural language rules and MCP endpoint has no equivalent in Unity Catalog. Unity Catalog has table comments and column descriptions — not an ontology.
Governance for regulated industries: Purview DLP, sensitivity labels, Entra Agent ID, compliance with Microsoft's existing enterprise agreements — significantly easier to approve in a BFSI compliance review than Databricks' governance model.

The most common account pattern — co-existence

The most common enterprise reality is Databricks for engineering + Fabric for BI and agents — not a winner-takes-all choice.
Databricks handles: complex ETL, ML training, feature engineering, large-scale transformations — the data preparation layer.
Fabric handles: semantic models, ontology, Data Agents, M365 Copilot integration, business-user-facing intelligence — the consumption layer.
Delta Lake tables in Databricks can be mirrored into Fabric OneLake via OneLake shortcuts or mirroring — the data doesn't move, the semantic layer sits on top.
Positioning in co-existence accounts: "We're not here to replace Databricks — we're here to make your Databricks data consumable by business users and AI agents through Fabric IQ. Your engineering investment stays; we add the intelligence layer."

Databricks trajectory — what to watch

Genie → Compound AI: Databricks is investing in multi-step agentic reasoning over Unity Catalog — this will close the gap with Fabric Data Agent's multi-source ontology queries over the next 12–18 months.
Unity Catalog open source (as of mid-2024): making Unity Catalog vendor-neutral and multi-cloud strengthens Databricks' governance story — watch for enterprises citing this as a reason to avoid Fabric's proprietary governance model.
Apache Ossie: Databricks has not announced Ossie support as of Oct 2026 — this is a gap that Microsoft and Snowflake are exploiting. If Databricks joins Ossie, the cross-platform semantic standard becomes universal and reduces Fabric's differentiation there.
Microsoft partnership: Databricks and Microsoft have a co-sell agreement — Azure Databricks is an Azure-native service. Some Microsoft field sellers promote both. Don't assume Microsoft field = Fabric-only.

Sales plays against Databricks-led accounts

The integration play: "Your Databricks data is already in Delta Lake. We can mirror it into Fabric OneLake with zero data movement and build a Fabric IQ Ontology on top. Your engineers keep Databricks; your business users get Copilot and agents."
The governance play: "In a BFSI environment, your compliance team needs to approve the AI governance model. Fabric's Purview + Entra Agent ID + Microsoft enterprise agreement is a known, approved framework. Databricks' governance model requires a separate review."
The M365 play: "Every employee in your firm already has M365 Copilot. Grounding Copilot Chat in your Fabric data takes 8 weeks. Grounding it in Databricks data has no native path."
The semantic richness play: "Genie works well on described tables. Fabric IQ Ontology adds entity types, relationships, business rules, and real-time bindings — a richer semantic model that produces more reliable answers on complex, multi-source business questions."

Partner Ecosystem

The ISV and partner opportunity

What to build as commercial IP

BFSI Ontology Template Library: pre-defined entity types, properties, relationships, and business rules for IRB, LCR/NSFR, trade lifecycle, customer 360, operational risk — license per engagement rather than build from scratch
Semantic Readiness Scorecard tool: a lightweight Fabric notebook that audits Power BI semantic models and scores them on 5 readiness dimensions — deployed as part of the assessment; generates the gap analysis automatically
Context Engineering Playbooks: domain-specific topic libraries and example query sets for BFSI Data Agents — reduce the 6-layer context setup time from weeks to days

Azure Marketplace strategy

List the Fabric IQ Onboarding Accelerator as a Transact offer — MACC-eligible, reducing client procurement friction
Target: listed before Ontology GA announcement, so your firm appears in Microsoft's GA marketing materials as a certified delivery partner
Explore the Microsoft Intelligent Data Platform partner designation — highest-tier Fabric partner recognition, unlocks Microsoft field co-sell eligibility

GSI risk — and the response

Accenture, Deloitte, and KPMG will build Fabric IQ practices; they will arrive with bigger budgets, more headcount, and stronger C-suite relationships
The window: they are generalists; they won't have BFSI-specific ontology templates or SR 11-7/DORA-specific playbooks for 12–18 months after Ontology GA
The response: be the specialist that the GSIs subcontract for domain-specific ontology work. Become the firm GSIs call when a BFSI client asks for Fabric IQ — not a competitor, a sub-contractor and eventually a referral channel

Three questions leadership should be asking every quarter

1. How many clients have a production Fabric IQ Ontology? This is the leading indicator of semantic services revenue — more ontologies in production = more agent deployment, managed services, and expansion opportunities
2. What is our context engineering accuracy benchmark? Track the NL2SQL/NL2DAX accuracy improvement we deliver vs the baseline — this becomes a publishable case study and differentiator
3. Are we ahead of or behind Microsoft's product timeline? If Ontology GA caught us by surprise, we're behind. The goal is to always be in the Insider programme and shipping client deployments before GA marketing noise begins