DarwinX lleva un agente de Salesforce del 43,5% al 93% sin tocar el modelo

La nueva frontera: mejorar al agente sin tocar el modelo

Salesforce AI Research y Agentforce presentaron DarwinX, un framework que lleva la tasa de éxito de un agente de navegador del 43,5% al 93% sobre 1.260 tareas no vistas de WebArena-Infinity, sin modificar los pesos del modelo subyacente. El avance, detallado en un paper publicado el 31 de julio de 2026 en arXiv (id 2608.07545), demuestra que todavía queda un porcentaje enorme de rendimiento por extraer en la capa que rodea al modelo.

Para un founder que hoy integra agentes de IA con APIs hospedadas (OpenAI, Anthropic, Google), esto cambia el cálculo: el cuello de botella rara vez está en el modelo, sino en el harness, el conjunto de instrucciones, herramientas, habilidades y flujos de control que envuelven al LLM.

Qué hace exactamente DarwinX

DarwinX trata la mejora del harness como un problema de selección natural. Mantiene una población de variantes del agente, las deja competir y conserva solo las que demuestran que ayudan sin romper lo que ya funcionaba.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La pieza central es un contrato que los autores llaman preserve-and-extend (preservar y extender): un cambio solo sobrevive si mejora alguna tarea y no regresa más allá de un umbral tolerable en tareas ya resueltas. Esto resuelve uno de los problemas crónicos de auto-mejora: que un parche local arregle un fallo y rompa otra cosa en silencio.

El sistema también:

Separa exploración de confirmación: una edición prometedora pasa un cribado temprano y luego se revalida con corridas de mayor fidelidad y pruebas en tareas que versiones anteriores ya resolvían.
Mantiene ramas alternativas vivas aunque rindan peor en métricas agregadas, porque pueden contener la única mutación que resuelve una clase específica de problemas.
Permite fusionar capacidades complementarias entre ramas y volver a probar la versión fusionada contra las mismas puertas de regresión.
Recoge fallos recurrentes en memoria compartida y los convierte en habilidades reutilizables, en vez de crear un parche distinto para cada caso.

El modelo nunca se toca. Todos los cambios ocurren en prompts, herramientas, skills y control flow.

Los números que reporta el paper

Sobre GPT-5.5 congelado, DarwinX elevó la tasa de éxito del 43,5% al 93% en WebArena-Infinity, tras una auditoría que filtró trayectorias inválidas o estilo exploit. Según el resumen de Crypto Briefing, las trayectorias inválidas cayeron de aproximadamente 23,5% a 1,4% en ese benchmark.

Sobre otros benchmarks:

Terminal-Bench 2.1: el agente Monet pasó del 75,5% al 83,2% con GPT-5.5 congelado, y llegó al 84,7% con un modelo base más fuerte. Las mayores subidas vinieron de tareas de ML y cómputo científico (+14,8 puntos) y de datos y bases de datos (+13,8 puntos).
TerminalWorld (entrenado en 94 tareas, evaluado en 41 no vistas): con Opus 4.8, la versión base resolvió 25 de 41 (61%) y DarwinX resolvió 28 (68,3%). Cuatro variantes especialistas resolvieron 24, 25, 26 y 27 tareas en subconjuntos distintos; la versión fusionada alcanzó 28, mejorando a cada especialista por separado.
SWE-bench Verified: el harness evolucionado sobre Terminal-Bench se transfirió sin cambios y alcanzó 84,2%, frente a 80,8% del harness de referencia, sin haber recibido retroalimentación de SWE-bench durante la evolución.

Los investigadores aclaran que el salto sobre GPT-5.5 en TerminalWorld (56,1%) quedó por debajo de un baseline neutro, y que el margen de una tarea sobre el mejor agente listo-para-usar lo describen como sugerente, no estadísticamente decisivo.

Por qué los bucles de auto-mejora se atascan

El paper identifica dos problemas que también reconoce cualquier equipo que parchea prompts a mano:

Path dependence: si cada ronda se construye sobre el agente que ahora luce mejor, una decisión temprana determina todo lo que sigue. Una edición útil local puede llevar la evolución a una rama que acaba estancándose, mientras una alternativa prometedora se abandona antes de desarrollarse.
Cross-task interference: un cambio que ayuda a una clase de tareas puede dañar silenciosamente a otra. Una instrucción de verificación exhaustiva puede mejorar el cómputo científico y agotar el presupuesto de tiempo en trabajos simples.

A esto se suma la estocasticidad de las evaluaciones: el mismo agente pasa una tarea en una corrida y la falla en otra, con diferencias de varios puntos porcentuales entre corridas del mismo benchmark. Por eso el paper insiste en que el regression testing amplio es tan importante como arreglar el fallo que disparó el cambio.

Ran Xu, autor senior del paper, lo resume así, citado por VentureBeat: la ingeniería manual del harness puede converger fácilmente a un óptimo local, porque arreglas un modo de fallo sin una batería de regresión que te diga qué rompiste.

Qué cambia esto si estás montando agentes hoy

Para un equipo que construye con APIs hospedadas, la conclusión es directa: no necesitas fine-tuning para conseguir saltos grandes en fiabilidad. Puedes conseguirlos en la capa que ya controlas, donde vives tu lógica de negocio.

Por un lado, el harness carga información que un modelo genérico no aprende durante el preentrenamiento: datos vivos, workflows, permisos, identidad, reglas de gobernanza, herramientas y superficies de acción. Por otro, cada modelo nuevo tiene sus propios modos de fallo y exige ajustes de prompt, formato de tool-use y contexto. El harness se vuelve, así, una capa de diferenciación más duradera que cualquier prompt puntual.

El coste real cambia de lugar: del entrenamiento de modelos al compute de evaluación. Evolucionar requiere múltiples variantes, repeticiones para absorber el ruido y pruebas de preservación antes de promover una edición. Es más infraestructura que editar prompts a mano, pero la versión manual también necesita regression testing si va a producción. La diferencia es que el bucle automatizado corre esos experimentos de forma sistemática.

Qué significa esto para tu startup

Si tu producto ya envuelve un LLM en herramientas y workflows, DarwinX te da un mapa concreto para mejorar fiabilidad sin tocar pesos:

Mide tu harness antes de tocar el modelo. Instrumenta cada endpoint o tool-call con traces persistentes, fallos, escalaciones y resultados de negocio. Sin esa señal, no puedes entrenar un bucle de auto-mejora, ni siquiera uno simple. Trata esos traces como el dataset de evaluación que tu equipo no tenía.
Convierte casos reales en una suite de regresión determinista. En cada workflow identifica al menos una señal verificable (estado final correcto, transacción aprobada, valor esperado en base de datos). Esa señal es tu verificador. Empieza con workflows donde ya tienes un verificador claro: extracción de datos, tickets que cierran por código de estado, integraciones que confirman con callback. La automatización de DarwinX solo es viable donde la salida es comprobable.
Lanza un bucle mínimo de preserve-and-extend, aunque sea lineal. No necesitas una población entera de variantes para empezar. Cuando un prompt nuevo arregle un fallo, reejecuta la batería de regresión antes de promoverlo. Si pasa, promuévelo; si no, descártalo. Es la disciplina central del paper en formato manual.

Lo que no debes hacer: no apliques evolución poblacional a workflows simples y estables, tipo mapeo entrada-llamada-resultado. Ahí la sobrecarga no se justifica. Tampoco confundas auto-mejora con auto-entrenamiento: DarwinX modifica el harness, no los pesos, y aun así logra saltos muy grandes.

El contexto importa: esta es una de varias líneas de investigación

DarwinX no surge en el vacío. En los últimos meses han aparecido varios proyectos que apuntan al mismo lugar, mejorar el harness en vez del modelo:

Darwin Gödel Machine (DGM), publicado por Sakana AI, deja que un agente modifique su propio código y mantiene un archivo de variantes pasadas. DarwinX se diferencia por el contrato explícito de preservación y por fusionar capacidades entre linajes.
HarnessX (de Xiaomi, ya cubierto por VentureBeat) reescribe prompts, herramientas y control flow mid-task; aísla variantes por familia de tarea para contener la interferencia.
Prime Agent, de Prime Intellect, liberado el 5 de agosto de 2026 como código abierto, se posiciona como alternativa abierta a harnesses propietarios tipo Claude Code o Codex; declara que todavía hay mucho rendimiento por extraer cuando un modelo se entrena alrededor de un harness moderno.

Y en la frontera opuesta, MIT Technology Review reportó en agosto de 2026 un estudio multi-institucional, liderado por Princeton, que mostró que agentes actuales todavía no son capaces de investigación abierta y creativa, lo que matiza las narrativas más agresivas sobre mejora recursiva total del modelo. La lectura útil para founders: la mejora recursiva del harness ya da resultados reales con modelos estables; la mejora recursiva completa de la capacidad de razonamiento está todavía más lejos.

Detalle técnico: qué evolucionó exactamente

Sobre Terminal-Bench 2.1 los autores reportan que el harness evolucionado añadió siete skills nuevas que instruyen al agente a definir primero qué aspecto tendría un resultado correcto, verificar archivos y valores generados antes de cerrar, y anclar las salidas en ejecución real de herramientas.

En trayectorias, la mejora no fue gastar más cómputo siempre. En tareas que ambas versiones ya resolvían, la mediana de turnos pasó de 12 a 13. En seis tareas recién resueltas, pasó de 11 a 22. La lección es operativa: el harness aprendió dónde valía la pena añadir verificación y reintentos, no solo a añadir más verificación en general.

Salesforce también publicó Beagle, infraestructura open-source bajo Apache 2.0 para experimentar con este enfoque. Monet sigue siendo propietario, pero cualquier equipo puede traer su propio harness. DarwinX es el método de evolución; Beagle es el laboratorio que ejecuta rollouts, evaluaciones y experimentos sobre agentes, entornos y datasets.