El artículo cuestiona el enfoque habitual de pedir a un modelo de lenguaje que rellene formularios antes de ejecutar una acción. Argumenta que el problema no es si el modelo pregunta, sino quién decide qué preguntar: si esa decisión queda dentro del modelo, las casillas inventadas y las verificaciones omitidas resultan indistinguibles de las correctas. La aprobación humana deja de ser una revisión y se convierte en un trámite, porque leer un formulario limpio no revela huecos que nunca se preguntaron.
La propuesta es invertir el diseño: tratar la fase previa a la ejecución no como validación, sino como un lugar que formula preguntas a partir de una lista externa. Cada pregunta o "casilla" tiene una fuente designada —el usuario, las instrucciones, valores predefinidos, valores observados o el estado previo— y se rellena solo si esa fuente aporta el dato. Si tras recorrer todas las fuentes la casilla sigue vacía, queda como desconocida, no como inferida. La ejecución exige un veredicto registrado basado en esa lista.
Las casillas se organizan en tres bloques: una fija (herramienta, condiciones de ejecución, nombre de la acción), otra del proveedor (campos requeridos, condiciones prohibitivas, cambio de estado que produce la herramienta) y otra del usuario (intención, contexto, límites, preferencias). Valores y condiciones comparten el mismo tratamiento: cada casilla está llena o no lo está, sin lógica separada. Las búsquedas se ejecutan en paralelo, lo que reduce el número de interacciones con el usuario. El resultado es un sistema en el que la lista de incógnitas —no la decisión de ejecutar— es el objetivo del cálculo, y los errores se manifiestan cuando el usuario responde que no.