El diseño de harness para agentes de Anthropic cambió mi forma de pensar sobre los sistemas de IA
Llevaba cuatro horas viendo a una IA construir una estación de trabajo de audio digital. No era una demo de juguete — era un DAW basado en navegador con la Web Audio API, edición multipista y un visualizador de forma de onda. El agente había estado ejecutándose de forma autónoma todo el tiempo. Sin guía manual. Sin correcciones a mitad de sesión. Solo una IA avanzando funcionalidad tras funcionalidad, haciendo commits de código, probando su propio trabajo y siguiendo adelante.
Entonces se detuvo.
No porque se cayera. No porque se quedara sin contexto. Se detuvo porque otra IA — el evaluador — le indicó que la sincronización de reproducción de audio estaba desfasada por 12 milisegundos y que el renderizado de la forma de onda no coincidía con los datos reales de frecuencia. El agente generador volvió, corrigió ambos problemas y envió de nuevo. El evaluador lo probó una segunda vez, confirmó las correcciones y aprobó el sprint.
Esa interacción — dos agentes de IA discutiendo sobre calidad como un desarrollador y un ingeniero de QA — es el núcleo de lo que Anthropic publicó en su diseño de harness para el desarrollo de aplicaciones de larga duración. Y reconfiguró por completo mi forma de pensar sobre la construcción de sistemas autónomos.
El modelo no es el producto. El harness lo es.
Por qué tu agente de IA sigue fallando en tareas complejas
Este es un patrón que he vivido docenas de veces. Le das a un agente de IA un proyecto complejo — construir una aplicación full-stack, refactorizar un codebase grande, crear un sistema de diseño de varias páginas. El agente arranca con fuerza. Los primeros 20 minutos lucen prometedores. Pero alrededor de la marca de los 45 minutos, las cosas empiezan a torcerse. Se saltan pasos. La calidad baja. El agente declara el proyecto "completo" cuando está quizás al 60%.
Yo solía culpar al modelo. "Sonnet no es lo suficientemente inteligente para esto." "Necesito mejores prompts." "La ventana de contexto es demasiado pequeña."
La investigación de Anthropic invirtió ese diagnóstico por completo. El modelo rara vez era el cuello de botella. El harness lo era.
Un harness de agente es el framework de software que envuelve a un modelo de IA — gestionando prompts, orquestando herramientas, aplicando restricciones, manejando bucles de retroalimentación y validando la salida. Piénsalo así: el modelo de IA es un motor. Potencia bruta. El harness es el coche. Volante, frenos, transmisión, GPS. Sin el coche, el motor simplemente se queda en un banco de trabajo haciendo ruido.
Esta distinción importa más de lo que la mayoría de ingenieros de IA se dan cuenta. Puedes cambiar un V6 por un V8 (Sonnet por Opus), y obtendrás una mejora incremental. Pero rediseña el coche — cambia cómo el motor se conecta a las ruedas, añade un sistema de navegación, instala mejores frenos — y toda la experiencia de conducción se transforma.
Eso es lo que Anthropic demostró. No un modelo mejor. Un sistema mejor alrededor del modelo. Y los resultados fueron lo suficientemente impactantes como para que reconstruyera mis propios flujos de trabajo con agentes en una semana después de leer su artículo.
Pero antes de entrar en lo que construyeron, necesitas entender qué es lo que sigue saliendo mal — porque estos modos de fallo están escondidos en cada sistema de agentes de larga duración que he visto, incluyendo los que yo mismo construí.
Los dos modos de fallo de los que nadie habla con honestidad
Anthropic identificó dos modos de fallo críticos en agentes de larga duración. Los he experimentado ambos tantas veces que leer su análisis fue como si alguien hubiera instalado cámaras en mi entorno de desarrollo.
Ansiedad de contexto: cuando tu agente entra en pánico
La ansiedad de contexto es lo que ocurre cuando un modelo de IA detecta que se está acercando a los límites de su ventana de contexto. El comportamiento es sutil e insidioso. El agente no se cae. No lanza un error. En cambio, empieza a apresurarse. Los pasos se comprimen. Las explicaciones se vuelven escuetas. Subtareas complejas que deberían requerir una planificación cuidadosa se despachan con un gesto. El agente empieza a cerrar prematuramente — declarando victoria en un proyecto a medio terminar porque alguna señal interna está gritando "te estás quedando sin espacio."
Lo noté por primera vez con Sonnet 4.5 durante un proyecto de refactorización. Alrededor de la marca de 80K tokens, el agente pasó de un trabajo cuidadoso y metódico a lo que solo puedo describir como un speedrun ansioso. Dejó de leer archivos antes de editarlos. Se saltó las ejecuciones de tests. Empezó a generar comentarios como "los elementos restantes son sencillos y siguen el mismo patrón" — que en lenguaje de agente significa "me rindo y espero que no te des cuenta."
La solución de Anthropic involucra dos técnicas complementarias.
La compactación de contexto resume y condensa el historial de la conversación, preservando la información esencial mientras libera espacio de tokens. La IA esencialmente se escribe a sí misma un resumen comprimido de todo lo que ha ocurrido hasta el momento, y luego trabaja desde ese resumen en lugar del historial crudo. Tiene pérdida — se pierde algo de detalle — pero una buena estrategia de compactación preserva las decisiones críticas y el estado actual.
Los reinicios de contexto van más allá. En lugar de comprimir el contexto existente, le das al agente una ventana de contexto completamente nueva para cada sprint o subtarea. El agente arranca limpio, solo con la información que necesita para la parte actual del trabajo. El progreso no vive en la memoria del modelo — vive en archivos, commits de git y artefactos estructurados en disco.
Aquí está el avance que importa para los constructores: Opus 4.6 con su ventana de contexto de 1 millón de tokens ha eliminado en gran medida la ansiedad de contexto como preocupación práctica. La ventana es tan enorme que la mayoría de sesiones autónomas de varias horas nunca se acercan a llenarla. Anthropic descubrió que podían eliminar los reinicios de contexto por completo con Opus 4.6 y depender solo de la compactación. Lo que antes requería un complejo sistema de traspaso entre sesiones ahora se ejecuta como una sesión continua.
Eso no significa que la gestión de contexto esté resuelta para siempre. Si exiges mucho de Opus 4.6 — una sesión autónoma de un día completo con lectura extensiva de archivos — llegarás a los límites. Pero el umbral pasó de "un problema serio después de 45 minutos" a "un caso extremo después de más de 6 horas." Para la mayoría de tareas reales, esa es la diferencia entre necesitar una solución en el harness y no necesitarla en absoluto.
Fallo de autoevaluación: el agente que cree que todo lo que hace es genial
El segundo modo de fallo es más peligroso porque es más difícil de detectar.
Cuando le pides a un agente de IA que evalúe su propio trabajo, miente. No deliberadamente — pero sí de forma consistente. El patrón es predecible: el agente genera una salida, la revisa y concluye que la salida es buena. Incluso cuando, para un observador humano, la calidad es obviamente mediocre.
He visto esto ocurrir en tiempo real. Un agente construye una landing page con elementos desalineados, espaciado inconsistente y una paleta de colores que parece elegida por un generador de números aleatorios. Le pides al agente que evalúe el resultado. "El diseño es limpio y profesional, con buena jerarquía visual y espaciado consistente." Está describiendo el diseño que pretendía construir, no el que realmente construyó.
Esto no es un problema de prompting. Puedes añadir "sé crítico" y "busca defectos" al prompt del sistema, y el agente asentirá, fingirá ser crítico y luego aprobará su propio trabajo con algunas matizaciones simbólicas. "Aunque hay margen de mejora en la paleta de colores, el diseño general comunica eficazmente el mensaje de marca." Traducción: "Estoy fingiendo ser crítico mientras no cambio nada."
El diagnóstico de Anthropic es directo y, en mi experiencia, certero: hacer que un generador sea autocrítico es un problema fundamentalmente más difícil que construir un crítico separado y dedicado. La solución arquitectónica no es hacer que el generador sea mejor en autoevaluación. Es separar los roles por completo.
Lo cual nos lleva a la arquitectura que realmente funciona.
La arquitectura de tres agentes: Planificador, Generador, Evaluador
El diseño final del harness de Anthropic utiliza tres agentes especializados trabajando en conjunto. Si alguna vez has trabajado en un equipo con un product manager, un desarrollador y un ingeniero de QA — esto te resultará familiar. Porque es exactamente la dinámica que replicaron.
El Planificador
El Planificador toma un prompt simple — "construye una aplicación de gestión de proyectos con un tablero Kanban" — y lo expande en una especificación de producto detallada. Listas de funcionalidades. Historias de usuario. Requisitos técnicos. Dirección de diseño visual.
El Planificador es deliberadamente ambicioso. Anthropic descubrió que una planificación conservadora conducía a resultados mediocres. Cuando el Planificador apuntaba alto, el Generador producía aplicaciones más creativas y más completas — incluso si no alcanzaba todos los objetivos. Una especificación que pide "una interfaz hermosa, de calidad museística, con elementos 3D" produce mejores resultados que una que pide "una interfaz limpia y funcional." El listón alto tira de la salida hacia arriba.
Algo que Anthropic aprendió por las malas: el Planificador debería centrarse en el qué y el por qué, no en el cómo. Cuando el Planificador incluía detalles técnicos granulares de implementación, esos detalles propagaban errores en cascada a través del trabajo del Generador. Un Planificador que dice "implementa colaboración en tiempo real" es mejor que uno que dice "usa WebSockets con un patrón pub/sub en Redis" — porque el Generador podría encontrar un enfoque mejor que la especificidad prematura del Planificador habría impedido.
El Generador
El Generador trabaja en sprints, implementando una funcionalidad a la vez. Cada sprint tiene un alcance claro derivado de la especificación del Planificador, y el Generador hace commits de código de forma incremental — lo que significa que el progreso se preserva en git independientemente de lo que le ocurra al contexto del agente.
Este enfoque basado en sprints es donde veo el paralelismo más fuerte con cómo ya uso Claude Code. Cuando trabajo con la arquitectura de enjambre de agentes de Claude Code, se aplica el mismo principio: dividir el trabajo complejo en partes discretas, hacer el progreso visible a través de artefactos (archivos, commits, grafos de tareas) y nunca depender de la memoria del modelo como fuente de verdad.
El Generador también incluye un paso de autoevaluación integrado antes de entregar al Evaluador — una verificación rápida de cordura. Esto captura los problemas obvios (errores de sintaxis, imports faltantes, builds rotos) sin depender del Evaluador para cosas que el Generador debería detectar por sí mismo. Piénsalo como un desarrollador ejecutando sus propios tests antes de abrir un PR. Sigues necesitando code review, pero no deberías estar desperdiciando el tiempo del revisor con problemas que tu linter detectaría.
El Evaluador: donde está la verdadera innovación
El Evaluador es lo que hace que esta arquitectura sea genuinamente diferente de cualquier cosa que haya construido antes.
La mayoría de sistemas de evaluación de IA revisan código de forma estática — leen los archivos fuente, analizan la estructura y dan retroalimentación. El Evaluador de Anthropic no solo lee código. Usa la aplicación. A través de la automatización de navegador con Playwright, el Evaluador navega la aplicación en ejecución, hace clic en botones, rellena formularios, toma capturas de pantalla, prueba endpoints de API y examina estados de la base de datos. Interactúa con el producto en vivo de la misma forma en que lo haría un ingeniero de QA humano.
Los criterios de evaluación tampoco son vagos. Anthropic definió cuatro dimensiones específicas:
Calidad de diseño — ¿La salida visual cumple con estándares profesionales? Layout, tipografía, color, espaciado — medido contra la especificación del Planificador, no contra ideales abstractos.
Originalidad — ¿La salida parece contenido genérico de IA, o tiene una identidad creativa genuina? Este criterio existe específicamente para combatir el problema de "todo lo que construye la IA se ve igual." Cuando leí esto, inmediatamente pensé en la guía de sistemas de diseño con IA que escribí — el problema de que las interfaces generadas por IA converjan todas en la misma estética es real, y Anthropic está evaluando explícitamente contra ello.
Oficio — Calidad de ejecución técnica. Código limpio, manejo apropiado de errores, layouts responsivos, rendimiento. Lo que un ingeniero senior notaría durante un code review.
Funcionalidad — ¿La funcionalidad realmente funciona? No "¿el código parece correcto?" — ¿el botón hace lo que se supone que debe hacer cuando lo pulsas?
El Evaluador califica cada sprint contra estos criterios. Si las calificaciones no alcanzan el umbral, el Generador vuelve a iterar. Esto crea un bucle de retroalimentación que es estructuralmente idéntico a cómo funcionan las GANs (Redes Generativas Adversarias) — un generador intentando producir una salida que engañe al discriminador, y un discriminador mejorando en detectar deficiencias.
Esto es lo que me sorprendió: conseguir que el Evaluador funcionara bien requirió múltiples iteraciones. Los evaluadores iniciales basados en Claude de Anthropic tenían el mismo problema que la autoevaluación — eran demasiado indulgentes. Aprobaban trabajo mediocre con retroalimentación alentadora. Se necesitó ingeniería de prompts deliberada para hacer al Evaluador genuinamente adversarial. Un prompt de sistema escéptico. Instrucciones explícitas para buscar tipos específicos de fallo. Permiso para rechazar trabajo y exigir revisiones.
Este es el insight clave al que sigo volviendo: ajustar un evaluador dedicado para que sea escéptico es un problema fundamentalmente más manejable que hacer que un generador sea autocrítico. El evaluador tiene un solo trabajo — encontrar problemas. El generador tiene un incentivo en conflicto — quiere terminar. Separar estos roles no es solo buena arquitectura. Es necesario.
El contrato de sprint: alineando Generador y Evaluador antes de empezar a trabajar
Un detalle del diseño de Anthropic que no he visto discutido lo suficiente en otros lugares es el contrato de sprint.
Antes de que comience cada sprint, el Generador y el Evaluador negocian un contrato. El Generador propone lo que va a entregar. El Evaluador confirma que entiende los criterios de aceptación. Ambos agentes acuerdan qué significa "terminado" antes de que se escriba una sola línea de código.
Esto suena burocrático. No lo es. Es la diferencia entre un PR que se aprueba en la primera revisión y uno que rebota cinco veces porque el desarrollador y el revisor tenían expectativas diferentes.
Sin el contrato, he visto a agentes evaluadores rechazar trabajo por no cumplir estándares que nunca se comunicaron. El Generador construye una funcionalidad de una manera, el Evaluador la quería de otra, y el bucle de iteración quema tokens discutiendo sobre requisitos que deberían haberse acordado desde el principio.
El contrato resuelve esto haciendo las expectativas explícitas. "El Sprint 3 implementará el editor de niveles con colocación de sprites mediante drag-and-drop, una paleta de tiles de al menos 20 elementos y soporte de deshacer/rehacer. El Evaluador verificará la funcionalidad creando un nivel de prueba, colocando sprites y confirmando que deshacer funciona para al menos 5 operaciones secuenciales."
Esa especificidad — nombrar pruebas de aceptación exactas — elimina toda una clase de iteraciones desperdiciadas. Y es un patrón que he empezado a tomar prestado para mis propios flujos de trabajo con agentes, incluso fuera del diseño de harness de Anthropic.
Lo que los experimentos realmente mostraron
La teoría es una cosa. Anthropic ejecutó tres experimentos que pusieron esta arquitectura bajo presión real. Los resultados cuentan historias diferentes dependiendo de cuál mires.
Experimento 1: El sitio web del museo de arte holandés
La tarea: diseñar un sitio web para un museo de arte holandés ficticio. Este es un desafío subjetivo, centrado en el diseño, donde "bueno" es difícil de definir y más difícil de evaluar.
El harness pasó por más de 10 iteraciones de retroalimentación entre el Generador y el Evaluador. Las primeras versiones eran genéricas — el tipo de páginas con aspecto de plantilla que cualquier IA produce. Para la iteración 7 u 8, el diseño había evolucionado hacia algo genuinamente inusual: una visualización de sala 3D con un suelo ajedrezado, obras de arte exhibidas en paredes virtuales y una navegación que se sentía como caminar por una galería.
El punto no es que el diseño final fuera perfecto. Es que el bucle iterativo adversarial empujó la salida más allá de la meseta del "suficientemente bueno" que la generación de IA en una sola pasada siempre alcanza. El Generador seguía buscando soluciones más creativas porque el Evaluador seguía rechazando las seguras. Esa dinámica — presión para superar, no solo cumplir, los estándares — no ocurre cuando un agente se evalúa a sí mismo.
Experimento 2: El creador de juegos retro 2D
Este fue el experimento más revelador. Dos ejecuciones de la misma tarea: construir un creador de juegos retro 2D con un editor de niveles, un editor de sprites y un sistema de comportamientos.
Ejecución 1 (harness simple — solo Generador): La salida lucía visualmente aceptable en capturas de pantalla. Pero cuando realmente intentabas usarlo, el juego no funcionaba. Los sprites no se movían. El editor de niveles no podía guardar niveles. Era una aldea Potemkin de creador de juegos — presentable desde afuera, hueco por dentro.
Ejecución 2 (harness completo — Planificador + Generador + Evaluador): El Planificador creó especificaciones detalladas con definiciones explícitas de "terminado" para cada sprint. El Evaluador probó cada funcionalidad de forma interactiva usando Playwright, detectando fallos funcionales que el Generador habría declarado "completos." El resultado: un creador de juegos funcional. No de calidad AAA, pero funcional. Podías crear sprites, construir niveles, asignar comportamientos y realmente jugar el resultado.
La diferencia entre estas dos ejecuciones es todo el argumento a favor de la ingeniería de harness en un solo ejemplo. Mismo modelo. Misma tarea. Mismo presupuesto de cómputo. La única diferencia fue el sistema envuelto alrededor del modelo.
Experimento 3: El DAW en navegador
La prueba más ambiciosa: construir una estación de trabajo de audio digital en el navegador usando la Web Audio API, ejecutándose en Opus 4.6.
Este experimento se completó en aproximadamente 4 horas a un costo de aproximadamente $125 en llamadas a la API. El resultado era funcional — audio multipista, visualización de forma de onda, edición básica — pero no de nivel profesional. Más importante aún, este experimento demostró cómo las mejoras en los modelos simplifican los requisitos del harness.
Con la ventana de contexto de un millón de tokens de Opus 4.6, Anthropic eliminó los sprints por completo. Sin reinicios de contexto. Sin negociación de contratos entre Generador y Evaluador. Solo una sesión continua con compactación automática gestionando el crecimiento del contexto. El harness que Sonnet 4.5 necesitaba — complejo, multisesión, gestionando cuidadosamente los límites de contexto — se volvió innecesario.
Esta es la conclusión más importante para los constructores: tus suposiciones sobre el harness tienen que evolucionar con el modelo. Un harness diseñado para las limitaciones de Sonnet 4.5 sobreingeniará la capa de orquestación cuando se ejecute en Opus 4.6. Y un harness diseñado para las capacidades de Opus 4.6 se romperá cuando el siguiente modelo introduzca nuevos comportamientos o elimine los antiguos. La ingeniería de harness no es una configuración única. Es una práctica continua.
Si prefieres que alguien construya este tipo de sistema de harness multiagente para tu caso de uso, acepto encargos personalizados de desarrollo de agentes de IA. Puedes ver lo que he construido en fiverr.com/s/EgxYmWD.
Cómo esto se conecta con patrones que ya conoces
El diseño de harness de Anthropic no existe en el vacío. Se sitúa junto a otros dos patrones que todo constructor serio de agentes debería entender — porque resuelven piezas adyacentes del mismo rompecabezas.
El bucle Ralph Wiggum
Creado por Geoffrey Huntley y formalizado por Boris Cherny (Head de Claude Code en Anthropic) a finales de 2025, el bucle Ralph Wiggum es elegante en su simplicidad. Ejecutas un agente en un bucle bash. Después de cada iteración, verificas la salida contra algo que no puede mentir — un linter, un verificador de tipos, una suite de tests. Si pasa, te detienes. Si falla, repites.
El insight clave: el progreso vive en archivos y en el historial de git, no en la ventana de contexto del modelo. Cada iteración arranca con contexto fresco. El agente lee el estado actual del codebase, trabaja en él y hace commit de los cambios. Si el bucle necesita continuar, la siguiente iteración lee los archivos actualizados con cero deuda de contexto acumulada.
Este patrón es ahora un plugin de primera clase en Claude Code. Puedes ejecutar /ralph-loop "Fix all TypeScript errors" --max-iterations 20 --completion-promise "ALL_FIXED" e irte.
Donde el bucle Ralph Wiggum difiere del harness de tres agentes de Anthropic: funciona mejor para tareas objetivamente verificables. "Corrige todos los errores de linting" tiene una verdad binaria — el linter pasa o no pasa. "Construye un creador de juegos hermoso y funcional" no la tiene. Esa brecha subjetiva es exactamente lo que el evaluador adversarial llena.
Desarrollo dirigido por especificaciones
La tercera pieza del rompecabezas es estructurar los requisitos antes de que el agente empiece a programar. Frameworks como Spec Kit de GitHub, BMAD-METHOD y OpenSpec resuelven todos el mismo problema: agentes que empiezan a programar antes de entender lo que están construyendo.
Esto se mapea directamente al agente Planificador en el diseño de Anthropic. El Planificador es esencialmente un redactor automático de especificaciones. Pero no necesitas un agente Planificador dedicado para obtener el beneficio. Escribir una especificación clara — funcionalidades, criterios de aceptación, definición de terminado — antes de entregar el trabajo a un agente produce resultados dramáticamente mejores que lanzar un prompt vago a un modelo y esperar lo mejor.
El enfoque dirigido por especificaciones también explica por qué el experimento del creador de juegos mostró resultados tan diferentes entre la ejecución simple y la del harness completo. La ejecución simple no tenía especificación. El agente fue improvisando sobre la marcha, reduciendo sus ambiciones con cada paso hasta que "creador de juegos" se convirtió en "algunos elementos de UI que parecen relacionados con juegos." La ejecución con harness completo tenía una especificación explícita con definiciones de terminado — y un evaluador que las hacía cumplir.
He estado usando una versión de esto en mi propio trabajo desde que construí la guía del SDK de agentes de Anthropic. Cada tarea compleja de agente ahora comienza con una especificación escrita. No porque el agente no pueda trabajar sin una — sino porque la especificación es el ancla que previene la deriva de alcance, la finalización prematura y la muerte lenta de la ambición que afecta a toda sesión de IA de larga duración.
Qué significa esto para cómo construyes agentes ahora mismo
Aquí es donde quiero ser práctico. La investigación de Anthropic está construida sobre el Claude Agent SDK, pero los principios aplican independientemente de qué modelo o framework estés usando. Si estás construyendo algo que se ejecuta de forma autónoma durante más de 15 minutos, esto es lo que yo tomaría de este trabajo.
Separa la generación de la evaluación. Siempre.
Este es el cambio individual de mayor impacto que puedes hacer en cualquier flujo de trabajo con agentes. Si tu agente genera salida y evalúa esa salida en el mismo contexto, tienes un problema de fiabilidad. Puede que no se manifieste en tareas simples. Pero en el momento en que la complejidad aumenta — cambios en múltiples archivos, requisitos subjetivos de calidad, interdependencias entre funcionalidades — la autoevaluación falla silenciosamente.
No necesitas un sistema adversarial sofisticado para empezar. Un segundo agente con un prompt de sistema escéptico que revise la salida del primer agente es suficiente para detectar los fallos más flagrantes de autoaprobación. Yo ejecuto una versión de esto en mi pipeline de contenido, y el evaluador rechaza aproximadamente el 30% de los primeros borradores — borradores que, sin control, habrían salido con problemas estructurales que yo detectaría durante la revisión manual.
Usa artefactos, no memoria, como tu fuente de verdad
Cada pieza de progreso debería existir fuera de la ventana de contexto del modelo. Commits de git. Archivos JSON de tareas. Especificaciones en Markdown. Logs estructurados. Si la sesión de tu agente se cae y el único registro de lo que ocurrió vive en el historial de la conversación — has construido un sistema frágil.
Este es el mismo principio detrás de la arquitectura de grafo de tareas persistente de Claude Code. El grafo de tareas vive en disco. Los agentes lo leen, lo actualizan y escriben de vuelta en él. Las ventanas de contexto van y vienen. El grafo de tareas persiste.
Ajusta la complejidad de tu harness a las capacidades de tu modelo
La propia evolución de Anthropic demuestra este punto. El harness que construyeron para Sonnet 4.5 — con reinicios de contexto, límites de sprint, negociación de contratos — era necesario porque el modelo lo necesitaba. El harness que construyeron para Opus 4.6 eliminó la mitad de esos componentes porque la ventana de contexto de un millón de tokens del modelo y su consistencia mejorada los hacían innecesarios.
Audita tu propio harness. ¿Estás ejecutando gestión de contexto compleja porque el modelo realmente lo necesita, o porque diseñaste el sistema hace seis meses cuando el modelo sí lo necesitaba? Sobreingeniar la capa de orquestación desperdicia tokens, añade latencia e introduce puntos de fallo que el modelo actual podría manejar por sí solo.
Define "terminado" antes de empezar
El patrón de contrato de sprint — donde Generador y Evaluador acuerdan criterios de aceptación antes de que empiece el trabajo — aplica a toda interacción con agentes, no solo a sistemas multiagente. Cuando le pides a un agente que "construya un dashboard," define qué debe incluir el dashboard, cómo verificarás cada funcionalidad y qué nivel de calidad esperas. Cuanto más explícita sea tu definición de terminado, menos margen tiene el agente para declarar una victoria prematura.
Las limitaciones honestas: lo que la ingeniería de harness no puede arreglar
Te haría un mal servicio si te dejara ir pensando que la ingeniería de harness es una bala de plata. No lo es. Después de pasar semanas implementando estos patrones, aquí están los muros contra los que me he estrellado.
El costo se acumula rápido. El experimento del DAW en navegador costó $125 en llamadas a la API por aproximadamente 4 horas de trabajo autónomo. Un sistema de tres agentes quema aproximadamente 3 veces los tokens de un enfoque de agente único porque estás ejecutando tres modelos (o tres sesiones del mismo modelo) en coordinación. Para proyectos personales y experimentos, está bien. Para sistemas en producción ejecutándose 24/7, la economía necesita un modelado cuidadoso.
La calidad del evaluador es el techo. Tu sistema solo puede ser tan bueno como la capacidad de tu evaluador para detectar problemas. Si el evaluador no puede identificar un desalineamiento sutil de UI o una condición de carrera en código asíncrono, esos problemas se despliegan. Anthropic lo reconoció — sus evaluadores iniciales pasaron por alto bugs sutiles y aprobaron implementaciones superficiales. Conseguir que el evaluador funcionara bien requirió iteración, no solo ajustes de prompts.
La calidad subjetiva sigue siendo difícil. El experimento del museo holandés mostró una mejora impresionante a través de la iteración adversarial. Pero "impresionante para IA" e "impresionante comparado con un diseñador humano con 10 años de experiencia" son niveles diferentes. La ingeniería de harness reduce esa brecha. No la cierra. Para trabajo creativo subjetivo — diseño, escritura, música — la evaluación humana sigue siendo necesaria en la etapa final.
La depuración del harness es una habilidad en sí misma. Cuando un solo agente produce una salida deficiente, la depuración es directa: lee la conversación, encuentra dónde se torció y arregla el prompt. Cuando un sistema de tres agentes produce una salida deficiente, el fallo podría estar en la especificación del Planificador, la implementación del Generador, los criterios del Evaluador o la interacción entre cualquier par de ellos. He pasado más tiempo depurando interacciones del harness que el que jamás pasé depurando prompts de agentes individuales.
Estas son limitaciones reales. No invalidan el enfoque — el experimento del creador de juegos demuestra que la arquitectura de tres agentes produce resultados dramáticamente mejores que la generación en solitario. Pero significan que la ingeniería de harness es una práctica que demanda iteración, monitoreo y refinamiento continuo. No un patrón que implementas una vez y olvidas.
Hacia dónde va esto
Anthropic publicó dos artículos sobre este tema — el primero en noviembre de 2025 centrado en el patrón de inicializador-y-agente-programador, y la continuación de marzo de 2026 introdujo la arquitectura completa de tres agentes con evaluación adversarial. La trayectoria te dice hacia dónde se dirige esto.
Las mejoras en los modelos simplifican el diseño del harness. Opus 4.6 eliminó la necesidad de reinicios de contexto. La próxima generación podría eliminar la necesidad de compactación explícita de contexto. Pero las mejoras en los modelos no eliminan la necesidad de orquestación y evaluación. Incluso un modelo hipotéticamente perfecto — uno con contexto infinito, memoria perfecta y cero errores de razonamiento — seguiría produciendo mejor salida con un evaluador separado desafiando su trabajo. Eso no es una limitación del modelo. Es un insight fundamental sobre cómo la calidad emerge de la presión adversarial.
La predicción práctica que haría: en 12 meses, las plataformas de harness-como-servicio serán tan comunes como las plataformas de RAG-como-servicio lo son hoy. Herramientas como Ralph Loop Agent de Vercel y el creciente ecosistema alrededor de frameworks de desarrollo dirigido por especificaciones como Spec Kit de GitHub son señales tempranas. La materia prima — modelos, capacidades de uso de herramientas, APIs de evaluación — ya está lista para producción. Lo que falta es la capa de orquestación empaquetada que lo haga accesible para ingenieros que no quieren construir infraestructura de harness desde cero.
Para los constructores que trabajan en este espacio ahora mismo, la oportunidad es clara. El harness es el producto. El modelo es un commodity. Los equipos e ingenieros que se vuelvan buenos en diseño de harness — que aprendan a descomponer tareas, construir evaluadores fiables, gestionar el contexto de forma efectiva e iterar sus patrones de orquestación junto con las mejoras de los modelos — construirán sistemas de IA que funcionen en producción mientras todos los demás siguen luchando con prompts de agente único que se desmoronan después de 30 minutos.
¿Esa sesión del DAW que vi? Cuatro horas de programación autónoma que produjeron una aplicación funcional. No porque el modelo fuera mágico. Porque el sistema a su alrededor estaba diseñado para mantener al modelo honesto, enfocado y en iteración hasta que el trabajo estuviera realmente terminado.
Esa es la lección. No mejor IA. Mejores sistemas alrededor de la IA.
Preguntas frecuentes
¿Qué es un harness de agente en el desarrollo de IA?
Un harness de agente es el framework de software que envuelve a un modelo de IA para gestionar prompts, herramientas, bucles de retroalimentación y validación — convirtiendo un modelo crudo en un sistema autónomo fiable. Piénsalo como el coche que hace útil al motor: dirección, frenos, navegación y todo lo demás. Para un desglose más detallado, consulta la sección "Por qué tu agente de IA sigue fallando" más arriba.
¿Cómo afecta la ansiedad de contexto a los agentes de IA?
La ansiedad de contexto ocurre cuando los modelos de IA detectan que se acercan a los límites de la ventana de contexto y comienzan a apresurarse, saltar pasos o declarar tareas completas prematuramente. Sonnet 4.5 exhibía este comportamiento alrededor de los 80K tokens. La ventana de un millón de tokens de Opus 4.6 elimina en gran medida el problema para sesiones de menos de 6 horas. Consulta la sección de modos de fallo para estrategias de mitigación.
¿Cuál es la diferencia entre compactación de contexto y reinicio de contexto?
La compactación de contexto resume el historial de la conversación para liberar espacio de tokens mientras preserva información clave — con pérdida pero continua. El reinicio de contexto inicia al agente con una ventana de contexto completamente nueva para cada subtarea, dependiendo de archivos y artefactos para el estado. Los modelos más nuevos con ventanas de contexto más grandes favorecen la compactación sobre los reinicios.
¿Cómo mejora la evaluación adversarial la salida de los agentes de IA?
La evaluación adversarial separa la generación de contenido de la evaluación de calidad usando dos agentes distintos — inspirada en la arquitectura GAN. El agente evaluador usa herramientas como Playwright para probar interactivamente aplicaciones en ejecución, detectando fallos funcionales que la revisión de código por sí sola no detecta. Los experimentos de Anthropic mostraron que esto produce aplicaciones funcionales donde la generación en solitario produce una salida visualmente similar pero no funcional.
¿Puedo implementar patrones de harness de agente sin el Claude Agent SDK?
Sí. Los principios — descomposición de tareas, estado basado en artefactos, evaluación separada, contratos de sprint — son agnósticos al modelo y al framework. El Claude Agent SDK proporciona abstracciones convenientes, pero puedes implementar los mismos patrones con cualquier API de modelo, una capa de orquestación en Python y herramientas estándar como Playwright para la evaluación.
Trabajemos juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.
- Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
