Operations Agent in Microsoft Fabric — Complete Guide
Everything you need to know about the Operations Agent in Microsoft Fabric — from setup and KQL data sources to governance, known limitations, and real-world use cases. Verified against official Microsoft documentation.
The Operations Agent is a feature in Microsoft Fabric’s Real-Time Intelligence (RTI) platform. It monitors KQL database tables in Eventhouse, evaluates detection rules every 5 minutes, and sends context-rich alerts to Microsoft Teams. Recipients can approve or reject recommended actions — which then trigger Power Automate flows via Activator. Currently in public preview. Only regular Eventhouse tables are supported — no lakehouses, warehouses, shortcut tables, or materialized views.
The Operations Agent in Microsoft Fabric is not generally available. Trial capacities are not supported — you need a paid Fabric capacity. Validate thoroughly before using it in production-critical monitoring. Keep a manual fallback process running alongside it.
What Is the Operations Agent in Microsoft Fabric?
The Operations Agent is a Fabric item inside the Real-Time Intelligence (RTI) workload. You create one per business process — one for API health, one for payment pipeline reliability, one for inventory thresholds. Each agent watches a KQL database in Eventhouse, evaluates the rules you define, and surfaces recommendations to your team in Microsoft Teams.
The difference from passive monitoring: the Operations Agent doesn’t wait for someone to look at a dashboard. It queries your data every five minutes, runs LLM-based reasoning over the results, and sends a Teams message with a plain-English explanation of what happened and what to do about it. The recipient reviews, optionally adjusts parameters, and taps Approve or Reject. The underlying action — a Power Automate flow — only fires after that approval.
That human-in-the-loop design is intentional. The agent proposes; a person decides. Nothing irreversible happens automatically.
RTI is organized around a clear pipeline: Eventstream handles ingestion and routing, Eventhouse/KQL database handles storage and querying, Activator handles no-code threshold-based alerting, and the Operations Agent sits at the reasoning layer — using an LLM to interpret telemetry and generate context-rich recommendations rather than just firing raw threshold alerts.
The Operations Agent is not a replacement for Activator. Activator is the right tool when you need sub-minute alerting on hard thresholds with no reasoning involved. The Operations Agent earns its place when the situation is more nuanced — when you need context, not just a number that crossed a line. Use both. They solve different parts of the same problem.
Operations Agent Prerequisites — What You Need Before Starting
Before creating an Operations Agent in Microsoft Fabric, confirm every item below. Missing any one of these will block you mid-setup.
| Requirement | Detail | Status |
|---|---|---|
| Fabric-enabled capacity | A paid F-SKU or P-SKU. Trial capacities are not supported. | Required |
| Eventhouse with KQL database | Must be in the same workspace as the Operations Agent item. | Required |
| Microsoft Teams account | All notifications and approvals go through the Fabric Operations Agent Teams app. | Required |
| Copilot/AI tenant setting | Must be enabled by a Fabric admin for your tenant. | Required |
| Operations Agent tenant setting | A separate tenant-level toggle your Fabric admin must enable. | Required |
| Same-region capacity | Fabric tenant and capacity must be in the same region. Cross-region causes Power Automate action errors. | Required |
| Cross-geo AI processing | If your Fabric capacity is outside the US or EU, a cross-geo processing setting must be enabled. | If applicable |
The Operations Agent in Microsoft Fabric is not available in South Central US and East US Fabric regions as of June 2026. Check the official documentation for the current region list before provisioning capacity.
How to Set Up the Operations Agent in Microsoft Fabric
The setup process has two distinct phases: configuring the agent and connecting the action flows. Both need to be complete before the agent goes live.
- Create the Operations Agent itemOn the Fabric home page, select the ellipsis (…) → Create → Real-Time Intelligence → Operations agent. Give it a specific name reflecting the process it monitors, such as Payment Pipeline Monitor or API Latency Watcher. Select your workspace.
- Write your business goalsDefine the high-level outcomes in plain English. Be specific — “Keep p95 API latency under 1,200ms” is more useful than “monitor latency”. The LLM uses these goals to orient its reasoning and generate the underlying KQL playbook.
- Write operational and semantic instructionsOperational instructions are your detection rules: “Alert when error rate exceeds 2% over a 5-minute window.” Semantic instructions explain your data: “The ApiTelemetry table tracks per-service metrics. The column p95_latency_ms is the 95th percentile response time in milliseconds.” Separate each rule onto its own line.
- Connect a KQL database knowledge sourceSelect the Eventhouse and KQL database the agent will query. Only regular tables are supported — shortcut tables, functions, and materialized views will not work. Flatten any nested JSON columns before this step.
- Define the actionsName each action and describe its purpose clearly. Actions can include scaling resources, opening tickets, sending emails, or calling external APIs. Optionally define adjustable parameters — for example, a scale factor the approver can modify before confirming.
- Connect actions to Power Automate flows via ActivatorFor each action, copy the generated connection string from Fabric into a Power Automate flow. Save the flow. This is the mechanism that fires when a recipient approves a recommendation.
- Save and review the generated playbookOnce saved, Fabric uses the LLM to generate an operations playbook — the actual KQL rules and reasoning logic derived from your instructions. Review this carefully. The model can misinterpret ambiguous instructions. Verify column names and table references match your actual data.
- Install the Fabric Operations Agent Teams appRecipients of notifications must have the Teams app installed. They must be in your organization and hold write permissions on the agent item in Fabric. The creator’s credentials are used for all queries and actions — not the recipient’s.
- Select Start to begin live monitoringThe agent immediately begins querying your KQL database every five minutes. Validate the first few alerts before treating it as production-ready.
On the Query insights tab of your KQL database, you can see every query the Operations Agent executes. This is the most reliable way to validate that the LLM correctly interpreted your instructions and is querying the right tables and columns.
The instructions step is where most teams get it wrong the first time. Vague goals like “monitor performance” produce vague playbooks. Quantifiable, specific instructions produce reliable detection rules. Write instructions the same way you’d write acceptance criteria for a developer: specific conditions, named columns, numeric thresholds, no ambiguity.
Operations Agent Supported Data Sources
This is one of the most important constraints to understand before planning any Operations Agent deployment.
Supported
- Regular KQL database tables in Eventhouse
- Eventhouse in the same Fabric workspace as the agent
- Flat table schemas with descriptive column names
- Fabric Ontology as data source (same workspace only)
Not Supported
- Lakehouse tables
- Data Warehouse tables
- External databases
- Shortcut tables within Eventhouse
- KQL functions
- Materialized views
- Nested / JSON columns
The Operations Agent only queries data through KQL. If your telemetry currently lands in a Lakehouse, you need a pipeline to stream it into Eventhouse via Eventstream before the agent can monitor it. Plan for this ingestion layer before setting up the agent.
Nested column structures — JSON blobs, dynamic columns with sub-properties — cause the LLM to generate incorrect or incomplete KQL rules. Flatten all tables to a simple column-per-field schema before using them as an Operations Agent knowledge source. Descriptive column names significantly improve rule accuracy.
How the Operations Agent in Microsoft Fabric Works — End to End
- Telemetry ingestionApplications, infrastructure, IoT devices, or third-party platforms stream events into Fabric via Eventstream, Azure Event Hubs, or IoT Hub. Data lands in Eventhouse KQL tables optimized for time-series queries.
- Scheduled evaluation every 5 minutesThe Operations Agent executes KQL queries against your database on a fixed 5-minute polling cycle. It evaluates the rules derived from your instructions against the latest data.
- LLM-based reasoningWhen data matches a defined condition, the agent uses an LLM (Azure OpenAI) to generate a context-rich, plain-English explanation of what happened, why it matters, and what action it recommends. This is what appears in the Teams message.
- Teams notification with recommendationA message arrives in Teams through the Fabric Operations Agent app. It shows the data context, the recommended action, and any adjustable parameters. The recipient can modify parameters before acting.
- Human approvalThe recipient taps Approve or Reject. If approved, the connected Power Automate flow fires using the creator’s credentials. If nobody responds within three days, the recommendation is automatically canceled and cannot be acted on.
- Playbook audit trailEvery detection, reasoning step, recommendation, and action outcome is logged in the operations playbook. This is your audit record for incident reviews, compliance, and continuous improvement.
Unapproved recommendations are automatically canceled after three days. If your on-call team works in shifts or has coverage gaps, make sure multiple recipients are configured. An unanswered recommendation is a missed response window — not a queued action.
The Operations Agent runs all queries and executes all actions using the creator’s identity and permissions. This applies to both data access and Power Automate flow execution. If the creator leaves the organization or has their permissions revoked, the agent stops working. Use a service account identity where possible — and document the creator dependency before deployment.
Operations Agent vs Data Agent in Microsoft Fabric
Microsoft Fabric has two AI agent types that are easy to conflate. They solve different problems and are designed for different teams.
They work well together. The Operations Agent fires an alert in Teams; a Data Agent helps you dig into the underlying data to understand why it happened.
Operations Agent Use Cases in Microsoft Fabric
These are the scenarios where the Operations Agent in Microsoft Fabric delivers the most practical value.
SRE & DevOps Incident Response
Detect latency spikes, error surges, or service degradations and recommend scale-out or restart actions — before customers open support tickets.
Data Pipeline Reliability
Monitor ETL and streaming workflows. Alert when ingestion lag exceeds thresholds or expected data volumes drop unexpectedly.
Cloud Cost Optimization
Detect idle compute resources during off-peak hours and recommend scale-down actions to reduce Fabric capacity spend.
Payment & Transaction Alerts
Alert revenue teams when transaction volumes drop, conversion rates slip, or payment failure rates cross defined thresholds.
Incident Investigation Context
Enrich alerts with deployment version, config change context, and baseline comparisons — giving on-call engineers a head start on root cause analysis.
Supply Chain & Inventory
Monitor product availability in real time and trigger replenishment workflows the moment any SKU drops below a critical threshold.
Operations Agent Limitations — Confirmed Constraints from Microsoft
These are current, confirmed limitations from official Microsoft documentation — not theoretical edge cases. Plan around them before deploying.
The Operations Agent is not generally available. The feature set, limitations, and regional availability will change as it moves toward GA. Check the official limitations page before any production deployment and keep a manual fallback monitoring process running in parallel.
Operations Agent FAQ
Operations Agent Resources — Official Microsoft Documentation
All links below go directly to official Microsoft Learn documentation. No third-party summaries.
This guide is verified against Microsoft Learn documentation as of June 2026. The Operations Agent is in public preview — features, limitations, and regional availability will change. Always check the official documentation before deployment. UIG Data Lab is an independent publication, not affiliated with or endorsed by Microsoft Corporation.
