An agent that can fail expensively

There is one variable that organizes all AI software design and almost never shows up in the demos: how much a mistake costs. A chatbot that hallucinates an answer costs you ten seconds and some patience. An agent that writes the wrong property into your PDM can wreck an entire release, with drawings already out and an ERP waiting on data that stopped being true. Building VaultPilot together with Avant Leap, the native AI agent for Autodesk Vault Professional, that difference stopped being theoretical and became the central design criterion.

The cost of error defines the architecture

When mistakes are cheap, you can afford to iterate: the user retries, corrects, moves on. When mistakes are expensive, the design changes in kind. You are no longer optimizing the model's answer: you are building the system that decides what can and cannot happen, regardless of what the model proposes. That is why I say build the gate before you build the agent. Define the limits first and the agent inherits safe ground. Build the agent first and the limits arrive late, one reaction at a time.

What the log says

In two months of development log, against a single Vault Professional 2026 instance, VaultPilot's gates stopped 80 writes before they touched data: 45 through identity anchoring (the agent was about to operate on a different file than the one the user had in mind) and 35 through the read-only switch. And one number marked me more than any other: 23 times the Vault API returned a success code that the subsequent read-back disproved. It is a development log, not a production success rate, but the lesson is general: an API success is a claim, not proof.

Four rules I keep

First: dry-run always. The agent shows exactly what it is about to change before changing it, and a person authorizes. Autonomous means the agent performs the workflow, not that nobody is watching.

Second: verify every write by reading it back. Without read-back, those 23 false successes would today be corrupt data wearing the costume of correct data, the worst possible error: the one you do not know you have.

Third: hard limits are never negotiated with the model. There are operations the agent refuses every time, no matter how it is asked. That refusal is not a limitation: it is a feature.

Fourth: a full audit trail. Every operation is recorded with who, what and when. When something looks off, the log answers in minutes what would otherwise be an investigation.

More control, not less

The uncomfortable conclusion for anyone expecting magic: an agent that can fail expensively needs more control engineering than a traditional script, not less. A script automates the rule; an agent handles the exception, and it operates exactly where the rules run out. There, control is not bureaucracy: it is what makes it possible to trust the agent with real work.