Harness engineering: por qué el modelo ya no basta

Durante los últimos tres años, la industria del software ha vivido obsesionada con el cerebro. Cada nueva versión de un modelo de lenguaje se trató como un acontecimiento histórico: se debatían las tablas de benchmarks, el tamaño de la ventana de contexto, el número de parámetros. La suposición implícita, casi nunca formulada en voz alta, era que si construíamos un modelo lo bastante inteligente, resolvería por sí solo nuestros problemas de negocio más complejos.

Esa suposición se ha revelado incompleta. A medida que los agentes de IA salen de los laboratorios y entran en producción —en fintech, en salud, en infraestructura crítica— chocamos contra un muro estructural que ninguna mejora del modelo, por sí sola, parece derribar. Un cerebro brillante es inútil si no tiene manos para manipular el mundo digital, ni límites que acoten sus acciones, ni memoria de la que aprender cuando falla. De esa constatación ha nacido una disciplina de ingeniería que en 2026 se ha vuelto central: el harness engineering.

Este artículo es una introducción a ese cambio de paradigma. No es un tutorial —esos vendrán después— sino un mapa conceptual de por qué la conversación sobre desarrollo con IA se ha desplazado del modelo hacia todo lo que lo rodea, y por qué ese desplazamiento importa para cualquier developer que trabaje con estas herramientas.

La nueva ecuación: agente = modelo + harness#

La forma más limpia de entender el cambio es una ecuación sencilla que ha empezado a circular entre quienes construyen sistemas agénticos en producción: un agente no es un modelo. Un agente es un modelo más un harness.

El término harness —arnés, en su traducción literal— describe el envoltorio de software que convierte las llamadas a un modelo en ejecución de tareas acotada, con estado y mediada por herramientas. No es “cualquier código alrededor de un LLM”. Es la infraestructura específica que hace que el comportamiento de un agente a lo largo del tiempo sea controlable, inspeccionable y recuperable. Incluye el sustrato de ejecución, las interfaces de las herramientas, el control del contexto, la orquestación, la observabilidad, la evaluación continua y las restricciones de gobernanza.

La idea de fondo es contraintuitiva para quien viene de la era del prompt: el harness engineering trata al modelo como una utilidad congelada. Como una calculadora de razonamiento que no cambias. La responsabilidad de garantizar la seguridad, la precisión en la ejecución, la orquestación de múltiples pasos y la memoria adaptativa se le retira al modelo y se le entrega a la infraestructura que lo envuelve. En lugar de intentar hacer el modelo más listo, se construye un ecosistema estructural alrededor de él que hace que los fallos sean, por diseño, imposibles de repetir.

Cómo llegamos hasta aquí: tres eras#

El desplazamiento hacia el harness no ocurrió de golpe. Es la tercera fase de una evolución que puede contarse en tres eras, cada una definida por cuál era la restricción que de verdad limitaba el rendimiento.

Prompt engineering (2023-2024). La primera era asumió que la clave estaba en cómo le hablabas al modelo. La habilidad valiosa era formular la instrucción perfecta: el prompt que desbloqueaba la respuesta correcta. Funcionó mientras las tareas eran de un solo turno y autocontenidas. Pero a medida que los problemas se volvían más complejos, quedó claro que ajustar la redacción de la instrucción tenía un techo bajo. El modelo no fallaba por cómo le preguntabas; fallaba por lo que no sabía en el momento de responder.

Context engineering (2025). La segunda era desplazó el foco del input a la información. Si el modelo fallaba por falta de contexto, la solución era darle el contexto adecuado en cada momento: recuperación de datos relevantes, gestión de memoria, ranking de resultados de herramientas por relevancia. La pregunta dejó de ser “¿cuál es el input?” y pasó a ser “¿qué información debería ver el modelo en cada paso?”. Esta era trajo los pipelines de RAG y la gestión activa de la ventana de contexto. Pero también trajo su propio problema: la ansiedad de contexto, la confusión del modelo cuando cantidades masivas de texto sin filtrar contaminaban la ventana.

Harness engineering (2026). La era actual llega cuando los modelos se vuelven lo bastante capaces como para abordar tareas de larga duración. En ese punto, la fiabilidad deja de depender del modelo y pasa a depender de la infraestructura que mantiene el estado, media el acceso a las herramientas, inyecta feedback, impone restricciones y verifica el progreso. El rendimiento de un agente en tareas de horizonte largo no lo produce el modelo: lo produce el sistema acoplado de modelo y harness trabajando juntos.

La lógica que conecta las tres eras es la misma: en cada fase, la restricción que limitaba el rendimiento se movió. Primero era la instrucción, luego la información, ahora la infraestructura. Quien optimiza la restricción de la era anterior está resolviendo un problema que ya dejó de ser el cuello de botella.

Por qué el harness es ahora la ventaja competitiva#

Hay un dato revelador en el informe de tendencias de programación agéntica que Anthropic publicó en 2026: la configuración de la infraestructura, por sí sola, puede mover los resultados de un benchmark en más de cinco puntos porcentuales. Dicho de otro modo: dos equipos usando exactamente el mismo modelo, con harnesses distintos, obtienen resultados materialmente diferentes.

Esto cambia dónde está el apalancamiento. Cuando el modelo era el factor diferencial, la ventaja competitiva consistía en tener acceso al mejor modelo. Pero cuando los modelos punteros se han commoditizado —cuando varios proveedores ofrecen capacidades comparables y accesibles vía API— el diferencial se traslada a lo que construyes alrededor. El harness es donde un equipo puede ser genuinamente mejor que otro.

El caso más documentado de 2026 lo ofrece Microsoft con su agente de SRE para Azure. Es un agente que ha gestionado de forma autónoma más de 35.000 incidentes en producción, reduciendo el tiempo de mitigación en Azure App Service de 40,5 horas a 3 minutos. Lo interesante no es el modelo que usa, sino cómo está construido su harness. El equipo descubrió que exponer todo —código fuente, runbooks, esquemas de consultas, notas de investigaciones pasadas— como archivos, y dejar que el agente usara operaciones básicas como leer archivos, hacer grep y buscar, superaba a un sistema de herramientas especializadas. La métrica de “intención cumplida” en incidentes nuevos subió del 45% al 75%. No cambiaron de modelo. Cambiaron el harness.

Las piezas de un harness#

Entender qué compone un harness ayuda a ver por qué es una disciplina de ingeniería y no un detalle de implementación. Aunque cada sistema es distinto, los componentes recurrentes son razonablemente estables.

El gestor de instrucciones decide qué instrucciones del sistema recibe el modelo y cómo se combinan con el estado actual de la tarea. El constructor de contexto determina qué información se inyecta en cada turno: no todo lo disponible, sino lo relevante para el paso concreto. El adaptador de modelo abstrae el proveedor, de modo que el harness no dependa de un LLM específico. El registro de herramientas cataloga qué acciones puede solicitar el agente. El resolutor de permisos decide si una acción solicitada está autorizada antes de ejecutarla. El rastreador de presupuesto controla cuántos tokens, cuántas llamadas y cuánto tiempo puede consumir una tarea antes de detenerse. Dos de estas piezas dan para artículo propio: el constructor de contexto es el objeto de el paso del prompt al context engineering, y el rastreador de presupuesto, de qué pagas de verdad en tokens cuando el sistema llega a producción.

Hay un principio de diseño que atraviesa todos estos componentes y que conviene interiorizar: el modelo nunca ejecuta herramientas directamente. El modelo devuelve una solicitud estructurada de llamada a una herramienta; el harness valida el esquema, comprueba los permisos, ejecuta la acción y le devuelve el resultado al modelo. Esta separación es lo que hace que el sistema sea auditable y seguro. El modelo propone; el harness dispone. Ese ciclo de propuesta, validación y ejecución tiene su propia estructura, que desmontamos pieza por pieza en la anatomía del ciclo planificar-ejecutar-verificar.

Qué significa esto para un developer#

Es tentador leer todo esto como algo que solo concierne a quienes construyen plataformas de agentes a gran escala. Sería un error. El cambio de paradigma tiene implicaciones prácticas para cualquier developer que use herramientas de IA, incluso las de consumo.

La primera implicación es de criterio. Cuando entiendes que un agente es modelo más harness, dejas de atribuir todos los fallos al modelo. Si tu asistente de código hace algo raro, la pregunta útil no es siempre “¿es tonto el modelo?”, sino a menudo “¿qué le está mostrando el harness en este momento y qué le está permitiendo hacer?”. Muchos comportamientos frustrantes se explican por el andamiaje, no por el cerebro. Es un buen prisma para leer las diferencias entre Claude Code, Cursor y Copilot: buena parte de lo que las distingue no es el modelo, sino lo que cada una construye a su alrededor.

La segunda implicación es de habilidad. Si la era del prompt engineering premiaba saber redactar instrucciones, la era del harness premia entender arquitectura: cómo se gestiona el estado, cómo se acotan las acciones, cómo se verifica el progreso, cómo se controlan los costes. Son habilidades de ingeniería de sistemas, no de redacción. Para un developer que quiera mantenerse relevante en este campo, ahí está el terreno que merece la pena aprender.

La tercera implicación es de oportunidad. Herramientas como los servidores MCP —qué es el Model Context Protocol y por qué se impuso, y cómo construir tu primer servidor MCP— permiten que developers individuales construyan piezas de harness reutilizables sin montar infraestructura masiva. El acceso a este tipo de construcción se ha democratizado precisamente en 2026.

Lo que viene#

Este artículo es la puerta de entrada a una serie sobre desarrollo con IA que trata estos temas con la profundidad que merecen. En las próximas piezas veremos cómo la disciplina del contexto evolucionó del prompt al context engineering, qué es exactamente el Model Context Protocol y por qué se ha convertido en el estándar de facto, cómo se diseña el bucle de un agente con sus presupuestos y condiciones de parada, cómo se gestiona la ventana de contexto en tareas largas, cómo construir tu primer servidor MCP, y cómo controlar los costes de tokens sin arruinar el proyecto. Si ya estás construyendo agentes y lo que te aprieta es el contexto, empieza por gestionar la ventana de contexto en tareas largas.

La tesis que une toda la serie es la que abre este artículo: el futuro del desarrollo con IA no está en el modelo. Está en todo lo que construyes a su alrededor. El modelo es la parte que ya no controlas y que se parece cada vez más entre proveedores. El harness es la parte que sí controlas, donde reside tu criterio de ingeniería, y donde —cada vez más— se decide si un sistema con IA funciona de verdad o solo funciona en la demo.

Quien entienda esto antes tendrá ventaja. No porque sea un secreto, sino porque la mayoría sigue mirando el cerebro mientras la acción se ha mudado a las manos, los límites y la memoria.