Los agentes de inteligencia artificial ya no se limitan a responder preguntas. Cada vez más, ejecutan tareas: lanzan comandos en un terminal, modifican archivos, llaman a servicios externos o encadenan pasos sin que nadie los supervise uno a uno. Eso plantea una duda muy práctica: cuando un agente dice «hecho», ¿qué se ha hecho exactamente? Un trabajo publicado en arXiv por Stefan G. Creadore presenta Praxa, un «arnés» (la capa de software que envuelve al modelo y controla lo que hace) diseñado para responder a esa pregunta con pruebas.

La idea de partida se resume en una frase del propio artículo: proponer, autorizar, ejecutar, comprobar el efecto y dar algo por bueno son cosas distintas. En palabras del autor:

«proposal, authority, dispatch, verified external effect, and serving promotion are different claims»

Es decir, que un modelo proponga una acción no significa que tenga permiso para hacerla; que la lance no significa que haya surtido efecto; y que haya surtido efecto no significa que el resultado deba pasar a producción.

Cómo funciona por dentro

Praxa convierte esas diferencias en estados explícitos por los que debe pasar cada acción. Según el resumen del trabajo, la cadena tiene cinco piezas:

• Admisión determinista: antes de ejecutar nada, unas reglas fijas (no el criterio del modelo) deciden si la acción propuesta está permitida.
• Ejecución intermediada: el agente no actúa directamente; un intermediario («broker») lanza la acción en su nombre.
• Lectura externa de vuelta: después, el sistema consulta el mundo exterior para ver si el cambio se ha producido de verdad, en lugar de fiarse de lo que dice el agente.
• Conciliación: se compara lo que se pretendía con lo que se ha observado.
• Promoción revisada: solo tras esa revisión se da el resultado por válido para usarlo «en serio».

La ventaja de este diseño es que cada salto, desde la intención hasta el efecto, queda registrado y se puede comprobar con pruebas automáticas. Si algo falla, se sabe en qué eslabón.

Qué dicen los resultados

Lo más llamativo del artículo es su honestidad con los datos. El autor presenta cuatro bloques de evidencia y, en cada uno, delimita qué demuestran y qué no:

• Auditoría del código: en una versión fijada del repositorio, el sistema superó 1.027 de 1.027 pruebas unitarias y 89 de 89 pruebas en Workerd (un entorno de ejecución para servidores), con 363 archivos instrumentados. Pero la ejecutó el propio autor, y no hay transcripciones de cada prueba ni reproducción independiente.
• Prueba piloto con Terminal-Bench: en 12 tareas seleccionadas de este banco de pruebas para agentes que trabajan en terminal, la versión base y la versión con la capa de fiabilidad aprobaron lo mismo: 17 de 36 intentos. La capa extra consumió un 37,49 % más de tokens de entrada y un 50,73 % más de salida. Conclusión del autor: el piloto no demuestra ninguna superioridad.
• Comparación de coordinación: en un entorno de desarrollo, ambas variantes completaron 180 de 180 ensayos con la misma precisión, recuperación completa tras caídas simuladas y cero violaciones de las protecciones. La variante candidata usó un 37,11 % menos de tokens, un 33,84 % menos de coste estimado y un 11,63 % menos de pasos. Aun así, el artículo advierte de que eso no prueba más calidad, menos latencia ni mejor comportamiento en producción.
• Despliegue real: el código y la configuración desplegados muestran funciones de reflexión acotada, gestión de memoria y vigilancia del estado de las herramientas, pero sin una mejora medida de resultados en producción.

La letra pequeña

El propio trabajo enumera lo que no establece: seguridad frente a ataques deliberados, seguridad en producción, superioridad general, capacidad de optimizarse a sí mismo de forma autónoma ni beneficio demostrado para el usuario. También conviene recordar que se trata de una prepublicación en arXiv, sin revisión por pares, firmada por un único autor.

Para el usuario de a pie, esto no cambia nada mañana: no es un producto que se pueda instalar ni una función que vaya a aparecer en una aplicación. Es una propuesta de arquitectura. Su valor está en la forma de pensar el problema más que en una cifra de rendimiento, porque los números, como reconoce el autor, no muestran una ventaja clara en calidad.

Por qué importa

A medida que delegamos tareas reales en agentes de IA, la pregunta deja de ser «¿lo ha entendido?» para pasar a ser «¿lo ha hecho, tenía permiso y se puede comprobar?». Praxa propone tratar cada acción como una cadena de afirmaciones distintas que hay que verificar una a una, algo parecido a lo que ya se hace con las transacciones bancarias o los despliegues de software. Y su forma de presentar los resultados, separando sin adornos lo demostrado de lo que no, es casi tan interesante como la propuesta en sí: en un campo lleno de anuncios grandilocuentes, un artículo que dice «esto no prueba superioridad» es una rareza que se agradece.