Autonomous does not mean no human: the four verbs of an agent loop

There are two words you have to defuse before talking seriously about agents inside engineering systems. One is autonomous. The other is MCP. If you do not clear them up at the start, you pay for it during questions.

Autonomous

Autonomous means the agent performs the workflow. It reads, it plans, it calls the tool, it re-reads and it reports. It does not mean it authorises the write. You do that, once, on a preview, before anything changes.

Every demo in the session has that pause in it. And the pause is not a limitation of the system: the pause is the product. It is what turns an agent into something a PDM administrator can let loose in their Vault.

The four verbs

An agent loop has four verbs, and the gates are not one of them. That sentence is the technical centre of the whole session.

Advertise. The executor publishes what may be called: a name, a description and a typed argument schema. In MCP this is tools/list. If an operation is not on that list, it does not exist for the model.

Call. The model answers with one tool name and its arguments as structured JSON. Never prose. If it cannot fill the schema, it cannot make the call. That is the first real barrier, and it is free: it comes from the typing.

Return. The executor hands back a typed result the model has to read, not a sentence it can paraphrase. And there is a consequence here that gets little attention: shape the result and you shape what the model is able to claim afterwards.

The gate. And the fourth one. This one is not in the protocol.

Why the boundary matters

MCP is an excellent transport and discovery protocol. It standardises how a tool is advertised, how it is called and how the result comes back. What it does not do is decide whether that call should run against your production data.

That decision is yours, and it is code you write. Believing the safeguards come in the box is, in my experience, the most expensive mistake people make when they start. You adopt the protocol, it works first try, and you mistake working for safe.

They are not the same thing. A loop that works gives you an agent. A loop with gates gives you an agent you can put in front of an engineer.

The smallest version is four pieces

The good news is that the minimum version of this fits in an afternoon. Four moving parts.

One read tool, answering a real question against your system, with typed arguments and a typed result. One write tool, a single bounded change on one entity type, where the worst case is somebody runs it twice. A preview: the same code path with one extra argument, reporting what would change and how much it would touch, applying nothing. And a read-back: after the write, you re-read the entity and compare.

Those four pieces are the skeleton everything else mounts on. Without them you have a chat that touches your database.

The rule I take to the stage

Build the gate before you build the agent. It is how the session closes, and it is the order I did not follow the first time.

MFG3731 · Vault on Autopilot. Thursday September 17, 2026, 4:30 PM, Autodesk University, Las Vegas. A 60 minute Technical Deep Dive on the Design and Manufacturing track.