Toda escritura es una afirmación: la relectura es la prueba

Si de mi sesión en Autodesk University solo se llevan una frase, quiero que sea esta: toda escritura es una afirmación, y la relectura es la prueba.

Y no es una idea sobre Vault. Es una idea sobre cualquier sistema al que le pidas que cambie algo.

El fallo del que nadie te avisa

Bajo contención de licencias, el sistema devuelve éxito y no persiste el cambio.

Léelo otra vez, porque es peor de lo que parece. No es un error que puedas capturar. Es un éxito. La llamada vuelve limpia, con su código correcto, y el dato sigue como estaba.

Un agente ingenuo lee ese éxito y reporta el trabajo como hecho. Y no está mintiendo: está repitiendo lo que la API le dijo. Ese es el problema entero. Un agente honesto puede afirmar una falsedad si su única fuente es la respuesta de la llamada.

En mi caso concreto es comportamiento de licenciamiento de Autodesk. Pero la forma del problema no es específica de Vault: cualquier API bajo contención puede entregarte un éxito que no ocurrió.

Por eso hay nueve compuertas y no una

Un solo control no cubre esto, porque el fallo no está en la intención del modelo sino en la capa de abajo. En la sesión nombro las nueve y digo qué hace cada una. Cómo está implementada cada una no sale de la sala, y ese límite es deliberado.

Las tres primeras trabajan antes de la llamada: el anclaje de identidad exige que el nombre haya sido leído antes en esa misma conversación; la inyección de esquema pone los nombres reales del Vault en el prompt en cada turno; la validación previa comprueba los argumentos contra el esquema vivo.

Las tres siguientes rodean la escritura: previsualizar y confirmar, de modo que nada se aplica sin una segunda llamada; topes duros, que acotan cuánto puede tocar una sola operación; y la relectura.

Las tres últimas son de control: un evaluador de lo que el agente afirma en su narración, un interruptor de solo lectura sobre toda la superficie, y la autenticación con el usuario propio de Vault.

La compuerta que salva la sesión

La relectura es la más barata de todas y la que más veces demostró su valor. Después de escribir, el agente vuelve a leer la entidad y compara. Si no coinciden, reporta el fallo que encontró, no el éxito que le entregaron.

Veintitrés veces, en dos meses de desarrollo, el sistema dijo que sí y la relectura dijo que no.

Cada una de esas veintitrés habría sido una mentira silenciosa. Algo que alguien creyó hecho y no estaba. Y las mentiras silenciosas en un PDM no se descubren cuando ocurren: se descubren semanas después, cuando alguien fabrica con la revisión equivocada.

El anclaje, en una línea de log

La otra que me gusta enseñar es la primera compuerta, porque se ve en una sola línea: rechazado, el archivo no fue leído ni buscado en esta conversación.

La regla es simple. Una escritura solo puede nombrar una entidad que esta conversación ya haya leído o buscado. No un nombre parecido. No un nombre plausible. Ese exacto.

Y ahí está la razón de fondo: un modelo obligado a inventar un nombre inventará uno plausible, y lo plausible es el fallo que no atrapas leyendo la respuesta. En el Vault contra el que construí esto, el estado de trabajo no se llama "Released" ni "WIP" en inglés: se llama como lo bautizó el cliente hace años. Ningún modelo adivina eso. Hay que mostrárselo, cada turno, desde la configuración viva.

Los números, y lo que no demuestran

Voy a Las Vegas con cifras contadas, no estimadas: cuarenta y cinco operaciones distintas de Vault invocadas desde lenguaje natural, doscientas cuarenta y nueve llamadas que llegaron al sistema, ochenta escrituras detenidas por una compuerta antes de tocar nada, y esas veintitrés relecturas que contradijeron a la API.

Y en la misma slide, resaltado: eso no es una tasa de éxito en producción. Es un log de desarrollo, de una instancia contra Vault Professional 2026, llevado mientras las herramientas todavía se estaban escribiendo.

Podría haber quitado esa línea. La dejo porque es exactamente lo que le exijo a cualquiera que me venda automatización, y porque el número que importa no es el mío: es el tuyo.

Sin línea base no hay afirmación. Si no puedes decir cuánto costaba antes, no puedes decir cuánto ahorra después.

MFG3731 · Vault on Autopilot. Jueves 17 de septiembre de 2026, 4:30 PM, Autodesk University, Las Vegas. Technical Deep Dive de 60 minutos, track Design and Manufacturing.