Anatomy of a PDM agent: 28 tools across 9 categories

When people watch an AI agent working on a PDM, the first thing they notice is the chat. You type in plain language, the agent understands, things happen. But the chat is the least interesting part of the system. It is just the front door.

What defines an agent is what sits behind that door: its inventory of tools. In VaultPilot, the agent we built together with Avant Leap for Autodesk Vault Professional 2026, that inventory is 28 tools organized into 9 categories. This article walks through them and explains why that architecture matters more than any conversational demo.

The 9 categories, from reading to writing

The first categories are about reading. Search: files, items and folders, always against the real Vault schema and never against the model's assumptions. Properties: querying values and preparing them for validated writes. BOM: full product structures, with comparisons to spot differences between versions. Reports: results exported to XLSX, PDF or CSV, ready for an audit or for the follow-up meeting.

Then come the ones that act on the system. Lifecycles: state transitions, always preceded by a dry-run that shows what will happen before it happens. Bulk operations: the same operation across hundreds of components in one pass, which is where an agent earns its keep. ECOs: engineering change orders. Jobs: queueing and monitoring the job server.

And one category that looks outward: ERP. Because engineering data does not end in engineering. Connecting the PDM to the business system is the gap that quietly consumes the most hours in a manufacturing company.

A tool without limits is a risk

Here is the nuance that separates a production agent from an experiment: each of the 28 tools has its own limits. Read tools run with the credentials of the user asking, no admin backdoors. Write tools go through dry-run with confirmation, schema validation and post-write verification. And there are operations the agent simply refuses to execute, by design.

The phrase I use to summarize it: an agent without tools is a chatbot, and an agent with tools and no limits is an incident waiting for a date. The value lives in the middle, and that middle is designed tool by tool.

Why the full map matters

When a team evaluates an agent for its PDM, the useful question is not how well it converses. It is which tools it has, what it can read, what it can write and which limits govern every operation. A clear inventory of capabilities turns an AI promise into an engineering specification you can audit.

That is also why this map exists as categories: the conversation with an engineering manager changes when they can point at the grid and say: this yes, this not yet, this only with prior approval. The agent stops being magic and becomes one more piece of the process, with a known contract.

How to apply this to your case

If you are thinking about bringing AI into your Vault, start with the inventory and not with the model: list the operations your team repeats every week, sort them into read, write and connect, and ask which ones hurt the most. With that map in hand, evaluating any agent (ours or anyone else's) takes minutes: you compare your list against its tools and its limits.

And if you want to see what that exercise looks like on real processes, write to me. The honest diagnosis is the part of the job I enjoy most.