El agente no se mejora solo: mejora su sistema de trabajo

En agentes seguimos hablando demasiado del modelo y demasiado poco de todo lo que lo rodea.

Es comprensible: cambiar de modelo se ve, se anuncia y parece una decisión estratégica. Cambiar una instrucción, un skill, una política de memoria o el orden en que se llaman las herramientas parece fontanería.

Pero, en producción, esa fontanería suele decidir bastante más de lo que queremos admitir.

El paper Harness²: Recursive Agent Harnessing for an Open World pone una versión ambiciosa de esta idea encima de la mesa: mantener los pesos del modelo fijos y dejar que el agente mejore el sistema que usa para trabajar.

No es fine-tuning. No es que el modelo aprenda de verdad durante la ejecución. Lo que cambia es el harness: prompt de sistema, guardrails, memoria, guía de herramientas, subagentes, skills, scripts y plugins.

Mi lectura es que el concepto importa más que su mecanismo concreto: la unidad de mejora de un agente no debería ser sólo el modelo; debería ser el sistema completo que convierte ese modelo en trabajo útil.

El modelo no trabaja solo

Dos equipos pueden usar el mismo modelo y obtener resultados muy distintos. No hace falta misterio para explicarlo:

uno llega con un objetivo y criterios de salida claros;
otro le da herramientas con contratos razonables;
otro guarda memoria que ayuda en vez de contaminar;
otro sabe cuándo dividir una tarea y cuándo no;
y otro tiene una forma seria de verificar el resultado.

Todo eso es capacidad del sistema, aunque no venga en los pesos.

Esto no es sólo intuición de quien ha sufrido agentes en producción. El trabajo Same Model, Different Harness: Different Coding-Agent Results llega a una conclusión incómoda para los rankings: con el mismo modelo, cambiar el harness cambia de forma material los resultados. Y el reciente Agent Systems with Harness Engineering trata precisamente ese soporte operativo como una disciplina propia, no como detalles de implementación.

La pregunta correcta deja de ser «¿qué modelo usamos?» y pasa a ser «¿qué sistema le estamos pidiendo que ejecute?».

Qué propone Harness²

Harness² trabaja en dos bucles.

En el primero, para la tarea actual, parte de una ejecución base y propone cambios sobre el harness. Prueba candidatos y compara sus trayectorias con la original para decidir qué conservar. Los autores lo llaman Propose–Probe–Compose.

En el segundo, extrae lecciones que han quedado respaldadas por esas pruebas y las guarda para tareas futuras. Es decir: no pretende que cada tarea empiece desde cero.

El detalle interesante es que intenta hacerlo en tareas abiertas, donde no siempre existe un verificador perfecto que diga si la respuesta era correcta. En sus experimentos reportan mejoras sobre varios benchmarks profesionales con GLM-5 y Gemini 3.5 Flash.

Hay que leer esos números con la prudencia habitual: son benchmarks propios de esta clase de sistemas, con presupuesto de iteración y configuración muy concretos. No prueban que haya aparecido un agente que se vuelve mejor indefinidamente. Sí prueban algo bastante más útil: que buscar cambios en el entorno de ejecución puede rendir sin volver a entrenar el modelo.

Lo valioso no es que se edite; es que se compruebe

La idea de un agente que se reescribe suena espectacular. También puede ser una forma muy eficiente de automatizar la deriva.

Si cada fallo autoriza a modificar prompts, memoria, herramientas y flujos, el sistema puede acabar persiguiendo ruido, sobreajustándose a una tarea o acumulando reglas que nadie entiende. Una mejora local puede empeorar silenciosamente lo siguiente.

Por eso la parte valiosa de Harness² no es el editor. Es el contraste entre ejecuciones.

En un sistema real yo exigiría, como mínimo:

Un baseline explícito. No aceptes una mejora si no sabes contra qué ha mejorado.
Un presupuesto de cambio. No dejes que una tarea abra una reforma ilimitada del sistema.
Evidencia antes de persistir. Una reflexión bonita no es una lección; un cambio que funciona en una muestra independiente empieza a serlo.
Versionado y rollback. Un harness es código de producción, aunque parte sea Markdown.
Métricas que no sean sólo éxito. Coste, latencia, tasa de reintentos, errores de herramientas y regresiones también cuentan.

El modelo puede proponer. El sistema tiene que saber decir que no.

Los skills son producto, no contexto decorativo

Una señal especialmente interesante del paper es que buena parte de los cambios útiles cae sobre skills y scripts. Tiene sentido.

Un skill bien escrito no es un texto para animar al modelo. Es una pieza de producto: delimita cuándo actuar, qué información necesita, qué comprobar antes de cerrar y qué hacer si falla.

La memoria tampoco debería ser un diario infinito de conversaciones. Debe funcionar más como una base de decisiones operativas: qué se decidió, por qué, cuándo caduca y qué evidencia la respalda.

Cuando esas piezas mejoran, no has creado un modelo mejor. Has hecho el trabajo más repetible. Para un equipo pequeño, eso suele ser una ventaja mucho más defendible que una demo brillante.

Mi criterio para aplicarlo

No pondría a un agente a mutar su propio harness como comportamiento por defecto.

Primero instrumentaría el flujo actual y localizaría un patrón repetido: errores de uso de una API, revisiones que no detectan regresiones, tareas que se bloquean siempre en el mismo punto. Después permitiría proponer una modificación pequeña, la probaría fuera de la ruta principal y la promovería sólo si mejora una métrica que importa.

Es una disciplina más aburrida que «el agente se optimiza solo». Precisamente por eso tiene más opciones de sobrevivir a la primera semana.

El precedente Meta-Harness: End-To-End Optimization of Model Harnesses apunta en la misma dirección: el harness se puede optimizar, pero eso lo convierte en otro sistema que necesita evaluación, aislamiento y control de cambios.

La tesis útil

La próxima ventaja no vendrá sólo de elegir el modelo con una puntuación mayor. Vendrá de construir alrededor de él un sistema que pueda observar sus fallos, ensayar cambios con seguridad y conservar únicamente lo que demuestra valor.

Eso no es magia recursiva. Es ingeniería de producto aplicada a agentes.

Y si el agente puede ayudar a hacer ese trabajo, perfecto. Pero conviene no confundir quién propone el cambio con quién debe decidir que merece quedarse.