Agent harness, o todo lo que no es el modelo

Durante tres años, la pregunta que ordenaba cualquier conversación sobre IA aplicada al trabajo fue siempre la misma: ¿qué modelo usas? Comparábamos modelos como se comparaban procesadores hace veinte años, con tablas, puntuaciones y una fe razonable en que el número más alto predecía el resultado. Se cambiaba de proveedor por dos puntos en un benchmark. Se abrían hilos enteros para discutir si una versión había empeorado en secreto. Todo el presupuesto y toda la atención apuntaban al mismo sitio.

Esa pregunta ha dejado de predecir gran cosa.

Desde febrero, el sector tiene una palabra para lo que sí la predice, y la ha adoptado con una velocidad que debería levantar sospechas: harness. En seis meses ha pasado de jerga interna de tres o cuatro equipos a título de informes de OpenAI, artículos de ingeniería de Anthropic, papers en arXiv, entrada propia en Wikipedia y requisito en ofertas de empleo. La sospecha está justificada, y volveremos sobre ella. Pero el desplazamiento que la palabra describe es real, es medible, y tiene consecuencias prácticas inmediatas para cualquiera que trabaje con agentes.

Un modelo, por sí solo, solo convierte texto en texto

Conviene empezar por lo aburrido, porque es donde está la idea. Un modelo de lenguaje hace exactamente una cosa: recibe texto y devuelve texto. No recuerda lo que ocurrió hace cinco minutos, no puede abrir un fichero, no puede ejecutar la batería de pruebas ni enterarse de que ha fallado, y no sabe cuándo parar. Cuando ves a un agente leer tu repositorio, lanzar los tests, mirar el error, corregir y volver a intentarlo, ninguna de esas acciones la ejecuta el modelo. Las ejecuta el software que lo rodea.

Ese software es el harness —literalmente, el arnés—: todo lo que no es el modelo. La fórmula que se ha impuesto este año es deliberadamente simple: agente = modelo + harness. Vivek Trivedy, de LangChain, la remató en marzo con una frase que desde entonces se ha citado hasta el agotamiento: si no eres el modelo, eres el harness.

Dentro de esa definición cabe una lista muy concreta. El bucle que llama al modelo una y otra vez. El catálogo de herramientas que puede invocar y el código que las ejecuta de verdad. El sandbox donde se ejecutan. El sistema de permisos que decide qué puede hacer sin preguntar. La gestión del contexto, incluida la compactación cuando la ventana se llena. La memoria entre sesiones. Los ficheros de instrucciones tipo AGENTS.md. Los tests, linters y hooks que verifican el resultado. Y la observabilidad que permite reconstruir, después, qué demonios pasó.

El corazón de todo eso cabe en seis líneas de pseudocódigo: montar el contexto, llamar al modelo, leer lo que pide, ejecutarlo, devolverle el resultado, repetir hasta que declare que ha terminado. Lo difícil nunca fue el bucle. Lo difícil es todo lo que hay que decidir dentro de él: qué entra en el contexto y qué se descarta, qué herramienta se expone y cuál se esconde, qué se ejecuta sin pedir permiso, qué cuenta como “terminado” y quién lo comprueba.

Cada palabra nueva ha ampliado el perímetro del trabajo

La genealogía del término explica bastante más que su definición.

Primero fue el prompt engineering: el trabajo consistía en encontrar la frase correcta. Después llegó el vibe coding —Karpathy, febrero de 2025—, que no era una técnica sino una renuncia declarada: aceptar el código sin leerlo y dejar que el modelo llevara el volante. En junio de 2025, Tobi Lütke propuso context engineering y Karpathy lo amplificó una semana después; lo que importaba ya no era la frase, sino qué había exactamente en la ventana de contexto en cada paso. Anthropic lo formalizó en septiembre como la disciplina de curar el conjunto óptimo de tokens durante la inferencia.

Y en febrero de 2026, Mitchell Hashimoto publicó el relato de su propia adopción de estas herramientas con una idea que el sector convirtió en consigna en cuestión de días: cada vez que el agente comete un error, cambia el entorno para que ese error no pueda repetirse. Seis días más tarde, OpenAI publicaba un informe titulado directamente “Harness engineering”. LangChain diseccionó el concepto en marzo. Thoughtworks lo convirtió en método en abril. Hugging Face tuvo que publicar un glosario en mayo porque ya nadie se ponía de acuerdo en dónde acababa un scaffold y empezaba un harness.

La trayectoria es coherente y dice algo incómodo. Una frase, una ventana, un entorno entero: el vocabulario se ha ido alejando del modelo. Cada término nuevo ha ampliado el perímetro de lo que se considera trabajo de ingeniería del lado de quien usa la herramienta, no de quien la vende.

Veintitrés puntos de diferencia sin tocar el modelo

Lo que separa esta palabra de las anteriores es que esta vez hay números.

Harness-Bench, publicado en mayo, es el intento más serio de aislar la variable: 106 tareas reales de programación, análisis de datos y trabajo documental, 5.194 trayectorias de ejecución, ocho modelos distintos y seis harnesses configurables. La diferencia entre el mejor y el peor, con las mismas tareas y el mismo modelo por detrás, fue de 23,8 puntos porcentuales. No es un caso aislado: el mismo Claude Opus 4.5 puntúa 45,9% en SWE-bench Pro bajo un scaffold estandarizado y 55,4% dentro de Claude Code. LangChain pasó del puesto 30 al 5 en Terminal-Bench 2.0 sin cambiar de modelo, solo reescribiendo el entorno. Eso es más de lo que suele mover un salto de generación.

El mecanismo no tiene misterio, y por eso es convincente. Casi todo lo que separa un intento fallido de uno bueno ocurre fuera del modelo. Si el agente puede ejecutar los tests, ve el error y corrige; si no puede, afirma que funciona y se queda tan tranquilo. Anthropic ha catalogado tres modos de fallo recurrentes que ilustran el punto: declarar victoria sin verificar, la ansiedad de contexto —el modelo se atropella según se llena la ventana— y el intento de resolverlo todo de una sola pasada. Ninguno de los tres se arregla con un modelo más listo. Los tres se mitigan con verificación externa, es decir, con harness.

El caso extremo lo publicó OpenAI en febrero: un equipo de tres personas, un repositorio vacío en agosto de 2025, cinco meses, un millón de líneas de código en producción y 1.500 pull requests fusionadas sin escribir código a mano. El detalle que casi nunca se cita del informe es el más útil: al principio no funcionaba. La productividad era baja por entorno mal montado, integración pobre con herramientas y mala recuperación ante errores. Solo subió a medida que fueron construyendo el arnés, pieza a pieza.

Conviene añadir el matiz que el propio Harness-Bench introduce, porque desinfla un poco el eslogan: los modelos más capaces muestran menos varianza entre harnesses. El entorno importa siempre, pero importa desproporcionadamente cuando el modelo es flojo. Un buen harness no es un sustituto del modelo. Es un amplificador, y también un colchón.

Sí, es platform engineering repintado

Ahora, la parte de marketing, que existe.

Stuart Miller lo escribió en mayo con poca paciencia: harness engineering es platform engineering pintado de otro color. Y la lista de antepasados que enumera es difícil de rebatir: middleware, SRE, diseño de control plane, arquitectura orientada a servicios, incluso el sistema de producción de Toyota. La palabra ni siquiera es nueva dentro del propio sector: test harness y eval harness llevan décadas y años respectivamente significando casi lo mismo. La única diferencia de fondo que Miller concede —y es la buena— es que aquí el componente central es estocástico: no devuelve lo mismo dos veces seguidas, y hay que diseñar un entorno que se recupere con elegancia cuando el componente se inventa una acción o declara terminado lo que no lo está. Es un problema distinto de grado, no de naturaleza.

Y aun así el nombre sirve, por una razón poco romántica: marca una frontera contractual. Decir “modelo” y “harness” en la misma frase es decir qué compras y qué construyes. Esa frontera es justo donde se juega el dinero ahora. Si el entorno explica más varianza que el modelo, el entorno es el producto: Claude Code, Codex y Cursor no venden pesos, venden arneses, y la suscripción se paga por el bucle, no por la inferencia. Del lado del cliente el razonamiento es el simétrico y también funciona: si tus reglas, tus validaciones y tus permisos viven en el harness, el modelo pasa a ser una pieza intercambiable. La misma palabra sirve de foso para unos y de seguro contra el lock-in para otros. Por eso la ha adoptado todo el mundo tan rápido.

El harness es también la mejor excusa del sector

Toda palabra que reparte responsabilidad se usa antes para eximir que para asumir.

“No es el modelo, es tu harness” es, desde marzo, la respuesta estándar a cualquier informe de degradación. Y a veces es cierta. Pero conviene ver la operación completa: el proveedor conserva el mérito de las capacidades —que son suyas, del modelo, y se anuncian como tales— y externaliza la culpa de los fallos hacia el entorno que montó el cliente. Es un reparto asimétrico muy conveniente, y no hay forma de auditarlo desde fuera.

Hay una segunda consecuencia, más técnica y peor. Si cambiar de arnés mueve veinte puntos, ninguna comparación entre modelos significa nada mientras no se declare el harness con el que se midió. Un paper de mayo lo plantea sin rodeos: las puntuaciones de agentes en tareas largas no son válidas para comparar modelos salvo que se fije un harness común para todos o se trate la elección de harness como variable controlada y se reporte su varianza. Prácticamente ningún anuncio comercial cumple ninguna de las dos condiciones. Seguimos leyendo tablas de modelos que en realidad son tablas de configuraciones.

Y hay un tercer efecto, que se paga en factura. Cada control que añades al arnés —tests, un segundo agente que revisa, verificación semántica de cada paso— consume tokens, y a menudo más que la tarea original. La fiabilidad de un agente se compra en consumo, precisamente en el momento en que la tarifa plana ha dejado de sostener a los agentes. No es casualidad que Gartner calcule que más del 40% de los proyectos agénticos se cancelarán antes de 2027: el coste de construir el arnés es la partida que nadie presupuestó, porque hasta hace seis meses ni siquiera tenía nombre.

Un harness se construye a base de errores repetidos

La parte práctica es más sencilla de lo que sugiere el vocabulario, y se puede empezar hoy con lo que ya tienes.

El principio de fondo es el de Hashimoto, y funciona como un trinquete: ninguna regla entra en el entorno sin un fallo real detrás. Cuando el agente se equivoque, no le regañes en el chat; cambia el entorno para que ese error concreto sea imposible o se detecte solo. Documenta a qué fallo responde cada regla. Así el arnés crece por evidencia y no por superstición, que es como acaban la mayoría de los ficheros de instrucciones.

Prefiere siempre verificación ejecutable a instrucciones escritas. Birgitta Böckeler propone una distinción muy útil para ordenar esto: los controles pueden ser guías, que se anticipan a la acción, o sensores, que la observan después; y pueden ser computacionales —linters, tipos, tests, hooks: deterministas, baratos, instantáneos— o inferenciales —otro agente revisando: caros, lentos y opinables—. La regla operativa es colocar lo computacional lo más a la izquierda posible, antes del commit, y reservar lo inferencial para después de integrar. Un test que falla enseña más que tres párrafos de AGENTS.md, y además no ocupa contexto.

Sobre ese fichero, el consejo más repetido y el menos seguido: manténlo corto. Addy Osmani recomienda menos de sesenta líneas y la comparación es exacta: es la checklist de un piloto, no una guía de estilo. Cada línea compite por atención con el problema real. Lo mismo aplica a las herramientas: diez bien delimitadas rinden más que cincuenta solapadas, y exponerlas todas de golpe al arrancar es una de las formas más fiables de degradar el contexto antes de empezar.

Por último, separa quien hace de quien juzga. Los agentes se aprueban a sí mismos con una generosidad notable, así que el paso de evaluación debe correrlo otra instancia, con otro contexto y otro criterio, o directamente una máquina. Y guarda las trayectorias: sin registro de lo que hizo el agente y por qué, no estás haciendo ingeniería del entorno, estás haciendo cábalas sobre él.

No compras un agente, compras la mitad de uno

Nada de esto exige elegir entre el entusiasmo y el desprecio por la palabra de moda. Es a la vez un rebrand de disciplinas que ya existían y el nombre más preciso que tenemos para algo que sí ha cambiado: dónde vive el trabajo que decide si esto funciona.

Lo que el término ha hecho visible no es una tecnología nueva, sino una división de trabajo. El producto que compras está deliberadamente incompleto, y la mitad que falta —la que contiene tus reglas, tus tests, tus permisos y tu contexto— la construyes tú, la pagas en tokens y la respondes tú cuando falla.

Durante tres años la pregunta fue qué modelo usabas. La pregunta útil, a partir de este año, es qué has construido a su alrededor.