Anthropic ha publicado uno de esos textos que interesan mucho más de lo que parece a simple vista. No presenta un nuevo modelo ni un benchmark espectacular, pero sí enseña algo que empieza a ser igual de importante en la práctica: cómo diseñar el entorno de trabajo de un agente para que pueda construir aplicaciones completas durante horas sin degradarse demasiado por el camino. En su artículo técnico, la compañía explica cómo pasó de experimentos limitados con Claude a una arquitectura multiagente capaz de producir interfaces mejores, aplicaciones más completas y sesiones de desarrollo autónomo mucho más largas.
La idea de fondo es sencilla de entender, aunque no tanto de ejecutar. Anthropic sostiene que el problema ya no es solo qué tan bueno es el modelo, sino qué “harness” o andamiaje se construye alrededor de él: qué agentes participan, cómo se dividen las tareas, cómo se gestiona el contexto, cómo se evalúa el trabajo y cómo se evita que el sistema se felicite a sí mismo aunque el resultado sea mediocre. El artículo fue publicado el 24 de marzo y lo firma Prithvi Rajasekaran, del equipo de Labs de Anthropic.
El verdadero cuello de botella no siempre es el modelo
Anthropic parte de dos problemas que ya había detectado en sus pruebas anteriores. El primero es la pérdida de coherencia en tareas largas. Según la compañía, cuando una sesión crece demasiado, el agente empieza a sufrir dos fenómenos: por un lado, el deterioro habitual de trabajar con demasiado contexto; por otro, algo que describe como “context anxiety”, una tendencia del modelo a intentar cerrar antes la tarea porque “cree” que se está acercando a su límite de contexto. En trabajos anteriores, la solución había sido reiniciar contexto y pasar el estado mediante artefactos estructurados. En documentación reciente, Anthropic también explica que en agentes de largo recorrido el contexto puede degradarse incluso antes de alcanzar el límite duro de tokens, un fenómeno que relaciona con el llamado context rot.
El segundo problema es todavía más interesante porque afecta directamente a la calidad final: la mala autoevaluación. Anthropic reconoce que, cuando se pide a un agente que juzgue su propio trabajo, tiende a ser demasiado benévolo, especialmente en tareas subjetivas como el diseño visual. En vez de detectar que una interfaz es genérica o poco inspirada, el sistema suele describirla como correcta, suficiente o incluso buena. De ahí sale una de las ideas centrales del post: separar al agente que genera del agente que evalúa.
De un generador optimista a un evaluador escéptico
Para romper ese techo, Anthropic tomó inspiración de las GAN y montó primero una estructura de dos agentes: un generador y un evaluador. En la parte de diseño frontend, el evaluador puntuaba la interfaz con criterios definidos de antemano: calidad del diseño, originalidad, ejecución técnica y funcionalidad. La empresa explica que dio más peso a la calidad visual y a la originalidad que a la mera corrección técnica, precisamente para sacar a Claude del patrón de “AI slop” funcional pero poco memorable. El evaluador, además, usaba Playwright para navegar por la página y revisarla activamente antes de emitir su crítica.
Ese enfoque terminó desembocando en una arquitectura de tres agentes para desarrollo full-stack: un planner que amplía una instrucción breve en una especificación de producto, un generator que implementa la app, y un evaluator que la prueba y la critica. La propia documentación del Agent SDK encaja con ese enfoque, ya que Anthropic lo presenta como una forma de usar Claude Code como librería, con las mismas herramientas, bucle de agente y gestión de contexto que tiene Claude Code, pero programables en Python o TypeScript.
El experimento que mejor explica por qué importa esto
Uno de los ejemplos más reveladores del artículo es la creación de un editor retro de videojuegos en 2D. Anthropic lanzó dos pruebas con el mismo objetivo: una con un solo agente y otra con el harness completo. El resultado no fue una mejora marginal. La versión simple costó 9 dólares y tardó 20 minutos; la completa llegó a 200 dólares y se alargó durante 6 horas. Pero la diferencia, según Anthropic, era evidente: el sistema con planner, generator y evaluator produjo una aplicación más rica, con una especificación de 16 funciones repartidas en diez sprints, mejor interfaz, más herramientas y, sobre todo, una experiencia jugable real. La versión de un solo agente parecía razonable a primera vista, pero tenía fallos importantes, incluido un modo de juego roto.
Ahí aparece otro punto clave del artículo: el evaluador no solo “juzga”, también encuentra errores que el generador no detecta. Anthropic muestra ejemplos concretos de fallos descubiertos por ese agente de QA, desde herramientas del editor que no rellenaban correctamente áreas rectangulares hasta rutas de API mal ordenadas en FastAPI o errores al eliminar entidades del nivel. La empresa admite incluso que afinar al evaluador costó varias iteraciones porque, de forma predeterminada, Claude no era un buen agente de control de calidad.
Con Opus 4.6, menos andamiaje y sesiones más largas
La segunda parte del artículo es casi tan importante como la primera. Cuando Anthropic pasó a Opus 4.6, decidió simplificar el harness porque el modelo aguantaba mejor tareas largas por sí solo. Eliminó la estructura por sprints y movió la evaluación al final de cada ronda de construcción, manteniendo el planner y el evaluator, pero reduciendo complejidad. El resultado fue un nuevo experimento: construir una DAW en el navegador con Web Audio API. El sistema tardó 3 horas y 50 minutos y costó 124,70 dólares en tokens. El agente principal trabajó más de dos horas seguidas sin la descomposición por sprints que sí había necesitado Opus 4.5.
El mensaje aquí es muy útil para cualquiera que trabaje con agentes: cuando cambia el modelo, también cambia qué partes del harness siguen siendo necesarias. Anthropic lo formula de forma bastante clara: cada componente extra en un sistema de agentes representa una suposición sobre algo que el modelo no puede hacer bien por sí mismo, y esas suposiciones hay que volver a ponerlas a prueba con cada nueva versión. Esta idea encaja con otro texto oficial de la compañía, “Building effective agents”, donde defiende que los mejores sistemas suelen apoyarse en patrones simples y componibles, no en marcos excesivamente complejos desde el principio.
Lo más valioso del post no es la receta, sino la dirección
El artículo de Anthropic deja una conclusión bastante sólida para equipos técnicos, startups y desarrolladores avanzados. Los modelos ya son suficientemente buenos como para resolver muchas tareas complejas, pero el salto grande no siempre llega por cambiar de modelo, sino por rediseñar el entorno en el que trabajan. Un planificador que amplía una instrucción pobre, un generador centrado en construir y un evaluador escéptico pueden ofrecer mejores resultados que un solo agente muy capaz trabajando a ciegas.
También deja una segunda lección igual de importante: no existe un harness eterno. Lo que funcionaba bien con una versión de Claude puede dejar de ser óptimo cuando el modelo mejora en contexto, memoria o razonamiento. En ese sentido, el post de Anthropic es menos un tutorial cerrado que una invitación a experimentar. Y quizá ese sea su mayor valor: recordar que, en la nueva ingeniería de agentes, el modelo importa mucho, pero el diseño del sistema que lo rodea importa cada vez más.
Preguntas frecuentes
¿Qué es exactamente un harness en agentes de IA?
En este contexto, es el conjunto de reglas, agentes, herramientas, archivos y flujos de trabajo que rodean al modelo para ayudarle a ejecutar tareas complejas con más consistencia. Anthropic lo usa para dividir trabajo, pasar contexto, evaluar resultados y mantener al agente enfocado durante sesiones largas.
¿Por qué Anthropic separa un generador y un evaluador?
Porque, según sus pruebas, los agentes tienden a valorar demasiado bien su propio trabajo. Separar generación y evaluación permite construir un bucle de crítica más útil y convertir juicios subjetivos, como la calidad de un diseño, en criterios más concretos y puntuables.
¿Qué papel juega el Agent SDK en este enfoque?
Anthropic explica que el Agent SDK permite construir agentes programables con las mismas herramientas, bucle y gestión de contexto que usa Claude Code. Eso facilita montar sistemas multiagente con acceso a archivos, shell, web y configuración basada en .claude/.
¿Significa esto que un buen harness sustituye a un buen modelo?
No. El propio artículo sugiere lo contrario: el harness amplifica el rendimiento del modelo, pero también debe revisarse cuando el modelo mejora. De hecho, Anthropic simplificó parte del sistema al pasar de Opus 4.5 a Opus 4.6 porque algunas piezas dejaron de ser tan necesarias.
vía: anthropic
