En 2026, en la industria de la IA surgió un nuevo consenso: lo que decide si un producto de IA es bueno o malo ya no es el modelo en sí, sino la capa que va fuera del modelo, llamada «harness». Cuando los modelos subyacentes que usan Claude Code, Cursor y OpenClaw se parecen cada vez más, lo que realmente marca la diferencia entre productos es el diseño del harness. El blog técnico de Martin Fowler, el responsable de producto de Anthropic trq212, y también las declaraciones recientes de Andrej Karpathy apuntan en la misma dirección: el próximo campo de batalla de la IA es el Harness Engineering.
¿Qué es Agent Harness?
Un agente de IA se puede descomponer en dos partes: el modelo (Model) y el harness. El modelo es el cerebro y se encarga de comprender el lenguaje y razonar. El harness es todo lo que está fuera del modelo: llamadas a herramientas, gestión de memoria, ensamblaje del contexto, persistencia del estado, manejo de errores, salvaguardas de seguridad, planificación de tareas y gestión del ciclo de vida.
Con una analogía intuitiva: el LLM es un caballo, y el harness es el equipo del caballo: riendas, silla de montar y la estructura de conexión al carruaje. Sin el equipo, aunque el caballo sea fuerte, no puede tirar del carruaje. Un agente de IA es igual: aunque el modelo sea más inteligente, si no hay un buen harness no puede completar tareas reales de forma fiable.
Akshay Pachaar propuso otra analogía en un tuit muy compartido: «Un LLM desnudo es como una CPU sin sistema operativo: puede calcular, pero por sí solo no puede hacer nada útil». El harness es ese sistema operativo.
Por qué de repente en 2026 el Harness Engineering se vuelve importante
Hay tres razones:
Primera: la capacidad de los modelos tiende a homogeneizarse. Las diferencias entre GPT-5.4, Claude Opus 4.6 y Gemini 3.1 Pro en la mayoría de las pruebas de referencia ya se han reducido a un solo dígito de puntos porcentuales. Cuando el modelo deja de ser el cuello de botella, la diferenciación del producto se desplaza naturalmente a la capa del harness.
Segunda: el agente pasa de los experimentos a la producción. En 2025, la mayoría de los agentes eran demos; en 2026, los agentes deben funcionar en entornos empresariales: necesitan manejar recuperación ante interrupciones, ejecución de larga duración, tareas de varios pasos y control de permisos. Todo eso es trabajo del harness.
Tercera: los LLM son intrínsecamente sin estado. Cada nueva session comienza desde cero y el modelo no recuerda la conversación anterior. El harness se encarga de persistir la memoria, el contexto y el progreso del trabajo, para que el agente pueda continuar trabajando como un auténtico «compañero».
Componentes centrales del Harness
Un harness de agente completo normalmente incluye las siguientes capas:
Componente Función Analogía Orchestration Loop Controla el ciclo «pensar → actuar → observar» del agente El bucle principal de un sistema operativo Tool Management Gestiona las herramientas que el agente puede usar (lectura y escritura de archivos, llamadas a API, operaciones del navegador, etc.) Controlador Context Engineering Decide qué información se envía al llamar al modelo cada vez y qué información se recorta Gestión de memoria State Persistence Guarda el progreso del trabajo, el historial de conversaciones y los resultados intermedios Disco duro Error Recovery Detecta fallos y reintenta o retrocede automáticamente Manejo de excepciones Safety Guardrails Limita el rango de acciones del agente para evitar operaciones peligrosas Cortafuegos Verification Loops Permite que el agente se autoverifique la calidad de la salida Pruebas unitarias
Tres capas de ingeniería: Prompt, Context y Harness
Las prácticas de ingeniería alrededor de los LLM se pueden dividir en tres capas concéntricas:
La capa más interna es Prompt Engineering: diseñar las instrucciones que se envían al modelo, determinando cómo «piensa» el modelo. Esta fue la habilidad dominante en 2023.
La capa intermedia es Context Engineering: gestionar lo que el modelo «ve». Determina qué información se introduce en el context window en qué momento y qué información se debe recortar. A medida que el context window se amplía hasta llegar a millones de tokens, la importancia de esta capa empezó a hacerse evidente en 2025.
La capa más externa es Harness Engineering: abarca las dos anteriores, además de toda la infraestructura base de la aplicación: orquestación de herramientas, persistencia de estado, recuperación de errores, ciclos de verificación, mecanismos de seguridad y gestión del ciclo de vida. Este es el campo de batalla central en 2026.
Ejemplo: por qué el mismo modelo se desempeña de forma radicalmente distinta en diferentes productos
Claude Opus 4.6 puede tardar una hora en reestructurar todo el repositorio de código dentro de Claude Code. Pero si se conecta el mismo modelo vía API a un harness rudimentario, es posible que no pueda ni siquiera arreglar bugs que abarcan múltiples archivos. La diferencia no está en el modelo; está en el harness.
¿Qué hizo el harness de Claude Code?
Busca automáticamente en todo el repositorio de código los archivos relevantes, en lugar de pedir al usuario que los especifique uno por uno
Lee el contenido de los archivos antes de modificarlos, y después ejecuta pruebas para verificarlas
Si las pruebas fallan, analiza el error de forma automática y vuelve a intentarlo
Conecta herramientas externas (GitHub, bases de datos, etc.) mediante MCP
El sistema de memoria guarda preferencias del usuario y el contexto del proyecto a través de sesiones
La estrategia Advisor hace que modelos con distintas capacidades colaboren por turnos
Todo eso es mérito del harness.
Feedforward y Feedback: dos modos de control del Harness
Según el análisis del blog técnico de Martin Fowler, los mecanismos de control del harness se dividen en dos categorías:
Feedforward (control anticipado): antes de que el agente ejecute acciones, se establecen reglas para prevenir salidas no deseadas. Por ejemplo: criterios de comportamiento en el system prompt, lista blanca de herramientas, permisos de acceso a archivos.
Feedback (control con retroalimentación): después de que el agente ejecute acciones, se revisa el resultado y se permite la auto-corrección. Por ejemplo: ejecutar pruebas para confirmar que el código es correcto, comparar la salida con el formato esperado, detectar alucinaciones y regenerar.
Un buen harness usa ambos tipos de control: limita el rango de comportamiento y a la vez conserva flexibilidad.
Productización de Harness Engineering: cómo lo hace Anthropic
Las actualizaciones de producto que Anthropic lanzó con intensidad en abril de 2026 son casi todas la productización de harness engineering:
Managed Agents: convierte en servicio administrado la infraestructura del harness (sandbox, planificación, gestión de estado), y el desarrollador solo necesita definir el comportamiento del agente
Estrategia Advisor: arquitectura de mezcla de modelos a nivel de harness que determina automáticamente cuándo consultar un modelo más potente
Edición empresarial de Cowork: ofrece un harness completo (control de permisos, gestión de gastos, análisis de uso) para usuarios no técnicos, para que no necesiten entender la tecnología subyacente
La formulación del responsable de producto de Anthropic trq212 es la más precisa: «Prompting es la habilidad de conversar con el agente, pero está mediado por el harness. Mi objetivo central es aumentar el ancho de banda entre los humanos y el agente».
Significado para los desarrolladores: una profesión y nuevas habilidades
Harness Engineering se está convirtiendo en un ámbito de ingeniería independiente. El conjunto de habilidades que requiere es distinto al de la ingeniería backend tradicional o la ingeniería de ML:
Entender los límites de capacidades de los LLM y sus patrones de fallo
Diseñar flujos confiables de llamadas a herramientas y manejo de errores
Gestionar el context window: cuándo introducir qué información
Construir observabilidad: rastrear las rutas de decisión del agente y el uso de herramientas
Diseño de seguridad: limitar el rango de comportamiento del agente sin ahogar su capacidad
Para quienes están aprendiendo Vibe Coding o usan herramientas de IA para desarrollar, entender el concepto de harness te ayudará a colaborar con agentes de IA de forma más efectiva: porque sabrás si el problema está en el modelo o en el harness, y cómo mejorar los resultados ajustando la configuración del harness (en lugar de modificar prompts una y otra vez).
Conclusión: la lucha por la infraestructura de la próxima década
La competencia de los modelos de IA no se detendrá, pero el rendimiento marginal está disminuyendo. La competencia en la capa de harness apenas comienza: quien pueda construir el harness más confiable, flexible y seguro, podrá convertir la misma capacidad del modelo en una mejor experiencia de producto.
Esto también explica por qué Anthropic, OpenAI y Google se están transformando de «empresas de modelos» a «empresas de plataforma»: lo que venden ya no es solo un API de modelos, sino la infraestructura completa de harness. Para los desarrolladores, entender harness engineering no es una opción: es una competencia fundamental para construir productos en la era de la IA.
Este artículo ¿Qué es Harness Engineering? El próximo campo de batalla de la IA no es el modelo, sino la capa de arquitectura fuera del modelo apareció por primera vez en Cadena de noticias ABMedia.
