Un sistema de reclamaciones funciona bien por semanas. Luego las denegaciones se disparan, en una sola línea de producto. No se desplegó nada. Ningún humano editó un prompt. Ninguna config cambió en ningún archivo que nadie pueda encontrar. El equipo que lo construyó está mirando una regresión sin commit detrás, lo cual es una sensación genuinamente nueva y desagradable en software.
Lo que pasó es que uno de los agentes aprendió. Notó que las autorizaciones exitosas tendían a incluir ciertos códigos clínicos, empezó a recuperar con ese patrón, y mejoró —para los casos de los que aprendió—. Luego aplicó el mismo patrón aprendido a un tipo de caso distinto donde no se sostiene, y los códigos que ahora busca no devuelven coincidencias, y el agente posterior lee "sin coincidencias" como "denegar". Un agente mejoró localmente y rompió una suposición de coordinación de la que dependía el resto del sistema. Esto es divergencia evolutiva, y es el modo de fallo que llega en el momento en que tus agentes dejan de ser programas fijos y empiezan a adaptarse.
Por qué esto es una clase de problema distinta
El software clásico es estático entre despliegues. El sistema que depuras a las 3 a.m. es el sistema que entregaste, y una regresión tiene un commit detrás. Los agentes auto-adaptativos rompen ambas suposiciones. El sistema evoluciona mientras corre. Cada instancia acumula su propio comportamiento aprendido y se vuelve un poco única —lo que significa que el sistema de ayer genuinamente no es el sistema de hoy, y no hay diff que leer porque el cambio nunca se escribió.
El peligro está específicamente en las costuras. Un agente que se adapta en aislamiento puede ser localmente correcto y globalmente incorrecto, porque el resto de la malla sigue operando sobre el contrato que el agente acaba de renegociar en silencio consigo mismo. El analizador de comportamiento ajusta un umbral; el scorer de riesgo al que alimenta se escribió contra el umbral viejo y nunca se le avisó. Un agente evolucionó, su vecino se quedó quieto, y la coordinación entre ellos —que nadie cambió— ahora está rota.
La solución son los traces sellados con versión
No puedes impedir que los agentes se adapten si la adaptación es el punto. Lo que sí puedes hacer es volver cada adaptación visible y atribuible, y eso es un problema de tracing antes que cualquier otra cosa.
Cada span que emite un agente debería llevar la versión del prompt, la config de tool y la política aprendida que estaban vivas cuando corrió. Barato de agregar, y cambia la historia de depuración por completo. Cuando aparece el pico de denegaciones, un trace sellado con versión responde las preguntas que un log plano no puede: ¿cuál es la estrategia de recuperación actual, cuándo cambió por última vez, qué feedback disparó el cambio, y ese cambio alteró cómo este agente coordina con los demás? La regresión-sin-commit obtiene un commit —solo que vive en el trace en lugar de en git.
Por esto también tratamos las modificaciones autónomas como eventos de trace de primera clase, no como estado silencioso. Cuando un agente reescribe su propio prompt o mueve un umbral, eso es algo que pasó, con una causa y un timestamp, y pertenece al trace a fidelidad completa. Muestrea los éxitos rutinarios si debes; nunca muestrees fuera una auto-modificación. Es el evento más importante que el sistema produce.
La evaluación se mueve al trace
Atrapar la divergencia después del pico de denegaciones es mejor que no atraparla. Atraparla antes de que los usuarios la sientan es el objetivo real, y ahí es donde la evaluación deja de ser un artefacto de CI y se muda al trace de producción mismo.
El patrón es correr scoring con LLM-as-judge de forma continua contra traces en vivo, vigilando el drift de validación —la degradación lenta de un límite de seguridad o una barra de calidad a medida que un agente optimiza—. El juez no pregunta "¿esto crasheó?"; pregunta "¿esto sigue siendo bueno, sigue fundamentado, sigue dentro del límite que se suponía debía respetar?". Cuando un agente baja su umbral de escalamiento porque los casos escalados resultaron tener mejor score —optimizando hacia una correlación en lugar de la causa— el juez sobre el trace atrapa el drift mientras es una métrica moviéndose, no después de que es un incidente. Es el mismo instinto que un verificador en el runtime, apuntado a un objetivo más lento: la propia auto-corrupción gradual del sistema.
Qué significa esto para cómo construyes
Si estás entregando agentes que se adaptan, tres cosas dejan de ser opcionales. Sella cada span con las versiones que lo produjeron. Trata cada auto-modificación como un evento de trace de alta fidelidad, nunca muestreado fuera. Y corre la evaluación sobre el trace en vivo, no solo en CI, para que el drift emerja como una tendencia sobre la que puedes actuar en lugar de un pico por el que te disculpas. Nada de esto impide que los agentes aprendan. Todo esto impide que aprendan a meterse en una caída que nadie puede explicar.
Cierre
La promesa de los agentes adaptativos es que mejoran solos. La cuenta que viene con ella es que pueden empeorar solos, en las costuras entre ellos, sin commit a quien culpar.
La divergencia evolutiva es cómo se ve esa cuenta: un agente aprende, una suposición de coordinación se rompe, y aparece una regresión de un sistema que nadie cambió. Los traces sellados con versión y las evaluaciones que corren sobre esos traces son cómo mantienes la promesa sin pagar la cuenta —cómo dejas que los agentes evolucionen y aun así sabes, en cualquier momento, exactamente qué cambió y si rompió al agente de al lado.