My agent refuses to do certain things (and that is a feature)

My agent said no to my own client. The request was well written, the intent was good, and the answer was a refusal with an explanation attached. It is one of the features I am most proud of.

Agents that obey too much

The conversation about AI agents usually revolves around what they can do: how many tools they have, how many steps they chain, how well they understand an ambiguous instruction. Almost nobody asks the opposite question: what do they refuse to do. In PDM that is the question that matters, because a wrong write does not stay put. It travels into the BOM, the ERP and production. And Vault has no mass undo: zero operations of that kind exist.

VaultPilot, the agent we built together with Avant Leap for Autodesk Vault, was born with that question at its center. It has hard limits: operations it will not run no matter how well the user phrases the request. Mass deletions, writes outside the agreed scope, changes without a prior dry-run showing exactly what is about to happen.

Two months of refusals, in numbers

During development we kept a log of everything the agent did and everything it refused to do. The numbers below come from that log (May 14 to July 14, 2026, a single instance against Vault Professional 2026): they are not a production success rate, they are the X-ray of a system under construction.

The first gate rejected 45 requests in two months. On top of that, 80 writes were stopped by a gate before touching data: 45 by identity anchoring and 35 by the read-only switch. And 23 times the API returned success and the subsequent re-read disproved it: without write verification, those would have been 23 silent lies in the history.

Every one of those refusals is an incident that never happened.

What each "no" does

I can tell you what each gate does, not how it is implemented. The dry-run shows the effect of an operation before running it and demands explicit confirmation. Validation against the real Vault schema prevents operating on properties the model thinks it remembers but that do not exist. Write verification re-reads after writing, because every write is a claim and the read-back is the proof. Hard limits keep certain operations out of the agent's reach, regardless of the prompt. And the audit trail records everything, refusals included.

There is one more layer: every chat runs with the user's own credentials. If you cannot delete a file in Vault, the agent cannot do it for you either. There is no admin backdoor.

The question for your next vendor

If you are evaluating agents that write to your data, do not ask only what they can do. Ask for the list of what they refuse to do, and how they record it. An agent that runs everything you ask is not powerful: it is a risk with a nice interface.

My rule since day one has not changed: build the gate before you build the agent.