This summary is produced by the author, and not by AI.
This note is shorter than the blogs that you're used to from us. You can consider this one akin to an internal memo we make public, because we believe more organizations and developers are currently trying to figure this out.
You have adopted Tabular Editor 3 (TE3) in your workflows, and now you're also experimenting with AI coding agents like Claude Code, Codex or GitHub Copilot. There are then two sources of changes to one file (or set of files): human from TE3 and agent directly to the files on disk.
The solution to this problem depends on your specific workflows. The scenario that prompted this note goes like this:
The risks are thus:
These risks are not unique to this specific setup, so we want to outline three different modes to avoid the toe-stepping problem, depending on how and where you prefer to edit your semantic models.
To understand the problem, it's useful to think of TE3 as having its own copy of the model metadata in memory. When it opens a folder model, all TMDL is read at once and built into TE3's memory. There are then two versions of the model: the one saved on disk, and the one that TE3 keeps in memory.
There are two ways to reconcile the on-disk version and TE3’s in-memory version of the metadata: saving or reverting. A save pushes TE3's memory to disk and overwrites all of the model files there (we use TMDL in this note but the same goes for formats like .bim). There is no warning when this happens. A revert discards the changes that are only in TE3's memory (the asterisk (*) in TE3’s title bar shows if there are) and reads the model files from disk. When reverting would throw away in-memory changes, TE3 warns you. When testing these flows, we bumped into a bug where this warning wouldn’t show after a failed revert; we released a fix in TE3 version 3.26.3.12966, so make sure you’re running the latest release.
The most important rules to avoid losing TE3's and agent’s work are:
It doesn't matter whether agents, you, or another tool makes the changes to the TMDL on disk; these rules apply whenever you have two or more actors editing the TMDL.
In this mode, the TMDL folder on disk is the source of truth. The functional loop is then:
To make this flow more convenient, you can bind the File.Revert action to a custom shortcut like Ctrl + E (by default not in use by TE3). Revert will pick up everything the agent has changed, unless the agent has made a flawed edit TE3 can't load, like a broken reference. TE3 will then show an error message listing all defects and cancel the revert. This is important to realize because if you hit 'Save', you'll overwrite what the agent has changed (and broken); the revert never happened and TE3's memory does not contain those changes.
The best way to avoid this problem is to give your agents tools that make breakage unlikely, such as the TE CLI or MCP servers. Letting agents go wild on TMDL as if they were just text editors is a recipe for errors, lost work and frustration. If agents edit exclusively through te, every single edit is validated as it is made, so flawed changes are caught before they can accumulate into one big failing chunk. te validate lets agents check their own work at the handoff, across two layers: broken references (these fail the revert), and stale DAX references, which revert will load without protesting and surface as broken measures.
In this mode, the model in Power BI Desktop (PBID) is the source of truth. To be specific, the local Analysis Services (AS) instance that spawned on your device. PBID follows the same mental model as TE3: it holds the model in memory and writes the TMDL folder only when you save. The TMDL files are not the source of truth. The functional loop is then:
This mode keeps the full desktop experience: the report is right there and you see model changes reflected in the visual immediately. This flow also has a lower risk of steamroll overwrites than Mode 1 because all actors edit the one live model through the AS engine, which merges edits object by object instead of rewriting the whole model. It does introduce the risk of atomic object collisions: if an agent has just changed [Gross Sales] while you were doing that too in TE3, whoever saves last wins that object: the other’s edit is gone entirely while edits to other objects survive. By default, TE3 watches the live model (the Track external model changes setting in Preferences defaults to On) and picks up changes made by another actor automatically. If TE3’s memory is stale when you save (for example with that setting Off), a Change conflict dialog will still warn you before merging, and the AS engine merges object by object; the object both actors edited still goes to whoever saves last.
There's also an arguably bigger failure mode in forgetting to save in PBID; only that writes the changes from either actor to the TMDL folder. A PBID crash can hit hard this way, so save often. Since PBID is the channel that saves, don't let agents touch the TMDL because PBID will just steamroll over it: even if there are no changes to save, PBID will rewrite the whole folder from memory.
The dynamics of Mode 2 also apply when the source of truth is a semantic model published to a workspace, with TE3 and agents connected directly to it and no folder involved. The Change conflict dialog will warn as it does locally, and that is your only safety net. With no folder on disk, there is nothing for Git to track. Connecting the workspace to Fabric Git integration is no substitute because its commits are manual snapshots of the whole model, so you can’t checkpoint each actor’s turn, and an undo rolls back everything since the last snapshot. It also adds a second writer to the model, on top of whichever actor’s turn it is.
TE3 has the "workspace mode" feature, where TE3 reads and writes from the TMDL folder and is connected to a workspace database (= semantic model) that it also deploys to upon save. This is essentially Mode 1 with a live model you can query from TE3, and here too the TMDL folder is the source of truth. The functional loop is then:
Both save and revert deploy to the workspace, so it is never a separate step and doesn't fall behind. The benefit over Mode 1 is that you can run DAX queries, for example to validate an agent's work after a revert loads their changes. Agents can also query the workspace database read-only, but they only see their own changes live after you next revert.
The workspace containing the semantic model should not be connected to Fabric Git integration because the model in the workspace would then have two writers: the TE3 session and incoming changes from the workspace's connected Git repo. You should use a separate managed workspace where the semantic model is built from the TMDL folder that is Git synced. That workspace should connect to the repo and branch, not to your local folder. The model in the managed workspace only changes when you deliberately pull in the changes through either the UI button or an API call. TE3 treats the workspace database as its own deploy target, so unlike Mode 2, it will not warn about Change conflict. Saves or reverts will just overwrite the workspace database, so do not point your agents there either.
The 3 modes we describe are about TE3 editing alongside an agent. None of these apply when using clients such as TE3 as readers. You can point as many read-only clients as you like at any workspace database, dev copy, or clone including: another TE3 instance connected read-only, a DAX Studio connection, thin Power BI reports, or a query-only agent.
Staleness is the only risk in read-only mode. Since readers don’t write there is no risk of colliding. It’s only when there are multiple editing actors that the user-mediated turn-taking is necessary.
.gitattributes rule for *.tmdl (*.tmdl text eol=crlf) and commit it so every collaborator gets the same normalization and the first PR doesn't show all files as different.compatibilityMode and lineageTags. These are properties in TMDL files; expect noise diffs on these lines whenever both tools save; they are harmless so don’t chase them in review.Pick the mode where you prefer to edit:
The three modes work because they follow two clear rules:
Give your agents the right tools (the TE CLI and/or MCP servers) to work with semantic models and they are less likely to break things and disrupt your workflow. Tracking changes in Git is extremely useful when developing semantic models, and non-negotiable if agents are involved.
Take your semantic models further with Tabular Editor.
Give Tabular Editor a spin