ERP and Vault, connected by an agent

There is a border that runs through almost every manufacturing company I know, and almost none of them has it on the org chart. On one side lives engineering, with its files, revisions and BOMs inside Autodesk Vault. On the other side lives the business, with its items, orders and costs inside the ERP. And in the middle, holding the operation together with both hands, there is almost always a person exporting to Excel, copying and pasting.

The gap nobody budgets for

That border costs money in ways that are rarely measured. Part numbers that do not match between the two systems. Revisions engineering released weeks ago that the ERP never heard about. BOMs traveling by email as attachments, aging from the moment they are exported. Each of those inconsistencies ends in a call, a meeting, or an order manufactured to the wrong revision.

In the field I have observed that an engineer can spend between 3 and 8 hours a week on repetitive PDM operations. A significant part of that time is exactly this: moving information from one system to the other so that the business and engineering speak the same language. It is not an instrumented figure, it is direct observation from real projects, but anyone working in manufacturing recognizes the scene.

An agent at the border

When we built VaultPilot together with Avant Leap, we decided the ERP could not be an afterthought. It is one of the agent's 9 tool categories, with the same weight as search, lifecycles, properties, bulk operations, BOMs, ECOs, jobs and reports: 28 tools in total, all invocable from natural language.

The practical consequence is simple to describe: the conversation where you work your PDM is the same one where you touch the border with the business. No switching systems, no intermediate exports, no information aging inside an email attachment.

And here comes the part that matters to me more than convenience: the rules do not change at the border. Operations that touch data pass through the same gates as the rest of the agent. Dry-run with confirmation before writing: first you see exactly what is going to change, then you authorize. Validation against the real schema, so the agent cannot invent properties that do not exist. Verification of every write with a read-back afterwards, because a reported success is not a proven success. And everything runs with the user's own credentials, not with an admin account hidden on a server.

The rule and the exception

At my Autodesk University session I summed it up in one sentence: a script automates the rule, an agent handles the exception. The border between engineering and the business is made of exceptions: the item that exists in one system and not the other, the revision that got ahead of the process, the BOM that changed after the last export. That is why rigid PDM to ERP connectors tend to fall short: they automate the happy path and leave the exceptions, which are exactly what hurts, in the hands of the human copier.

An agent with gates flips that equation: it handles the exception by talking with you, and leaves you the final decision on every write. Autonomy does the work. Authorization stays yours.