Fabric’s data agent and operations agent need two different production checklists

Microsoft Fabric’s data agent and operations agent are not two versions of the same assistant. Microsoft’s product documentation describes one as a conversational analytics surface and the other as a monitor that can recommend—and, after approval, execute—operational actions.

The data agent is an answer path

Microsoft’s data-agent documentation says the generally available feature converts natural-language questions into SQL for lakehouses and warehouses, DAX for semantic models, KQL for KQL databases, or Microsoft Graph queries. Connections are read-only, queries run with the requesting user’s credentials, and Purview controls can restrict what the agent accesses or returns.

That makes the main deployment questions familiar to analytics teams: Which sources should the agent see? Are business definitions encoded clearly? Can users inspect enough evidence to trust an answer? The same documentation says one agent supports up to five sources and can be guided with instructions and sample question-query pairs. This is a routing-and-grounding problem before it is an automation problem.

The operations agent is an action path

The operations agent has a different risk profile. Microsoft’s best-practices and limitations page says it monitors one Eventhouse or ontology source, runs queries every five minutes, requires timestamped data, and uses the delegated identity and permissions of its creator. Recommendations expire after three days if nobody acts.

Microsoft’s actions documentation says the agent can send Teams messages, run Fabric items including notebooks and pipelines, or trigger Power Automate flows. A recipient may approve a recommendation, but execution still occurs on behalf of the creator. Changing the message recipient therefore does not change the execution identity.

That shifts the production checklist. Teams should inventory what the creator account can do, narrow every downstream notebook or flow, define numeric thresholds rather than vague conditions, and review the generated KQL in Query Insights. Microsoft also warns that operations-agent outputs are probabilistic, only English instructions are supported, heavy use can fall back to simplified non-LLM Teams messages, and workspaces encrypted with customer-managed keys are not currently supported.

Share the data foundation, not the controls

The useful mental model is “ask” versus “act”: use the data agent when a person initiates a question, and the operations agent when changing data should initiate a response. Both may sit over Fabric data and both may surface in Teams, but the shared interface should not produce a shared approval process.

For practitioners, the clean boundary is simple: evaluate the data agent for answer quality, source selection, permissions and evidence; evaluate the operations agent for monitoring gaps, threshold quality, delegated identity and action blast radius. If a workflow needs both, pass an alert into a separately permissioned analytical investigation rather than treating a fluent answer as authorization to act.