El agente que se reescribe a sí mismo no tiene especificación

La palabra que hace mucho trabajo silencioso en el marketing de agentes ahora mismo es autoevolutivo. El agente no solo ejecuta tu flujo de trabajo — reescribe cómo funciona sobre la marcha, aprendiendo de cada ejecución para seguir mejorando sin que tú lo toques. ServiceNow y NVIDIA acaban de poner esa idea en tu escritorio: Project Arc, un agente autónomo "de larga duración y autoevolutivo" que lee tus archivos, abre tu terminal y "se adapta cuando las cosas no salen como se esperaba."

Suena como el sueño. También es exactamente la propiedad que hace imposible confiar en un sistema en producción.

La producción corre sobre un blanco que se queda quieto

Cada disciplina que usamos para lanzar software fiable asume una cosa: el comportamiento está fijo el tiempo suficiente para comprobarlo. Escribes una prueba porque el código debajo no se moverá. Revisas un cambio porque hay un antes y un después. Haces rollback porque la versión de la semana pasada sigue siendo algo que existe. Quita el blanco fijo y todas y cada una de esas herramientas dejan de funcionar.

Un agente autoevolutivo lo quita a propósito. La versión que probaste en el sandbox aprendió tres cosas nuevas para el jueves. El comportamiento que tu equipo de seguridad aprobó no es el comportamiento corriendo cuando ocurre el incidente. No hay un rollback limpio, porque "la versión anterior" es un punto borroso en una deriva continua, no una release etiquetada.

Si el sistema se reescribe entre la prueba y el incidente, tu prueba no fue del sistema que falló. Verificaste un fantasma.

La automejora es solo deriva descontrolada con mejor relaciones públicas

Ya sabemos que los agentes de larga duración se degradan con la distancia — duplica la longitud de una tarea y la tasa de fallos aproximadamente se cuadruplica. "Autoevolutivo" no arregla eso; elimina lo único que te permitía detectarlo. Cuando la lógica del propio agente es lo que cambia, no puedes distinguir la mejora del deterioro hasta que está frente a un cliente. No es aprender. Es deriva, disfrazada de característica.

Y fíjate en qué se apoya de verdad la versión seria de Project Arc: no en la autoevolución, sino en la gobernanza a su alrededor — un runtime en sandbox, una torre de control que registra cada archivo leído y cada comando ejecutado, políticas que acotan lo que puede tocar. El argumento de venta es la autonomía. El producto es una jaula. Eso te dice cuál de las dos mitades es la que sostiene el peso.

Deja que aprenda donde puedas mirar

No tienes que elegir entre un agente estático y uno sin rendición de cuentas. Pones el aprendizaje en algún lugar donde puedas verlo y deshacerlo:

• El aprendizaje vive en los datos, no en la lógica. Ejemplos recuperados, filas de memoria, prompts ajustados, una base de conocimiento — cosas que puedes leer, comparar y borrar. El procedimiento de decisión del agente permanece fijo y revisable.
• Cada cambio es un cambio que puedes nombrar. Si actualizar el comportamiento significa lanzar un nuevo prompt o una nueva configuración que pasa las evals, tienes una versión, un diff y un rollback. "Evolucionó" no es una versión.
• La especificación es la fuente de la verdad, no el humor del agente. Escribe el comportamiento y haz que el sistema responda a él. Si el agente quiere hacer algo que la especificación no cubre, eso es un ticket, no una improvisación.
• La mejora es una release, controlada por evals. Aprende offline, mide contra un conjunto de pruebas fijo y promueve deliberadamente — el mismo bucle que usarías para cualquier cambio de modelo. La automodificación online se salta el único paso que atrapa una regresión.

En resumen

Un sistema que se mejora a sí mismo en la oscuridad es indistinguible, desde fuera, de un sistema que silenciosamente se rompe a sí mismo en la oscuridad. Todo el valor de la ingeniería es poder diferenciar esos dos casos.

Mantén el comportamiento del agente fijo y pon el aprendizaje en datos que puedas inspeccionar y reiniciar. "Evoluciona por sí solo" no es una capacidad que comprar — es la historia de verificación que acabas de tirar a la basura.