The dry-run: the most important feature of an agent that writes

There is one fact about Autodesk Vault that almost nobody keeps in mind until they need it: there is no mass undo. Zero operations. If a process changes the state of two hundred files and that change was wrong, there is no button that puts everything back. You fix it file by file, with time, with nerves, and with someone asking every half hour whether it is done yet.

That fact was the starting point for the most important design decision in VaultPilot, the AI agent for Vault Professional 2026 we built together with Avant Leap. It was not choosing the language model. It was this rule: the agent executes no write without first showing the full plan.

What a real dry-run is

A dry-run is not a generic confirmation message. It is the complete simulation of the operation, presented before touching a single piece of data: which files will be modified, which properties will change and to what values, which lifecycle state each component will move to. The entire plan on the table, in a format an engineer can read and question.

And the part that matters most: execution does not start until the user confirms it. If the plan shows something odd, a file that should not be there, a property with an unexpected value, you cancel at no cost. The mistake dies on paper.

What the gates stop

Over two months of development against a Vault Professional 2026 instance, the log recorded 249 calls that reached the Vault. Of those, 80 writes were stopped by a gate before touching data: 45 by identity anchoring and 35 by the read-only switch. It is a development log, not a production success rate, and that is why I always quote it with that caveat. But the lesson transfers: an agent working from natural language will attempt things it should not, and the difference between an incident and an anecdote is whether a gate stands in front.

The dry-run is the first of those gates and the one that does the most work. Every one of those stopped attempts would have been, at best, an afternoon of manual corrections. At worst, a batch of components released with wrong data.

The dry-run does not work alone either. Its natural partner is write verification: after executing, the agent reads back what it wrote and compares it with what it promised. In that same log, 23 times the API returned success and the read-back contradicted it. Without that check, those 23 cases would today be corrupt data wearing the face of a successful operation. Every write is a claim; the read-back is the proof.

Autonomous does not mean no human

In my Autodesk University 2026 session I defended a line that sums up this philosophy: the agent performs the workflow, but it does not authorise the write. You do. Autonomy means the agent does the heavy lifting, walks the vault, builds the plan, prepares the operation. It does not mean it decides alone over production data.

That is why, when I evaluate any tool that promises to write into a PDM, the first question I ask is the same one I ask of my own: show me the plan before executing. If the answer is that there is no plan, that the tool simply does, the evaluation ends right there.