A Fabric Data Agent can change even when its name and URL do not. A source is added, instructions are edited, few-shot examples change, a semantic model is republished, permissions move, or a draft is published. Any of these can alter source selection, generated queries, answers, security behavior, latency, and capacity consumption.
Datrick treats Data Agent configuration as releasable software. Git history and deployment pipelines provide the transport; deterministic evaluation, environment-aware binding, permission tests, publishing controls, approval, rollback, and runtime monitoring provide release confidence.
Can you reproduce the exact published agent currently serving users? Establish the definition and release evidence before the next change.
Inventory the whole release unit
Map the Data Agent, owner, developers, consumers, Git provider, branches, workspaces, deployment stages, service connection, sources, semantic models, warehouses, lakehouses, Eventhouses, ontologies, instructions, example queries, permissions, tenant settings, capacities, integrations, and published channels. Include dependencies that are not serialized or automatically rebound.
Define which workspace is authoritative for development, test, and production. Restrict development consumption so experimental agents are not mistaken for approved production tools. End users should reach only the production-published version through supported channels.
Understand the draft and published item definition
| Definition area | Release evidence | Failure to prevent |
|---|---|---|
| Top-level schema | Definition schema version, item metadata, logical identity, compatibility, and validation result. | A service update or unsupported schema breaks import or changes interpretation. |
| Draft stage | Source inventory, selected schemas, AI instructions, source instructions, few-shot examples, and configuration diff. | An unreviewed portal edit bypasses source control or evaluation. |
| Published stage | Publish information, published configuration, release version, actor, timestamp, and channel acceptance result. | Production workspace contains a newer draft while users still consume an older published agent. |
| Dependencies | Source item IDs, workspace IDs, names, connection or credential requirements, permissions, and target mapping. | The promoted agent points to development data or an inaccessible source. |
| Environment values | Variables, mapping rules, post-deployment scripts, secrets boundary, region, capacity, and tenant settings. | Hard-coded development references or credentials reach production. |
| Consumers | Fabric, Power BI Copilot, Copilot Studio, Foundry, sharing, group membership, and minimum source access. | The agent deploys successfully but is unavailable or overexposed to users. |
| Evaluation | Question suite, expected source/query/result, security persona, latency, cost, score, approval, and artifact version. | A syntactically valid release silently reduces answer quality or security. |
Review exported files rather than assuming every portal setting is represented. Keep generated and human-authored configuration distinctions clear. Do not store secrets in Git. Version the evaluation data and expected results beside the release process without exposing sensitive production samples.
Use branches and review for semantic change
Require a change request that explains the user problem, affected sources and questions, expected behavior, risk, and rollback. Use isolated feature workspaces or branches. Review structured diffs for removed sources, widened schema, changed instructions, few-shot examples, publishing state, and dependency references.
Automated checks should validate JSON schemas, required files, naming, source allow lists, prohibited environments, unresolved placeholders, unsafe instructions, missing owners, and evaluation coverage. Human reviewers assess business semantics, source authority, privacy, and whether examples teach unsupported behavior.
Promote through development, test, and production
Use Fabric deployment pipelines or a controlled API/fabric-cicd workflow based on the supported item matrix and organizational release tooling. Data Agent source control and deployment support are preview, so validate behavior after every Fabric release and retain a manual recovery path.
Deploy dependencies in a known order. Rebind each target source to the correct workspace and item, establish permissions, validate tenant and capacity settings, then run smoke tests before publishing. Microsoft documents service-principal support for Data Agent ALM operations; do not assume that identity can interact with the agent outside ALM.
Require evidence before publish and exposure
| Gate | Test | Release decision |
|---|---|---|
| Definition integrity | Schema, files, logical identity, diff, source allow list, environment values, and dependency resolution. | Block invalid, unexpected, or development-bound configuration. |
| Source binding | Every source exists, matches expected type and schema, uses production data, and has an accountable owner. | Block missing, stale, unauthorized, or cross-environment references. |
| Answer quality | Matched questions across source selection, SQL/DAX/KQL, calculation, narrative, ambiguity, and unsupported requests. | Score meets threshold and has no critical regression from current production. |
| Security | Allowed and prohibited personas, RLS/CLS, source permissions, sharing, prompt attacks, and restricted data inference. | No unauthorized detail, metadata, aggregate, or cross-source disclosure. |
| Performance and cost | p50/p95 latency, AI Query, generated-engine CU, concurrency, failures, retries, and shared-capacity impact. | Release stays within SLO, budget, and capacity safety margin. |
| Publishing | Published version, channel availability, user group, source authorization, version marker, and smoke questions. | Only the approved production definition is consumable. |
| Rollback | Restore prior definition, rebind sources, republish, verify permissions, rerun critical questions, and record recovery time. | Rollback meets the agreed RTO and restores known behavior. |
Detect drift after release
Compare the production item definition with the approved commit and release manifest. Alert on portal edits, source changes, publishing changes, permissions, sharing, owner, tenant settings, capacity assignment, or integration changes. Configuration equality is not enough: source schemas and semantic behavior can drift without changing the agent definition.
Schedule critical evaluation questions and negative security tests. Monitor answer quality, selected sources, query failures, authorization errors, latency, AI Query consumption, user corrections, and incidents. Link runtime findings to the exact published definition and source versions. If production trust is already compromised, use the Data Agent incident-response and rollback guide to preserve evidence and restore a known-good path.
Run a three-to-five-week lifecycle assessment
- Select one Data Agent, its consumers, environments, sources, release owners, current deployment process, and recent change failures.
- Export and inspect draft and published definitions; map serialized files, missing settings, dependencies, bindings, identities, and channels.
- Design Git branches, workspace stages, approvals, service connection, environment mappings, secret handling, and post-deployment operations.
- Build schema, policy, dependency, question-quality, security-persona, performance, cost, publishing, and rollback tests.
- Run a production-shaped promotion from development through test to an isolated target, rebind sources, publish, and execute acceptance tests.
- Exercise rollback and measure recovery; add drift detection for definition, source, permission, sharing, publishing, and runtime behavior.
- Deliver the release architecture, repository contract, pipeline specification, test suite, approval gates, runbook, evidence template, and implementation backlog.
Frequently asked questions
Does Fabric Data Agent support Git integration and deployment pipelines?
Microsoft documents Git integration and deployment-pipeline support for Fabric Data Agent as part of application lifecycle management. Source control and Data Agent deployment support are currently documented as preview. Validate the current support matrix, tenant behavior, provider limitations, item dependencies, and target-workspace bindings before adopting the workflow for production releases.
What parts of a Fabric Data Agent are stored in source control?
Microsoft's Data Agent item definition includes a top-level schema, draft stage configuration, source definitions, and few-shot examples. Published agents add publish information and a separate published-stage representation. The exact serialized files depend on sources and schema version, so review exported definitions and exclude environment-specific secrets or unsupported settings from assumptions.
Does deploying a Fabric Data Agent automatically publish it?
Do not assume that presence in a production workspace means the agent is published for every consumption channel. Microsoft guidance states that a Data Agent must be published to be consumed through channels such as Copilot for Power BI, Copilot Studio, and Foundry tools. The release workflow should verify draft versus published state and run post-deployment acceptance tests.
Can a service principal operate a Fabric Data Agent?
Microsoft documents service-principal support for Data Agent in ALM scenarios such as Git integration and deployment pipelines, but not as general interaction support for the agent. Use least privilege for release automation and test separately which human or application identities can consume the published agent.
How long does a Fabric Data Agent CI/CD assessment take?
A focused assessment and production-shaped release pilot can often be completed in three to five weeks for one agent and its required sources. The work includes definition export, environment mapping, Git workflow, deployment automation, source rebinding, evaluation gates, publishing, permission tests, rollback, drift detection, and operating documentation.
Official implementation references
- Source control, CI/CD, and ALM for Fabric Data Agent
- Fabric Data Agent item definition
- Fabric CI/CD concepts and best practices
- Fabric deployment pipelines
- Fabric CI/CD workflow options
Start with the production Data Agent whose next change cannot be safely reproduced or rolled back. Datrick can define the source contract, build the release gates, run a production-shaped deployment, and deliver an auditable lifecycle workflow.