En tareas largas, el rendimiento del agente depende menos del modelo y más del arnés

He leído esta pieza de Anthropic sobre harness design para apps de larga duración y creo que toca un tema bastante más importante que el titular técnico.

No va realmente de un "harness".

Va de algo más incómodo: en cuanto un agente trabaja durante horas, ya no estás comparando modelos; estás diseñando un sistema.

Y ese matiz cambia bastante la conversación.

El error habitual: pensar que más tiempo sólo requiere más contexto

Cuando un agente falla en una tarea larga, la explicación rápida suele ser esta:

le faltó contexto,
el prompt no era suficientemente bueno,
o el modelo todavía no da para tanto.

A veces es verdad.

Pero muchas veces el problema es otro: hemos tratado una ejecución de varias horas como si fuera una conversación larga.

Y no es lo mismo.

Una conversación larga puede sobrevivir con memoria, contexto y algo de paciencia.

Una tarea larga, en cambio, empieza a sufrir cosas bastante más parecidas a las de cualquier sistema complejo:

pérdida de foco,
degradación del criterio,
cierres prematuros,
validación indulgente,
acumulación de errores pequeños,
y una tendencia peligrosa a confundir “parece hecho” con “funciona de verdad”.

Mi lectura es simple: el problema de los agentes largos no es sólo cognitivo; es operacional.

El salto importante no es “más agente”, sino separar funciones

Lo más interesante de estos enfoques no es que metan tres agentes en vez de uno.

Es que dejan de asumir que la misma instancia debe:

entender el problema,
decidir el plan,
ejecutar,
evaluarse,
y además tener buen gusto y mala leche al revisarse.

Eso casi nunca sale bien.

En humanos tampoco.

Hay una razón por la que en equipos sanos se separan cosas como:

producto,
implementación,
QA,
revisión,
y validación de criterios de calidad.

No es burocracia gratuita. Es una forma de reducir sesgos y aislar errores.

Con agentes pasa algo parecido.

En cuanto separas al que construye del que evalúa, aparece algo muy valioso: fricción útil.

Y la fricción útil suele ser una buena señal en sistemas agentic.

El mayor problema de un agente no es que se equivoque. Es que se felicite por ello

Este punto me parece clave.

Un agente puede cometer errores, claro.

Pero el error realmente caro aparece cuando además los justifica, los minimiza o los da por buenos.

Ahí ya no tienes sólo una ejecución imperfecta. Tienes una ejecución que se autoaprueba.

Eso explica por qué muchos prototipos agentic impresionan durante cinco minutos y decepcionan durante cinco días.

Desde fuera parecen capaces porque producen mucho.

Desde dentro no tienen suficiente capacidad para distinguir entre:

avance real,
output presentable,
funcionalidad profunda,
y maquillaje convincente.

Dicho de otra forma: a muchos agentes les sobra entusiasmo y les falta criterio adversarial.

Por eso me parece tan potente la idea de introducir una capa de evaluación explícita, separada y entrenada para desconfiar un poco más.

La evaluación no debería preguntar “¿está bien?” sino “¿qué ha quedado mal?”

En muchos flujos de trabajo con IA seguimos evaluando demasiado en abstracto.

Preguntas tipo:

¿qué te parece el resultado?
¿está listo?
¿cumple el objetivo?

Eso produce respuestas bonitas y bastante poco útiles.

Para tareas largas, la evaluación debería parecerse mucho más a esto:

qué promesa concreta no se ha cumplido,
qué interacción falla al probarla,
qué parte está simulada en vez de implementada,
qué detalle parece correcto pero no aguanta uso real,
y qué coste introduce esta solución a la siguiente iteración.

Es decir: menos juicio general y más evidencia operativa.

Para mí, ese es uno de los aprendizajes más transferibles.

No sólo para grandes harnesses. También para cualquier agente que quieras usar en producción.

En tareas largas, los handoffs importan más que el contexto bruto

Otro punto que me parece muy relevante: no siempre gana el sistema que más contexto arrastra.

A veces gana el que mejor sabe cortar, resumir y relanzar.

Esto va un poco contra la intuición popular de “si el contexto es enorme, mejor”.

No necesariamente.

Mucho contexto puede ayudar, sí.

Pero también puede traer:

ruido,
sesgos arrastrados,
decisiones antiguas que ya no convienen,
y una especie de inercia que hace que el agente siga avanzando por una mala línea sólo porque ya la empezó.

En sistemas largos, un buen handoff vale muchísimo porque obliga a responder preguntas sanas:

qué estado hay que preservar de verdad,
qué decisiones siguen vigentes,
qué errores no deben repetirse,
y cuál es el siguiente paso útil.

Eso se parece bastante a una disciplina de ingeniería, no a una conversación infinita.

El arnés bueno no mete complejidad por postureo

Aquí hay una trampa bastante común.

En cuanto alguien descubre que separar planner, builder y evaluator mejora algo, la tentación es añadir más capas:

más agentes,
más contratos,
más validaciones,
más handoffs,
más procesos,
más sofisticación aparente.

Y eso puede convertir el sistema en una máquina carísima de producir latencia.

Mi criterio aquí sería bastante duro:

cada pieza extra del harness debería justificar qué error reduce y qué valor añade.

Si no puedes explicarlo de forma operativa, probablemente sobra.

Porque cada componente adicional también tiene coste:

más tokens,
más tiempo,
más puntos de fallo,
más complejidad de observabilidad,
y más dificultad para saber qué parte estaba haciendo realmente el trabajo importante.

La buena noticia es que esto también implica otra cosa: a medida que mejoran los modelos, parte del arnés debería desaparecer.

Y eso es sano.

La complejidad útil es temporal

Me interesa mucho esta idea: un harness es, en el fondo, una colección de prótesis para las debilidades actuales del modelo.

Eso significa que hay que revisarlo continuamente.

No para complicarlo siempre más, sino para preguntar:

qué parte sigue siendo necesaria,
qué parte ya se volvió redundante,
qué parte hay que rediseñar porque el modelo cambió,
y qué nueva frontera sí merece intervención.

Este punto me parece especialmente importante para equipos que construyen encima de modelos en rápida evolución.

Si no revisas el harness, te puede pasar cualquiera de estas dos cosas:

te quedas corto y el sistema falla por ingenuo,
te pasas y el sistema funciona, pero con un coste y una lentitud absurdos para lo que ya podría resolver el modelo solo.

Las dos son malas decisiones.

El paralelismo útil con producto y software clásico

Lo que más me interesa de todo esto es que acerca los agentes a preguntas muy clásicas de construcción de software:

dónde están los límites del sistema,
qué parte decide,
qué parte valida,
dónde está la fuente de verdad,
cómo se traspasa estado,
y cómo se detecta una falsa sensación de completitud.

Eso me gusta porque saca la conversación del terreno mágico.

En vez de “mira qué listo es el modelo”, pasamos a “cómo diseñamos un sistema que degrade bien, se revise bien y no se crea sus propias mentiras”.

Ese cambio de marco es muy sano.

Mi lectura práctica para builders y equipos pequeños

Si yo tuviera que aterrizar esto a algo utilizable, me quedaría con cinco ideas.

1. No metas multiagente por defecto

Empieza simple.

Pero en cuanto detectes que el agente:

se autoaprueba demasiado,
se pierde en tareas largas,
o entrega cosas vistosas pero poco fiables,

entonces sí tiene sentido separar ejecución y evaluación.

2. Define criterios antes de evaluar

Si el revisor no sabe qué significa “bueno” en ese contexto, sólo generará opinión.

Y opinión no es QA.

Necesitas criterios observables, aunque sean imperfectos.

3. Los contratos intermedios son muy útiles

No hace falta llamarlos sprint contracts si no quieres.

Pero sí hace falta que, antes de construir, quede claro:

qué se va a hacer,
qué no se va a hacer todavía,
y cómo sabremos que la iteración sirve.

Eso evita muchísimo autoengaño.

4. La revisión debe buscar fricción, no paz

Si tu evaluador siempre está contento, no tienes evaluador.

Tienes un animador.

5. Revisa periódicamente cuánto harness sigues necesitando

Cada mejora del modelo mueve la frontera.

Lo que ayer era esencial mañana puede ser lastre.

Lo que esto dice de los agentes en 2026

Mi conclusión es bastante clara.

La conversación madura sobre agentes ya no va sólo de prompts, herramientas o modelos más listos.

Va de arquitectura de trabajo.

De cómo repartes funciones.

De cómo introduces verificación.

De cómo gestionas tareas largas sin perder coherencia.

Y de cómo evitas que el sistema confunda una demo convincente con un resultado sólido.

Eso, por cierto, también es una buena señal.

Significa que el campo está dejando atrás parte del hype más infantil y entrando en una fase más interesante: la de diseñar sistemas que realmente aguanten uso real.

Idea final

Si tuviera que quedarme con una sola idea, sería esta:

en tareas largas, el rendimiento del agente depende cada vez menos de una única conversación brillante y cada vez más del sistema que la contiene.

El modelo sigue importando, claro.

Pero cuando el trabajo dura horas, toca producción, acumula estado y necesita criterio de verdad, lo decisivo ya no es sólo la inteligencia generativa; es el diseño del arnés.

Y ahí es donde se empieza a separar el juguete del sistema.

Si quieres leer la pieza original que me ha servido de excusa para pensar sobre esto, es Harness design for long-running application development, de Anthropic.