The numbers I bring on stage at AU 2026

Tomorrow at 4:30 PM I present MFG3731, Vault on Autopilot, at Autodesk University. And instead of saving the material for the room, I want to put in writing the numbers that hold the session together, because they were the hardest part to earn and the part that looks least like a typical AI talk.

They come from our development log: two months of work, May 14 to July 14, 2026, against a Vault Professional 2026 instance. They are not a production success rate and they do not pretend to be. They are what actually happens when you build an agent that writes to a PDM.

The four numbers

249 calls reached Vault. Over that period the agent invoked 45 distinct operations from natural language: searching, changing lifecycle states, assigning properties, exporting BOMs, generating reports. Every call is a user intention turned into a concrete operation against the server.

150 were verified against the server: 60%. Verified means that after executing, the agent read the data back from Vault and confirmed the result matched the promise. That is the standard we hold it to: not reporting what it did, but proving what is there.

80 writes were stopped by a gate before touching data. 45 by identity anchoring and 35 by the read-only switch. Every one of those 80 was a write that an agent without controls would have executed.

23 times the API returned success and the read-back disproved it. This is the number I care about most. If your integration trusts the return code, those 23 operations would live in your Vault today as correct data that is not.

What they mean together

The 60% is not a number to brag about; it is a number to trust. A vendor who only shows perfect demos is not showing you the system: they are showing you the rehearsal. Real systems fail, and the right question is not whether they fail, but whether the failure reaches your data or dies at a gate.

The context that gives them meaning

These numbers do not live alone. In the field we have observed teams where each engineer spends between 3 and 8 hours a week on repetitive PDM operations, and manually auditing a 25 part assembly before release takes 18 to 25 minutes. Vault, on top of that, has no bulk undo: a botched batch operation does not roll back with a button. That is the terrain where an agent adds real value, and also the reason it cannot operate without gates.

That is why the session does not revolve around the demo, but around the contract: every write is a claim, and read-back is the proof. That is what I defend tomorrow in Las Vegas.

And that is also why I am publishing the numbers before presenting them, not after. If my argument is that an agent must prove what it does instead of asking for trust, the least I can do is hold myself to the same standard: here is the log, failures included, so everyone can judge with evidence instead of a well rehearsed demo.