Pyrana and Microsoft Fabric

Architecture

Fabric and Pyrana answer different questions. Fabric answers "what does our governed data say?" It ingests, stores, models, secures, and visualizes data in one SaaS platform over OneLake. Pyrana answers "given that data, our documents, and our policies, what should happen next, who must approve it, and can we prove why?" It is the application layer where people and agents act on the data.

Fabric is delivered as SaaS with workloads for Data Factory, Data Engineering, Data Science, Data Warehouse, Databases, Real-Time Intelligence, Power BI, and Fabric IQ (preview), all over OneLake, a tenant-wide logical lake built on Azure Data Lake Storage. Shortcuts reference data in Azure, Amazon S3, and Google Cloud Storage without copying it, and mirroring replicates Azure SQL, Cosmos DB, Databricks, and Snowflake into OneLake. The OneLake catalog and Microsoft Purview govern it.

Pyrana's seven layers (harness, Temporal orchestration, tool sources, tool approval policies, durable storage, the context engine, and the frontend surface layer) sit above whatever data platform the client runs. Pyrana does not need to store source data. Its agents query Fabric live, and the platform stores only what the application produces: versioned outputs, curated knowledge, and audit records.

Why not build the agents directly in Fabric?

For read-only questions over governed tables, do: Fabric data agents are designed for exactly that. The question changes when agents must act. On the Microsoft stack, an application that drafts, routes, approves, and records is assembled from several services (Fabric for data, Microsoft Foundry and Foundry Agent Service for agents, Microsoft Agent Framework for orchestration code) plus an application the team builds. Microsoft provides capable building blocks. Pyrana is that application layer already built, running on Azure.

Context and knowledge

Fabric holds structured business context: tables, Power BI semantic models with measures, and in preview, ontologies that define entity types, relationships, rules, and metrics bound to live data. Pyrana's cortIQ holds the knowledge that is not in tables: policies, procedures, contracts, and tribal rules, as classified Context Units with evidence passages and content-addressed citations.

The two are complementary. Fabric IQ's ontology can be generated from existing semantic models, imported from RDF or OWL, and explored as a graph, so agents reuse trusted DAX measures instead of recomputing them. Fabric data agents do not read unstructured files such as PDF, Word, or text documents; Microsoft covers documents through Foundry IQ, which it places alongside Fabric IQ in Microsoft IQ. cortIQ adds governance to that document layer: each unit carries a knowledge type, a classification that controls how it may change, an evidence grade, and a quality score, and every run records which units were retrieved, injected, and cited.

Agent capabilities

Fabric ships three kinds of AI help. Copilot in Fabric assists authors in each workload (notebooks, pipelines, SQL, KQL, Power BI). Data agents answer natural-language questions over up to five sources. Operations agents watch live data and recommend actions. Pyrana runs agents inside business workflows that fan out per entity, call job-specific tools, and publish versioned outputs.

Fabric data agents are generally available. They choose among lakehouses, warehouses, semantic models, KQL databases, ontologies, and Microsoft Graph, generate SQL, DAX, or KQL, and run read-only queries with the asking user's credentials. Microsoft documents limits that shape their role: responses cap at 25 rows and 25 columns, the model cannot be changed, questions should be in English, and queries never create, update, or delete data. Data agents publish to Microsoft 365 Copilot, Teams, Copilot Studio, and Foundry, and each published agent is also an MCP server.

Operations agents (preview, in the Fabric IQ workload) evaluate rules every five minutes against an eventhouse or ontology, send Teams messages, and can run configured actions when a recipient approves, using the creator's delegated permissions under an Entra agent identity.

Governed actions and approvals

Fabric's agents are designed to inform and recommend: data agents are strictly read-only, and operations agents run an action after a recipient approves it in Teams. Pyrana is designed to act: a tool approval policy over typed arguments decides which invocations need a person, freezes the exact operation, and routes it to a named approval lane.

In Pyrana, thresholds, membership checks, and compound rules decide when a person is needed. Reviewer eligibility is checked at decision time, the frozen invocation is revalidated before dispatch, and dispatch is idempotent. A queued request looks different from a posted entry. The approval applies to the operation whether a page, the copilot, a schedule, an agent, or an external system requested it.

Building the application

Fabric's business-facing surfaces are Power BI reports and apps, Copilot for Power BI, and data agents in Microsoft 365. Pyrana's surface is an application: declared pages where people work, a copilot that receives the exact page context, personal pages people ask the copilot to build, an API, and an MCP server.

Fabric supports Git integration and deployment pipelines for data agents and other items. Pyrana compiles one App configuration into immutable versions; an App owner activates a version, and rollback is activating a prior one. With clean data in Fabric, a Pyrana application typically stands up in about a week, and the frontend is the main effort.

Governance and security

Fabric governs data: Entra ID, workspace roles, OneLake security, row-level and column-level security, sensitivity labels, and Purview data loss prevention, audit, and eDiscovery, with Purview protections for data agents in preview. Pyrana governs actions: one eight-step gate per call, layered access from tenant to approval lane, and an audit record written before dispatch.

These layers stack. When a data agent answers, Purview policies and the user's permissions still apply. When Pyrana calls Fabric, tool policies map the caller's scope entitlement to tool arguments before the call, and Fabric's own security applies to the identity the connection uses. Pyrana is SOC 2 aligned, runs on Azure with Entra ID SSO and Azure OpenAI, and keeps customer data in the client's cloud.

Operations

Fabric monitors capacity consumption, data agent diagnostics, and operations agent activity logs. Pyrana captures every run's traces, tokens, and tool errors as JSON, runs a data quality check before an agent run starts, and checks outputs with deterministic tests and LLM-as-judge evaluation.

Cost structure

Fabric is priced by capacity: F SKUs measured in capacity units, pay-as-you-go or reserved, with Microsoft citing about 41 percent savings for one or three year reservations. Copilot in Fabric and data agents consume that capacity and require F2 or higher. Pyrana is a platform subscription plus implementation, added on top.

Fabric capacity is needed either way if Fabric is the data platform. So the real decision is between funding an in-house build of the application layer (agent runtime, orchestration, approvals, storage, authorization, audit, frontend) on Foundry and Agent Framework, or adopting one. A first Pyrana engagement, including SSO, access profiles, the approval policy, and loading the policy library, runs about six weeks.

What it takes to ship the same application

Reference application: an approval-gated procurement request. A person or agent drafts a purchase request using spend and budget data in Fabric; amounts above a threshold need a finance approver; the request waits durably for the decision; everything is recorded.

Drawn from documentation; build effort has not been benchmarked.

Using them together

Pyrana runs on Azure, uses Azure OpenAI and Entra ID, and can call Foundry-hosted models and agents, so it sits inside the same Microsoft estate as Fabric. Fabric stays the data foundation and dashboard surface. Pyrana is one application layer above it.

• Fabric SQL as a tool source. Warehouses and lakehouse SQL analytics endpoints accept SQL connections over TDS with Entra user or service principals. Pyrana's ODBC tool source binds job-specific tools to curated views, so agents pass an entity and a period and the tool holds the query.
• Fabric data agents as MCP tools. A published data agent is an MCP server with one tool. Pyrana can bind it as an MCP tool, so an ontology-grounded answer arrives through Pyrana's gate and audit record.
• Clean views upstream. Fabric pipelines and notebooks prepare the data; Pyrana runs a data quality check before each agent run.
• Outputs back to the Microsoft estate. Pyrana can deliver outputs to OneDrive and systems of record, where Power BI, Copilot Studio, and Microsoft 365 can pick them up.
• Other platforms alongside. The same Pyrana application can also read Databricks and Snowflake, with the user's principal passed through to their row-level security.

Where Fabric is the right tool

Keep these in Fabric; Pyrana consumes them and does not replace them: ingestion and mirroring, the lakehouse and warehouse, semantic models and the metrics layer, Power BI dashboards, Purview catalog, lineage, and data loss prevention, Real-Time Intelligence, the Fabric IQ ontology, and data agents for quick read-only questions.

When not to add Pyrana

• The goal is dashboards and analytics, and no process ends in an action.
• A Fabric data agent in Microsoft 365 Copilot or Teams answers the questions people ask.
• An operations agent that alerts one person and runs an approved action covers the workflow.
• Your engineering team has chosen to build the application layer on Microsoft Foundry and Agent Framework and has capacity to run it.
• All required context lives in Fabric tables and semantic models, with no policies or documents to govern.