| name | fabric-data-agent |
| description | Design, configure, evaluate, and govern Microsoft Fabric Data Agents for natural-language Q&A over Lakehouse, Warehouse, Power BI semantic model, KQL database, mirrored database, ontology, or Microsoft Graph data. Use when the user asks for Fabric data agent, conversational analytics, NL2SQL, NL2DAX, NL2KQL, data-agent instructions, example queries, agent evaluation, publishing, sharing, governance, diagnostics, or ALM.
|
| argument-hint | [business domain] [data sources] [questions to support] |
Fabric Data Agent
Use this skill for Fabric Data Agent design and lifecycle tasks. Data Agents are read-only conversational analytics artifacts; they are not general-purpose automation agents.
Required References
Workflow
- Clarify the audience, business domain, and questions the Data Agent should answer.
- Select data sources and tables deliberately. Prefer certified semantic models for governed metrics, Warehouse/Lakehouse tables for relational exploration, and KQL databases for telemetry.
- Confirm permissions, capacity, tenant AI settings, cross-region constraints, and Purview/DLP implications.
- Draft the Data Agent instructions: glossary, source routing, metrics, fiscal calendar, ambiguity handling, and refusal rules.
- Add validated SQL/KQL example query pairs where supported.
- Build an evaluation set and test generated queries/intermediate steps before publishing.
- Plan sharing, monitoring, periodic review, and ALM promotion through Git/deployment pipelines where supported.
Delegation
| Need | Delegate |
|---|
| Querying or validating Lakehouse/Warehouse data with T-SQL | sqldw-consumption-cli |
| Querying or validating KQL database behavior | eventhouse-consumption-cli |
| Semantic model metadata or DAX validation | powerbi-consumption-cli |
| Source table design for Data Agent readiness | fabric-lakehouse, sqldw-authoring-cli |
| ALM and deployment of Data Agent configuration | fabric-alm-cicd |
| Governance/security review | FabricAdmin |
Must
- Keep Data Agent behavior read-only.
- Respect Purview, RLS/CLS, workspace roles, model Read permissions, and selected data-source scope.
- Use clear English instructions and examples.
- Validate generated SQL/KQL/DAX against the actual source schema when possible.
- Surface limitations early, especially row/column caps, unsupported unstructured files, semantic-model example-query limitations, and cross-region constraints.
Prefer
- Narrow, trusted source selection over broad workspace exposure.
- Business glossary and metric definitions embedded in Data Agent instructions.
- Evaluation questions covering happy paths, ambiguous wording, access-denied scenarios, and sensitive data boundaries.
- Published Data Agent descriptions that explain purpose, scope, owner, data freshness, and escalation path.
Avoid
- Using a Data Agent for write operations, remediation automation, or full dataset export.
- Adding raw files directly as sources; expose them through tables first.
- Routing certified KPI questions to raw Lakehouse tables when a semantic model owns the business logic.
- Ignoring Purview audit/eDiscovery implications for sensitive workloads.
Output Format
For design requests, return:
- Use-case and audience summary
- Source selection and routing rules
- Governance and permission model
- Data Agent instructions draft
- Example query plan
- Evaluation set
- Publish/share/ALM plan