Product

Fabric Builder

The AI an engineer brings to your Fabric estate.

Built on the Governor pattern — read the platform thesis.
01 · Executive summary

The foundation your business runs on

Your company’s data model is its foundation. Measures, dimensions, relationships — when that’s clear, everything downstream works; when it drifts, everything else cracks.

Fabric Builder is the AI an engineer brings to your Fabric estate. A coder, not a governor — it refines its skills and its memory on the engineer’s corrections and the estate’s evolution. An engineer — yours or one of ours — operates Fabric Builder to probe your existing infrastructure (SQL, APIs, warehouses, SaaS), build the dataflows, Power BI reports, semantic models, and Fabric Data Agents your team needs, and tend the estate over time: monitoring data health, auditing security, verifying visuals, surfacing insights. The engineer directs. Fabric Builder works. GitHub holds the shared plan.

Your data team never talks to Fabric Builder. They talk to the Fabric Data Agents it creates — grounded in your knowledge graph, ready to answer.

We did it for our own e-conomics and Business Central data. It works the same way for any source you bring us. Your data stays in your Microsoft 365 tenant. Your foundation grows with you.

02 · Capabilities

What an engineer can do with Fabric Builder

Fabric Builder runs a three-phase cycle — Build, Use, Tend. Most “AI for data” products stop at Build and Use. Tending is the differentiator.

Phase 01 · Build

Onboard a data source

Fabric Builder probes existing infrastructure, generates embeddings, and produces the dataflow, Power BI reports, semantic model, Azure AI Search knowledge graph, and Fabric Data Agent.

Phase 02 · Use

Answer the data team

The data team asks questions in natural language. The Fabric Data Agent answers, grounded in the RAG pipeline and the semantic model Fabric Builder built.

Phase 03 · Tend

Keep the foundation sharp

The differentiator. Monitor data health, audit security, verify visuals, surface insights — the model stays sharp as the business evolves.

Seven verbs the engineer operates across those three phases — each grounded in the tenant, each auditable through GitHub.

03 · Architecture

How it fits together

Proven on
  • Konica Minolta Nordic BI — Databricks estate Where the pattern was forged. Fabric Builder’s lineage — Lt. Dan → PBI Builder → Fabric Builder — emerged building data-platform work on the Konica Minolta Nordic BI estate on Databricks. Dataflows, semantic modeling, and the coder-refines-skills loop were all proven there first.
Adjacent integrations
  • e-conomics Frederiksberg Vinimport ApS · Fabric dataflow + Power BI semantic model built from e-conomics API data.
  • Microsoft Dynamics 365 Business Central Frederiksberg Vinimport · Runi Finance · Fabric dataflow + semantic model built from BC data.

Two views. The first shows the user story — who talks to what, where the tenant boundary lies, how Abel observes. The second zooms into the build factory — what happens during onboarding when Fabric Builder probes a new source and produces artifacts.

User story. An engineer (left) operates Fabric Builder inside the customer's Microsoft 365 tenant. Fabric Builder produces the services the data team uses. Abel (right) queries and surveils Fabric Builder via A2A. GitHub holds the shared plan between the engineer, Fabric Builder, and Abel. The data team and end users interact with the Fabric Data Agents downstream. A single red accent traces the engineer's round-trip.
User story · engineer · Fabric Builder · Abel · GitHub plan · data team downstream
Build factory. During onboarding, Fabric Builder probes existing infrastructure — SQL, APIs, warehouses, SaaS — generates embeddings, and produces four artifacts inside the customer tenant: a Fabric dataflow, a Power BI semantic model, an Azure AI Search knowledge graph, and a Fabric Data Agent.
Build factory · probe · embed · dataflow · semantic model · knowledge graph · Data Agent
04 · Engineering

Inside the build

Fabric Builder is a team of agents coordinating through MCP tools, grounded in a RAG pipeline that stays current with the customer’s data estate. The control surface is the engineer’s — every action flows through their Entra identity.

Inside the build. A team of agents (lead, workers, verifier) coordinates via MCP tools. A RAG pipeline (data dictionary, knowledge graph, embeddings, retrieval) grounds the team in the customer's data estate. Every outbound call carries the engineer's Entra identity via On-Behalf-Of tokens. All actions are traced to GitHub issues.
Inside the build · MCP tools · RAG pipeline · agent team · Entra + OBO · GitHub audit

MCP tools. Fabric Builder loads Microsoft Graph, Power BI REST, Fabric, Entra, and Purview as MCP servers. Every tool the agent team calls is an MCP invocation; every call is audited.

RAG pipeline. A data dictionary captures the vocabulary the business uses to describe its data. A knowledge graph in Azure AI Search holds the relationships. Embeddings are generated on source probes and refreshed on downstream changes. Retrieval is gated by the engineer’s identity and the tenant boundary.

Agent coordination. A lead agent plans. Worker agents run tool calls in parallel. A verifier agent checks visuals and schema before deploy. The engineer sees the plan, the tool calls, and the verification evidence in GitHub issues.

Azure services. Azure OpenAI for reasoning. Azure AI Search for the knowledge graph. Fabric for dataflows, lakehouse, and Data Agents. Power BI REST for PBIR artifacts. EU-resident where the vendor offers it.

Identity and deployment. The agent user exists in the customer’s Entra. Every outbound call to Microsoft Graph or Power BI uses On-Behalf-Of tokens — the engineer’s identity, not ours. The tenant boundary is hard; Fabric Builder cannot read or write outside it.

Observability. Every agent action writes a trace. Traces are reviewable in GitHub issues alongside the shared plan. Errors surface to the engineer, not to the end user.

Skill and memory refinement. Fabric Builder is a coder, not a governor. It refines its skills on every correction from the engineer — what worked, what didn’t, which patterns to prefer next time — and it refines its memory on the estate’s evolution: schema changes, new sources, retired measures. The longer it runs, the sharper it gets.

Harnesses. Fabric Builder ships on two parallel paths. Claude Code is the preferred build experience — tight edit-run loops on the engineer’s workstation. The Microsoft-platform-native path runs on Copilot Studio with GPT‑5.4 plus an agent team, delivered through the GitHub Copilot CLI as the agent shell. Both harnesses share the same MCP tool surface, the same RAG pipeline, and the same tenant boundary. SDK parity is deliberate.

05 · Sovereignty

Runs in your tenant. Stays there.

Three things that matter for this product specifically: Fabric Builder runs in your Microsoft 365 tenant, your data doesn’t leave it, and the agent itself carries an Entra identity you own — created, managed, rotated, and revoked by you.

06 · Pricing

Two paths

Fabric Builder is sold two ways, because the audience is two kinds of buyer. Pick the one that matches who runs your Fabric work today.

Path A

Engage us

Runi Services brings an engineer — and Fabric Builder — to your estate for a defined scope. Fixed-fee or consumption-based. Ideal when you don’t have a dedicated data-platform engineer yet.

Enquire about engagement
Path B

Deploy for your engineers

Your engineers use Fabric Builder as their platform tool, with optional governance support from Runi Services. Licensed via Azure Marketplace once the listing is live.

Join the deploy waitlist

Pricing for either path is scoped to your data surface and Fabric tier. Contact for pricing.

07 · Get started

Two ways in