Versión y confianza en a2
Ayer revisamos un plan. Hoy vamos a ejecutarlo de nuevo.
Los archivos pueden haber cambiado; precisamente por eso repetimos la ejecución. Pero ¿y si también cambió el código que llama el plan?
La habilidad puede conservar su nombre. Su descripción puede parecer igual. Sin embargo, la operación que se ejecutará puede haber dejado de ser la que revisamos ayer.
Una comprobación separada del paquete de presentación de a2 aborda esta situación.
Conocer la versión además del nombre
Los planes de la demo contienen la identidad y el hash del código de la habilidad que se utilizará. Así puede verse en qué implementación se basó el plan.
Las mismas versiones de habilidades se reutilizan en los datos del primer y segundo día. Después hay otra comprobación que intenta ejecutar el plan antiguo con un estado de habilidad modificado.
El registro del paquete indica esta causa de parada:
skill_snapshot_changed
La lista de pasos completados está vacía. Durante esta comprobación no se ejecutó ningún paso del plan ni se llamó al modelo.
Lo que me interesa es que el cambio se haga visible antes de empezar, en vez de descubrirse a mitad del trabajo.
Código modificado no significa código incorrecto
La versión nueva puede ser realmente mejor. Puede corregir un error o tratar un caso antes no compatible.
Aun así, no quiero transferir automáticamente la aprobación del plan anterior al código nuevo.
La revisión anterior trataba una implementación concreta. Cuando cambia, hay que evaluar de nuevo qué comportamientos se conservan. La transición a una versión nueva también debe ser una decisión registrada.
En el artículo anterior sobre Evidrel abordamos una pregunta similar mediante el cambio de fuentes: ¿cómo tratar una aceptación anterior cuando cambian sus fundamentos?
En a2, una respuesta concreta es el vínculo de versión entre el plan y la habilidad que ejecutará.
Lo que un hash del código no dice
Que el código coincida con la versión esperada no demuestra que sea correcto. También puede repetirse el mismo código defectuoso de la misma forma.
La pregunta que responde esta comprobación es más acotada:
¿La implementación que vamos a ejecutar es aquella en la que se apoya el plan?
Para saber si el resultado es correcto siguen haciendo falta las reglas de la tarea y una salida esperada independiente. El hash no sustituye esas comprobaciones.
Por eso importan dos registros separados de la demo: la comparación con el resultado esperado y el rechazo de ejecución al cambiar la versión. Uno comprueba la salida; el otro, la implementación que sustenta la ejecución.
Una condición para repetir la ejecución
Al facilitar el trabajo repetitivo existe el riesgo de volver invisibles los cambios intermedios.
El vínculo de versión del plan limita ese riesgo en un punto concreto. Añade una condición sobre qué código se utilizará a la petición de «ejecutar otra vez el mismo trabajo».
Este es uno de los comportamientos que valoro en la primera versión preliminar: junto a un plan que puede ejecutarse, uno que explica por qué no se ejecutará si cambian sus fundamentos.
Nota de fuentes — 18 de octubre de 2026: El texto se basa en los documentos de la versión 0.1.0a1 y los registros existentes de la demo. Los datos son sintéticos y las habilidades están escritas por personas. No se ejecutó una demo, llamada al modelo o evaluación nueva para este artículo.
Código fuente · Versión y descargas · Guía de la demo · Descargar informe HTML · Descargar evidencia de la demo · GitHub CI
Conexiones: a2 · La misma tarea, otro archivo al día siguiente · ¿Cuándo debería detenerse un agente? · ¿Cuándo deberíamos dejar de utilizar un resultado? · La primera versión preliminar técnica de a2
Se conecta con
Examina la versión preliminar 0.1.0a1 de a2 y la evidencia limitada de su paquete.
Pasa de la demo de dos días al control separado que rechaza un cambio de habilidad.
Concreta la pregunta de parada mediante el control de la versión esperada por un plan.
Relaciona los cambios de fuentes en Evidrel con los del código de un plan de a2, manteniendo distintos los mecanismos.