Ahora mismo hay dos clases de agente de IA en producción. Al primero lo cuidas como a un bebé. Le ajustas el system prompt, lo ves fallar en un tipo de tarea nuevo, lo vuelves a ajustar, y el prompt se va convirtiendo poco a poco en un muro de casos especiales que nadie quiere tocar. El segundo detecta el fallo por su cuenta, escribe una versión mejor de su propio prompt, prueba esa versión contra trabajo real, y solo se la queda si de verdad gana. La distancia entre esos dos es todo el campo de los agentes que se autoevolucionan, y este año dejó de ser una curiosidad de investigación.
Un agente que se autoevoluciona no es más que un agente envuelto en un bucle de retroalimentación. El agente ejecuta una tarea. Algo puntúa la salida. Cuando una debilidad aparece con suficiente frecuencia, el sistema propone un system prompt nuevo, corre la versión vieja y la nueva sobre tráfico real durante un tiempo, y promociona a la ganadora. Si la versión nueva resulta peor, revierte a la última que se sabía buena. Sin humano en el camino, pero tampoco un acto de fe, porque nada se promociona hasta que se lo gana.
Esa es la idea. Lo interesante es saber qué pieza es la que de verdad cuesta.
El optimizador quedó resuelto este año
La pieza sobre la que todo el mundo escribe papers es el paso de mutación: dado un prompt que rinde por debajo, producir uno mejor. Durante años la respuesta seria fue el aprendizaje por refuerzo, que ajusta un modelo a partir de recompensas numéricas escasas. Funciona, pero es caro y trata un fallo rico en matices como un solo número.
En 2026 el campo convergió en otra respuesta. GEPA, abreviatura de Genetic-Pareto, fue aceptado en ICLR como oral y plantea un argumento sin rodeos: el lenguaje enseña mejor que una recompensa escalar. En vez de empujar pesos a partir de un número, GEPA lee la trayectoria real de una ejecución, el razonamiento y las llamadas a herramientas y la salida, y luego reflexiona sobre ella en lenguaje natural para diagnosticar qué salió mal y escribe la edición más pequeña que lo arregla. Mantiene una frontera de Pareto de candidatos que ganan cada uno en casos distintos y combina sus puntos fuertes.
Los números son la razón por la que la gente se fijó. GEPA supera a GRPO, un método potente de aprendizaje por refuerzo, en torno a un 6 por ciento de media y hasta en un 20 por ciento, usando hasta 35 veces menos rollouts. También supera a MIPROv2, el caballo de batalla anterior en optimización de prompts, en más de un 10 por ciento. Menos ejecuciones caras, mejores resultados, y nada de maquinaria de aprendizaje por refuerzo que montar. Esa combinación es por la que GEPA se extendió rápido y por la que ahora viene dentro de DSPy, el framework de optimización más popular.
Así que el optimizador está, a efectos prácticos, resuelto. Que es justo por lo que es la parte fácil.
Lo difícil es todo lo que lo rodea
Si lees el trabajo de GEPA con atención, notas que optimiza offline. Toma un conjunto de entrenamiento, corre rollouts contra él, reflexiona, y te entrega un prompt mejor. Lo que no hace es decirte si ese prompt es seguro para ponerlo delante de usuarios reales, vigilarlo sobre tráfico en vivo, ni deshacerlo cuando empeore en silencio el martes que viene. Eso no son defectos de GEPA. Es sencillamente otro trabajo.
El equipo de Decagon documentó lo que realmente costó correr GEPA sobre un clasificador en producción, y ese artículo es más útil que el paper para cualquiera que esté llevando cosas a producción. Destacan tres hallazgos. El modelo de reflexión tiene que ser un modelo de frontera. Vieron que los modelos más pequeños "fallan por completo en la optimización de prompts", con GPT-4o-mini sin producir ningún cambio, porque, según lo expresan ellos, optimizar un prompt es razonar sobre el razonamiento. Más datos no es mejor. Su punto óptimo estaba entre 20 y 100 ejemplos, y forzar hasta 500 hizo que el prompt se inflara mientras el rendimiento caía, sobreajustándose a casos límite en lugar de aprender la regla general. Y la implementación por defecto no limita la longitud del prompt, así que tuvieron que construir eso ellos mismos antes de que un prompt desbocado se comiera su ventana de contexto.
Después, y solo después de que un candidato superara los umbrales offline, lo pasaron por un despliegue A/B controlado con clientes reales, subiendo el tráfico hacia la versión nueva de forma gradual. Esa última frase es el sentido entero de este artículo. El optimizador es un componente. A su alrededor hay un arnés de evaluación, un filtro que decide si un candidato puede salir, un camino de reversión para cuando no, restricciones de longitud y seguridad sobre la mutación, y toda la fontanería para mantener todo esto corriendo online en lugar de como un job por lotes de una sola vez. Esa capa que lo envuelve es donde vive la fiabilidad, y casi nunca es lo que se lleva un paper.
Las piezas de un bucle que se autoevoluciona
Ayuda nombrar las partes, porque un bucle de producción es en realidad un ensamblaje de trabajos pequeños y aburridos que hacen cada uno una sola cosa.
Un puntuador, o crítico, convierte una salida en un número. Un único LLM calificando a otro LLM se inclina hacia su propio estilo, así que el patrón más robusto es varios críticos con criterios distintos, o incluso de proveedores de modelo distintos, sacando una mediana. La puntuación solo es tan fiable como el panel que la produjo.
Un detector de patrones observa las puntuaciones a lo largo del tiempo y decide cuándo existe una debilidad real, frente a una sola mala ejecución. Es la diferencia entre reaccionar al ruido y reaccionar a una tendencia.
El optimizador es el reflector estilo GEPA descrito arriba. Es la parte que escribe el prompt nuevo, y es la parte en la que todo el mundo se obsesiona.
Un filtro de seguridad es el adulto de la sala. Antes de dejar que un prompt nuevo tome el mando, el filtro lo enfrenta cara a cara contra el que ya está, comprueba que la mejora es real y no un cara o cruz, y se niega a promocionar una versión que empeore por debajo de un umbral. Combínalo con reversión automática y un registro del último prompt que se sabía bueno, y una mala mutación te cuesta unas cuantas ejecuciones en lugar de un fin de semana.
Un registro de experimentos recuerda cada ejecución, cada puntuación y cada versión de prompt, para que el bucle tenga memoria y para que puedas auditar por qué un prompt dado está en vivo. Sin él estás evolucionando a ciegas.
Ninguna de estas piezas es vistosa. Todas son de carga. Quita el filtro y la reversión y no tienes un agente que se autoevoluciona, tienes un agente que muta su propio prompt sin cinturón de seguridad, que es un agente peor que con el que empezaste.
Por qué esto ha sido una historia solo de Python
Aquí está la brecha que me lanzó a esto. Todo optimizador de prompts serio en 2026 está escrito en Python. DSPy, la propia implementación de referencia de GEPA, TextGrad, AdalFlow, PromptWizard de Microsoft. Si tus agentes corren en un stack de data science en Python, te sobran opciones. Si corren en TypeScript, que es donde vive una parte enorme de los agentes reales en producción, no había nada. Ni un port fino, nada.
Esa es la brecha que darwin-agents existe para llenar. Es una librería open source en TypeScript, con licencia MIT, que le da a un agente el bucle entero en lugar de solo el optimizador: críticos multimodelo, pruebas A/B, el filtro de seguridad, reversión automática y registro de experimentos, con el optimizador como una pieza intercambiable dentro. La apuesta de diseño es la misma que la de este artículo. El optimizador es la parte que puedes tomar prestada de la investigación. La capa de producción es la parte que tienes que construir, así que construye esa bien y deja el optimizador conectable.
Su última versión cierra el bucle obvio. Hasta ahora la librería traía un optimizador reflexivo estilo GEPA como algo que podías llamar tú mismo, y un bucle de evolución con filtro de seguridad aparte, pero los dos no estaban conectados. El bucle seguía usando un optimizador más simple. La versión nueva los une, así que el optimizador reflexivo ahora corre dentro del filtro de producción en lugar de como un script offline. Hasta donde he podido encontrar, esa combinación concreta, un optimizador estilo GEPA evolucionando prompts en vivo detrás de un filtro de seguridad, en TypeScript, no existe todavía en ningún otro sitio. Es opt-in, así que los agentes existentes se comportan exactamente igual que antes hasta que lo activas, y sigue siendo alpha, así que trátalo como alpha.
Si quieres ver las ideas de alrededor aplicadas a una flota en lugar de a un solo agente, la misma lógica aparece en ajustar una flota entera de agentes sin factura de proveedor.
Cuándo quieres esto de verdad
La autoevolución se gana su complejidad cuando tres cosas se cumplen a la vez. Tienes suficiente tráfico como para que una prueba A/B llegue a un veredicto en un tiempo razonable, porque un bucle que nunca reúne datos suficientes para decidir es solo sobrecoste. La tarea tiene una noción medible de lo que está bien, porque un crítico necesita algo que puntuar. Y el coste de una mutación equivocada es recuperable, que es exactamente lo que el filtro y la reversión garantizan.
Cuando eso no se cumple, un agente que se autoevoluciona es la herramienta equivocada, y un humano retocando un prompt de vez en cuando es genuinamente mejor. Ser honesto sobre ese límite es parte de usar bien la técnica. El modo de fallo de todo este campo es un equipo que enciende la evolución automática para un agente que corre diez veces por semana contra un objetivo difuso, y luego se pregunta por qué el prompt deriva hacia el sinsentido. El bucle solo es tan bueno como la señal que lo alimenta.
La carrera del optimizador está casi terminada y GEPA la ganó por ahora. Los próximos dos años de trabajo real están en la capa por la que nadie compite: el filtro, la reversión, la evaluación, y el trabajo poco vistoso de correr todo eso con seguridad mientras los usuarios miran. Esa es la parte que decide si un agente que se autoevoluciona es un lastre o lo más fiable de tu stack.
