A Fabric data agent and a Fabric “database agent” are two different Microsoft products that share a word. According to Microsoft’s data agent concept guide (Microsoft Learn, 2026), the data agent is generally available and answers read-only questions about your OneLake data, while the database agent belongs to Database Hub, an early-access management hub for six database engines (Azure Blog, 2026).
Microsoft’s documentation keeps these products apart; everyday conversation does not. Your analysts meet the data agent in Microsoft 365 Copilot, Teams, or Copilot Studio; your DBAs meet the database agent when Database Hub flags a change across the estate. A third product, the operations agent, lives in Real-Time Intelligence.
The two names people mix up most:
| Dimension | Fabric data agent | Database Hub’s “database agent” |
|---|---|---|
| What it is | A configurable Fabric item for conversational Q&A | The agent layer inside Database Hub |
| Status (September 28, 2026) | Generally available | Early access, then “private preview” |
| What it does | Turns questions into SQL, DAX, or KQL and returns answers | Reasons over estate-wide signals and suggests next steps |
| Access posture | Read-only, under the asking user’s permissions | Agent-assisted, with a human deciding |
| Who uses it | Analysts and business users | DBAs and database developers |
| Best for | Self-service answers over modeled data | Operating many databases from one place |
Data or databases: which does each Fabric agent work on?
What separates a Fabric data agent from a database agent is the object each one works on. The data agent works on your data: it reads tables and semantic models and answers questions about them. A database agent works on your databases: it watches how Azure SQL, Cosmos DB, PostgreSQL, and other engines behave and helps the people who run them.
Microsoft’s leadership draws the first half of that line. In the FabCon and SQLCon 2026 announcement (Azure Blog, 2026), Arun Ulag, Executive Vice President, Azure Data, Microsoft, wrote that “Fabric data agents can be thought of as virtual analysts.” The same paragraph names operations agents as the complement that monitors real-time data and takes proactive action.
“Database agent” as a phrase comes from Microsoft’s own FabCon session titles rather than its product documentation:
- Session W24, Database Agents: A New Way to Manage Databases in Fabric (ESPC, 2026), from Patrick LeBlanc of Microsoft, describes “Database Agents in Database Hub in Fabric.”
- Session W19, From 2AM Page to Action in Minutes with DB Agent (ESPC, 2026), from Brian Holt and Charles Feddersen of Microsoft, walks through a production database incident handled in VS Code.
Neither announcement blog uses “database agent” as a product name, so people leaving FabCon Europe 2026 carry a label Microsoft Learn does not index. Among the types of AI agents, a question-answering agent and a system-watching agent sit at opposite ends, though both meet the definition of what an AI agent is. The label tells you less than the object: ask what the agent reads, and what it may change.
What is a Fabric data agent?
A Fabric data agent is a generally available Fabric item that lets people ask plain-language questions about data stored in OneLake and get answers. Microsoft Learn (2026) calls it “the conversational analytics component” in multi-agent solutions on Fabric.
Under the hood, Azure OpenAI Assistant APIs pick a data source and call a tool to write the query: text-to-SQL for enterprise data, extended to DAX and KQL. It follows the talk-to-data agent blueprint pattern, and picking a tool per question is textbook AI agent tool use.
The limits are deliberate. According to Microsoft Learn (2026), each agent supports up to five data sources in any combination, and Microsoft caps responses at 25 rows and 25 columns because the agent exists for conversational insight rather than dataset export.
Microsoft also set the access bar low. According to Microsoft’s setup guide (Microsoft Learn, 2026), querying a Power BI semantic model through a data agent needs only Read permission on the model, with no Build permission or workspace role, on an F2 or higher Fabric capacity or Power BI Premium P1 or higher.
Unlike Fabric’s preconfigured copilots, a data agent is a configurable item that Azure AI Foundry agents can call, closer to a published service than an enterprise copilot.
Core components of a Fabric data agent
- Read-only enforcement: read-only connections to every source; no create, update, or delete queries.
- Three query tools: NL2SQL for lakehouses and warehouses, NL2DAX for semantic models, NL2KQL for KQL databases, plus Microsoft Graph.
- User-scoped access: queries run with the asking user’s credentials, and Purview policies still apply.
A data agent is only as accurate as the definitions it reads. The semantic layer for BI vs. AI agents question decides whether its NL2DAX answers match the numbers finance reports.
What is Database Hub’s database agent, and where does the operations agent fit?
Database Hub is Fabric’s unified management experience for operational databases, and its database agents are the layer that watches them. According to the March 18, 2026 announcement (Azure Blog, 2026), it covers Azure SQL, Azure Cosmos DB, Azure Database for PostgreSQL, SQL Server enabled by Azure Arc, Azure Database for MySQL, and Fabric databases, without changing how each is deployed.
Microsoft’s Fabric Community blog post (Microsoft, 2026) calls the approach “agent-assisted, human-in-the-loop”: agents reason over estate-wide signals to surface what changed, explain why it matters, and guide teams toward a next step.
Database Hub launched in early access on March 18, 2026, and Microsoft’s Build 2026 announcement (Azure Blog, 2026) on June 2 still called it “currently in private preview.”
The operations agent is a separate, documented product: according to Microsoft Learn (2026), a Fabric item in Real-Time Intelligence that monitors an eventhouse or ontology, runs each rule’s query every 5 minutes, and messages you in Teams. Arun Ulag’s Build 2026 post (Azure Blog, 2026) declared operations agents generally available.
No Microsoft source says Database Hub’s agents are built on operations agents. Both pair agent perception of live signals with agent reasoning about cause, but Microsoft documents them apart, so treat them as two products.
Core components of Database Hub’s agents
The agents observe database behavior across all six engines. Microsoft pairs them with built-in observability, delegated governance, and Copilot-powered insights, and names aggregate health views, common performance categories, and trend analysis as its signals. Public detail beyond that is thin while it is pre-GA.
Core components of the operations agent
- State and transition rules: “is above” fires while a value stays high; “crosses above” fires once.
- Autonomous rules: per the transparency note (Microsoft Learn, 2026), you approve, reject, or make a rule autonomous so it acts without confirmation.
- Agent identity: each agent gets a Microsoft Entra Agent ID but runs with its creator’s delegated permissions.
That last detail matters for AI agent identity: Fabric attributes actions to the agent, yet the agent borrows its authority from a person. Monitoring agents run a continuous agent loop, and a loop that can act needs owners before it needs features.
Data agent vs. database agent vs. operations agent: head-to-head
The three agents diverge on status, scope, and write posture, and “database agent” names only one of them. Cells reflect Microsoft’s pages as of September 28, 2026; where Microsoft has published nothing, the cell says so.
| Dimension | Fabric data agent | Database Hub agent (“database agent”) | Operations agent |
|---|---|---|---|
| Status | Generally available | Early access; “private preview” in June 2026 | Generally available since June 2026 |
| Primary function | Answer questions about data | Observe databases and guide fixes | Monitor live data and act on rules |
| Scope | Up to five OneLake sources | Six database engines, cloud to edge | An eventhouse or ontology |
| Read or write | Read-only | Recommends; a human decides | Runs approved or autonomous actions |
| Identity model | Asking user’s credentials | Not publicly documented | Entra Agent ID, creator’s delegated permissions |
| Human control | Out-of-policy requests refused | “Human-in-the-loop” by design | Approve, reject, or make a rule autonomous |
| Trigger | A user asks | Continuous observation | Rule queries every 5 minutes |
| Official source | Learn concept guide | Azure Blog, March 2026 | Learn how-to |
| Known risk | Truncated answers at 25 rows | Pre-GA; public detail is limited | Excessive notifications or overused automated actions |
Picture a Monday at a retailer on Fabric: a DBA reads a Database Hub alert that “the agent flagged a connection-pool anomaly.” An hour later, a finance analyst asks “the agent” in Teams for Q3 revenue by region. Same word, two unrelated systems, and three if an operations agent watches inventory.
Each design choice is a strength for its job:
- Data agent: read-only is a safety feature, and Microsoft’s setup guide (Microsoft Learn, 2026) marks root-cause questions such as “Why is our factory productivity lower in Q2 2024?” as out of scope.
- Operations agent: the transparency note (Microsoft Learn, 2026) says it analyzes data and identifies the cause when a rule matches, the gap the data agent leaves.
- Database Hub agent: pre-GA is normal for a new hub, and it alone targets DBA toil across engines.
In AI agent architecture terms, the data agent is request-driven and the other two are event-driven, the same split as autonomous agents vs. copilots. Autonomous rules belong on any enterprise AI agent guardrails checklist.
Pick by the object and the write posture, then name the agent in writing so the label can’t drift.
How do Fabric’s data agent and Database Hub work together?
The data agent answers while Database Hub’s agents and operations agents watch and act, so teams running Fabric at scale end up using both kinds. The design work sits in the handoffs.
Incident first, question second
A Database Hub agent surfaces that a database’s behavior changed, or an operations agent flags a stock level crossing below a threshold in Teams. The owner then asks a data agent a read-only follow-up, for instance against a mirrored database, a supported data agent source (Microsoft Learn, 2026). The monitoring agent supplies the “when,” and the data agent supplies the “how much.”
Read-only by design, action by approval
Because the data agent cannot write, you can open it to many more people. Actions stay behind Database Hub’s human decision, or behind the operations agent’s approval step unless someone makes the rule autonomous. According to Microsoft Learn (2026), you can now add a data agent to a Copilot Studio agent as a Fabric IQ Data MCP tool while keeping source permissions, which puts an MCP gateway question in front of platform teams.
One identity per agent
The operations agent’s dedicated Entra Agent ID is the pattern worth copying for agents outside Fabric, with one caveat: it still borrows its creator’s permissions. Giving AI agents access to enterprise data works better when every agent has a name and an owner, with its scope written down.
Where to start depends on the pain. Self-service Q&A over modeled data points to the data agent, DBA toil across several engines points to Database Hub (pre-GA), and business-process alerts on live data point to an operations agent.
Both database-agent sessions sit on FabCon’s Databases in Fabric tracks, and the FabCon Europe 2026 sessions by role map places the rest. Knowing which agent produced an answer or an action is the part your team has to design, and it starts with the Fabric AI agent governance questions on permissions and ownership.
Why naming your AI agents clearly matters
“Database agent” versus “data agent” is a small case of a pattern every enterprise will hit: one question-answering product and two monitoring products, all called “the agent” in conversation. According to Microsoft Learn (2026), the family is still growing, with Operations Agent for Pipelines in preview for Data Factory runs.
The fix is knowing, inside your organization, which agent someone means when they say “the agent,” what it reads, what it may change, and who answers for it. AI-ready data work already asks this of tables: an AI-ready data checklist wants an owner on each asset, and what makes data AI-ready includes the meaning, owner, and access scope of what an agent reads. Agents deserve the same record.
Atlan, the Context Layer for AI, treats this as context work. An AI agent registry and a plan for agent sprawl matter more as vendors ship agents faster than teams name them, and context engineering and a sound AI agent harness depend on that inventory. Does your team have one place that says which agent is which?
FAQs about Fabric data agent vs. database agent
1. What is the difference between a Fabric data agent and a Fabric database agent?
A Fabric data agent answers plain-language questions about data in OneLake and is read-only. A Fabric database agent is the agent layer in Database Hub that observes operational databases and guides fixes. The data agent is generally available; Database Hub is pre-GA, labeled early access and later private preview.
2. What is the Database Hub in Microsoft Fabric?
Database Hub is a unified management experience in Fabric for six database engines, including Azure SQL, Azure Cosmos DB, Azure Database for PostgreSQL, and Fabric databases. It adds observability, delegated governance, Copilot-powered insights, and agents that reason over estate-wide signals.
3. Can a Fabric data agent write or delete data?
No. A Fabric data agent only generates read queries in SQL, DAX, and KQL, keeps read-only connections to every source, and never creates, updates, or deletes data. It also does not trigger notebooks, anomaly detection jobs, or other write workflows in Eventhouse.
4. What are “health signals” in Fabric’s Database Hub?
Microsoft calls them estate-wide signals: observations of database behavior that Database Hub’s agents reason over to surface what changed, why it matters, and what to do next. It names aggregate health views, common performance categories, and trend analysis, but publishes no detailed metric list.
5. Is Microsoft Fabric’s Database Hub generally available?
No. Microsoft announced Database Hub in early access at FabCon and SQLCon 2026, and its Build 2026 announcement still described it as in private preview. The Fabric data agent and the operations agent are both generally available.
6. What does “agent-assisted, human-in-the-loop” mean in Fabric?
It means agents watch and recommend while people decide. For operations agents, Microsoft documents the mechanism: recommendations arrive in Teams, and you approve, reject, or mark a rule autonomous so the agent may act without confirmation. Database Hub uses the phrase with fewer published mechanics.
7. How do Fabric data agents and operations agents work together?
Operations agents monitor live data and flag conditions, and data agents answer the follow-up questions. Typically, an operations agent alerts an owner in Teams, and the owner asks a data agent a read-only question about the same data.
Sources
- Fabric data agent creation (concept), Microsoft Learn
- Create a Fabric data agent, Microsoft Learn
- FabCon and SQLCon 2026: Unifying databases and Fabric on a single data platform, Azure Blog
- Microsoft Build 2026: Building agentic apps with Microsoft Fabric and Microsoft Databases, Azure Blog
- Advancing Databases for the Next Generation of Applications, Microsoft Fabric Community
- Create and configure operations agents, Microsoft Learn
- Operations agent transparency note, Microsoft Learn
- What’s new in Microsoft Fabric, Microsoft Learn
- Database Agents: A New Way to Manage Databases in Fabric (session W24), ESPC FabCon Europe 2026
- From 2AM Page to Action in Minutes with DB Agent (session W19), ESPC FabCon Europe 2026
