Harness engineering: por qué la IA necesita arnés, no solo prompts

Durante los primeros años de adopción de la IA generativa, buena parte de la conversación profesional giró alrededor del prompt. Saber pedir se convirtió en una habilidad visible, casi en una artesanía. Pero cuando el trabajo deja de ser una consulta puntual y pasa a convertirse en investigación, análisis, desarrollo de producto, documentación, revisión de código, diseño de procesos o soporte a decisiones, el prompt empieza a quedarse corto.

Un prompt puede orientar una respuesta. Un arnés orienta un sistema de trabajo.

La diferencia no es menor. Cuando pedimos a un agente que “analice este informe”, “prepare una propuesta”, “revise este backlog” o “construya esta funcionalidad”, no solo necesitamos que genere texto. Necesitamos que sepa dónde están las fuentes, qué criterios debe respetar, qué no puede tocar, cómo debe verificar lo que produce, cuándo debe detenerse y qué evidencias debe dejar antes de declarar algo como terminado.

Birgitta Böckeler, de Thoughtworks, formuló en abril de 2026 una distinción que ayuda a ordenar este terreno: el arnés externo de un agente está compuesto por guías y sensores. Las guías actúan antes de que el agente produzca; los sensores actúan después, ayudando a detectar errores y corregirlos. Además, ambos pueden ser computacionales o inferenciales.

Esta forma de verlo desplaza la pregunta. La pregunta más madura es: ¿qué sistema de trabajo necesita la IA para producir algo revisable, trazable y útil?

Un agente no es un compañero de equipo

En agilidad conviene ser especialmente cuidadosos con el lenguaje. Llamar “compañero de equipo” a una IA puede resultar cómodo en una conversación informal, pero introduce una confusión peligrosa. Un agente puede ejecutar tareas, consultar materiales, generar alternativas, detectar inconsistencias y acelerar trabajo. Pero no asume responsabilidad profesional, no comprende el contexto político de una organización como lo hace una persona, no tiene compromiso con el producto ni responde ante las consecuencias de una decisión.

Por eso, para un equipo ágil, la IA debería entenderse como una herramienta con capacidad de acción, no como un miembro más del equipo. Esta distinción protege algo esencial: la responsabilidad sigue siendo humana. El equipo decide qué problema merece atención, qué trade-offs acepta, qué riesgos comunica y qué calidad considera suficiente.

El harness engineering no contradice esta idea; la refuerza. Un buen arnés no busca “soltar” a la IA para que trabaje sin criterio humano. Busca concentrar el criterio humano donde más valor tiene: definir intención, límites, evidencias, estándares y puntos de control.

OpenAI lo resumió de forma muy directa en su experimento interno con Codex: “Humans steer. Agents execute.” En ese caso, el equipo afirmó haber construido una beta interna con cero líneas de código escritas manualmente, aproximadamente en una décima parte del tiempo estimado, pero el aprendizaje importante no fue “la IA lo hizo todo”. Fue que los humanos pasaron a diseñar entornos, especificar intención y construir bucles de feedback.

Guías: lo que el agente necesita saber antes de actuar

Una guía es cualquier elemento que orienta el comportamiento antes de que el agente produzca. En software puede ser un archivo AGENTS.md, una guía de arquitectura, una convención de testing o una plantilla de pull request. En trabajo del conocimiento puede ser un brief, una guía editorial, un glosario, una taxonomía, una lista de fuentes aceptables o un protocolo de investigación.

La clave es que una guía no debería ser decoración documental. Debe ser operativa.

No es lo mismo escribir: “Este artículo debe ser riguroso”, que escribir: “Toda cifra debe ir acompañada de fuente, año y alcance; si no hay fuente verificable, reformula sin cifra o marca el dato como pendiente de verificación”. La primera frase expresa una aspiración. La segunda cambia el comportamiento del agente.

En un equipo ágil, las guías pueden tomar formas muy concretas. Un Product Owner que usa IA para preparar hipótesis de discovery puede darle al agente una plantilla que obligue a separar evidencia, supuesto e interpretación. Un Scrum Master que analiza retrospectivas puede usar un glosario de disfunciones organizacionales para evitar diagnósticos vagos. Un equipo que trabaja con documentación viva puede fijar reglas sobre qué fuentes tienen prioridad y qué términos no deben usarse de forma ambigua.

Aquí aparece una idea fundamental: lo que no está codificado en el entorno, no existe para el agente. Si una decisión se tomó en una reunión, pero no quedó registrada, la IA no la puede respetar de forma fiable. Si el equipo tiene una convención tácita, pero nunca se documentó, el agente la violará tarde o temprano. No por mala intención, sino porque trabaja con señales disponibles.

Sensores: lo que detecta errores después de actuar

Los sensores son el otro lado del arnés. Observan lo producido y generan señales para corregir. En software estamos acostumbrados a ellos: tests, linters, análisis estático, pipelines de integración continua. En gestión, producto o investigación solemos tener sensores más débiles: revisión humana, lectura crítica, listas de comprobación, contraste con fuentes o validación con stakeholders.

El reto actual consiste en convertir parte de esa revisión en sensores más explícitos y accionables.

Un sensor pobre dice: “El documento no está suficientemente fundamentado”. Un sensor útil dice: “La sección 3 contiene tres afirmaciones cuantitativas; dos tienen fuente y una no. La afirmación sin fuente es esta. Corrige localizando una fuente verificable o reformulando sin dato numérico”.

Böckeler insiste en que los sensores son especialmente potentes cuando producen señales optimizadas para que el propio agente pueda autocorregirse. También advierte que los controles computacionales suelen ser preferibles cuando son posibles: son más rápidos, más baratos y más fiables dentro de su alcance que los controles inferenciales basados en otro modelo.

Esto no significa que los revisores inferenciales no tengan valor. Un segundo agente puede actuar como lector escéptico, crítico editorial, revisor de riesgos o evaluador de coherencia. Pero conviene no caer en una fe ingenua: un modelo revisando a otro modelo no convierte automáticamente el resultado en verdadero. Puede detectar problemas semánticos interesantes, pero sigue siendo probabilístico.

Para trabajos de Scrum Manager, por ejemplo, un sensor editorial podría comprobar si el texto distingue entre nivel individual, equipo y organización; si evita prometer soluciones mágicas; si separa hipótesis de evidencia; si las referencias son reales; y si el cierre invita al debate en lugar de cerrar el tema con una receta universal.

El verdadero cambio: iterar el arnés, no regañar al modelo

Cuando un agente falla, la reacción habitual es escribir algo como: “No inventes fuentes”, “te he dicho que seas más riguroso” o “hazlo mejor”. Es comprensible, pero poco eficaz. El modelo no aprende de nuestro enfado en el sentido fuerte del término. Lo que sí cambia su comportamiento es modificar el entorno en el que trabaja.

El steering loop que describe Böckeler propone precisamente eso: cuando un fallo se repite, el humano debe mejorar el arnés. Si falta contexto, se añade una guía. Si falta detección, se añade un sensor. Si el agente intenta hacer demasiado, se reduce el alcance. Si se pierde entre materiales, se mejora la estructura del entorno.

Este enfoque encaja muy bien con la mentalidad ágil, pero con una advertencia: no se trata de ritualizar la mejora, sino de hacerla efectiva. No basta con decir “inspeccionamos y adaptamos”. La pregunta es: ¿qué cambio concreto en el sistema evitará que este error se repita?

Pensemos en un caso sencillo. Un agente ayuda a preparar un artículo y cita estudios inexistentes. La mala solución es añadir al prompt: “No inventes estudios”. La buena solución es crear una regla de trabajo: toda referencia debe incluir autor, año, título y fuente verificable; antes de cerrar el artículo, se ejecuta una comprobación específica de referencias; cualquier fuente no verificada se elimina o se marca como pendiente. Eso ya no es un consejo. Es un control.

Tareas largas: el problema de la memoria y la continuidad

El harness engineering se vuelve especialmente relevante cuando el trabajo no cabe en una sola conversación. Anthropic publicó en noviembre de 2025 un análisis sobre agentes de larga duración donde señalaba un problema sencillo de entender: los agentes trabajan en sesiones discretas, y cada sesión nueva empieza sin memoria directa de lo ocurrido antes, salvo que el sistema le proporcione artefactos persistentes. Su propuesta combinaba un agente inicializador, que prepara el entorno y descompone el trabajo, con un agente de ejecución que avanza de forma incremental y deja evidencias para la siguiente sesión.

Esta idea es muy aplicable fuera del código. Un equipo que prepara una guía didáctica, una investigación de mercado, una serie de artículos o un rediseño de procesos no debería depender de que “la conversación lo recuerde todo”. Debería mantener archivos vivos: brief, decisiones, fuentes, glosario, estado de avance, pendientes, versiones y criterios de aceptación.

Anthropic amplió esta línea en marzo de 2026 con diseños de arnés para desarrollo de aplicaciones de larga duración, incluyendo descomposición en partes manejables, artefactos estructurados de traspaso y arquitecturas con agentes planificadores, generadores y evaluadores. También describió fallos frecuentes de implementaciones ingenuas: pérdida de coherencia al llenarse el contexto, cierres prematuros y necesidad de reinicios con traspaso estructurado.

La lección para agilistas es clara: si usamos IA para trabajo complejo, necesitamos tratar el entorno como un producto interno. Debe ser navegable, versionado y comprensible para una sesión nueva. Si una persona nueva no entendería el proyecto en pocos minutos, probablemente el agente tampoco.

Contexto, herramientas y estándares abiertos

El arnés no vive aislado. Depende de cómo el agente accede a contexto, herramientas y datos. Por eso se están consolidando estándares y convenciones alrededor del ecosistema agentic.

Anthropic presentó el Model Context Protocol en noviembre de 2024 como un estándar abierto para conectar asistentes de IA con sistemas donde viven los datos: repositorios, herramientas de negocio, bases de datos o entornos de desarrollo. Más tarde, en diciembre de 2025, la Linux Foundation anunció la Agentic AI Foundation, con MCP, goose y AGENTS.md como proyectos fundacionales; describió AGENTS.md como una convención simple para dar a los agentes instrucciones específicas del proyecto de forma predecible.

Para un equipo ágil, estos movimientos importan por una razón práctica: cuanto más estandarizado sea el modo en que los agentes reciben instrucciones, acceden a herramientas y respetan límites, más fácil será gobernar su uso. Y gobernar no significa burocratizar. Significa que el equipo sabe qué datos puede usar, qué acciones puede ejecutar, qué permisos tiene, qué evidencias deja y qué revisión humana exige cada tipo de tarea.

Aquí hay una tensión organizacional real. Muchas empresas están incorporando IA de forma fragmentada: cada persona usa su herramienta, sus prompts, sus documentos y sus atajos. Al principio parece velocidad. Con el tiempo puede convertirse en deuda operativa: outputs difíciles de auditar, fuentes dispersas, decisiones sin trazabilidad y dependencia de prácticas individuales que nadie más puede reproducir.

La brecha de verificación

Uno de los riesgos más incómodos de los agentes de IA es que pueden producir resultados muy persuasivos antes de ser correctos. El texto suena bien. El código parece ordenado. El análisis tiene estructura. La recomendación es razonable. Y, sin embargo, algo crítico puede estar mal.

Esta brecha entre apariencia y verificación no es nueva, pero la IA la amplifica. En un entorno profesional, “hecho” no debería significar “el agente lo ha entregado”. Debería significar “ha pasado los controles acordados”.

En investigación y análisis, esto implica verificar fuentes, separar datos de interpretación, declarar incertidumbre y exponer evidencia contradictoria. En producto, implica comprobar si la recomendación conecta con outcomes reales, no solo con outputs. En Scrum, implica no convertir prácticas en dogmas ni diagnósticos de equipo en juicios simplistas. En escalado y liderazgo, implica reconocer cuando un problema no está en la conducta individual, sino en incentivos, estructura, poder o cultura.

Böckeler identifica el behaviour harness como una frontera todavía abierta: verificar que el sistema realmente hace lo que debía hacer sigue siendo más difícil que verificar estructura, estilo o mantenibilidad. En software, no basta con que la suite de tests generada por la IA esté en verde, porque puede estar validando un malentendido. En trabajo del conocimiento ocurre algo parecido: un informe puede cumplir la plantilla y aun así no responder la pregunta importante.

Por eso el juicio humano no desaparece. Cambia de lugar. Revisar cada frase puede ser menos importante que definir bien las preguntas que el trabajo debe responder, los criterios mínimos de aceptación y las objeciones que debería resistir.

Cómo empezar sin sobrediseñar

No todos los equipos necesitan un sistema sofisticado de agentes, sensores, hooks y subagentes. De hecho, sobrediseñar el arnés puede ser otra forma de desperdicio. Para empezar, suele bastar con cinco piezas.

Primero, una guía maestra breve: qué estamos haciendo, para quién, con qué estándares y qué está prohibido. Segundo, una estructura de materiales: fuentes válidas, documentos base, glosario, plantillas y ejemplos buenos. Tercero, un registro de decisiones: qué se decidió, cuándo, por qué y con qué implicaciones. Cuarto, una lista de verificación antes de cerrar entregables. Quinto, una rutina de revisión humana que no sea ornamental.

A partir de ahí, el arnés debe crecer por dolor real, no por moda. Si el agente falla repetidamente en terminología, se crea un glosario y un sensor de términos. Si inventa referencias, se crea una verificación bibliográfica. Si se dispersa, se reduce el WIP y se trabaja tarea por tarea. Si rompe una convención, se convierte la convención en comprobación automática cuando sea posible.

Esta lógica es muy cercana a la mejora continua: no mejorar “en general”, sino cerrar bucles concretos.

Para quienes quieran practicar este enfoque de forma guiada, Scrum Manager ha incorporado en Skill Arena el tema Harness Engineering, centrado en entrenar competencias como distinguir inteligencia de agencia, diseñar guías y sensores, preparar entornos que superen el cold-start test, aplicar pass-state gating, medir la calidad del arnés y decidir cuándo no conviene usar un agente. La intención no es aprender “trucos de IA”, sino desarrollar criterio profesional para trabajar con agentes de forma más fiable y verificable.

Qué cambia para scrum masters, product owners y equipos

Para un scrum master, el harness engineering puede ayudar a diseñar espacios de análisis más rigurosos. Un agente puede revisar retrospectivas, detectar patrones de impedimentos o preparar preguntas de facilitación, pero necesita límites claros: no diagnosticar personas, no atribuir intención sin evidencia, no confundir síntomas con causas raíz y no proponer soluciones fuera del nivel de influencia del equipo.

Para un product owner, el arnés puede mejorar discovery y toma de decisiones. Puede obligar al agente a separar hipótesis, evidencia, impacto esperado, riesgo y coste de aprendizaje. También puede impedir que convierta deseos de stakeholders en “necesidades de usuario” sin validación.

Para un equipo de desarrollo, el arnés puede reducir fricción si convierte estándares tácitos en reglas visibles. Pero también puede generar falsa seguridad si todo se delega en la IA sin sensores adecuados. La velocidad sin verificación no es agilidad; es acumulación rápida de deuda.

Para líderes y centros de formación, el reto es distinto: no basta con enseñar herramientas. Hay que enseñar criterios de uso. ¿Cuándo conviene usar un agente? ¿Cuándo no? ¿Qué tareas requieren revisión humana obligatoria? ¿Qué datos no deben subirse? ¿Qué evidencias mínimas debe dejar un entregable asistido por IA?

Una disciplina emergente, no una respuesta cerrada

El state of the art de mayo de 2026 muestra una disciplina en formación. Hay conceptos sólidos —guías, sensores, contexto, verificaciones, artefactos persistentes, arneses externos—, pero todavía hay preguntas abiertas. Los propios diseños de arnés envejecen a medida que mejoran los modelos. Anthropic lo señaló al explicar que ciertos controles necesarios para un modelo podían volverse “peso muerto” cuando el modelo siguiente resolvía mejor ese comportamiento.

Esta es una buena vacuna contra el dogmatismo. El harness engineering no debería convertirse en otro framework cerrado. Es más útil entenderlo como una práctica de diseño: observar cómo falla el trabajo asistido por IA, convertir los aprendizajes en controles y revisar periódicamente si esos controles siguen teniendo sentido.

Para la comunidad ágil, el debate merece atención porque toca una pregunta de fondo: ¿cómo mantenemos responsabilidad, aprendizaje y calidad cuando parte de la ejecución la realizan sistemas probabilísticos?

No parece suficiente responder “con mejores prompts”. Tampoco parece sensato responder “dejando que la IA trabaje sola”. Entre ambos extremos aparece un espacio más maduro: diseñar arneses que hagan el trabajo más legible, verificable y gobernable.

Quizá la pregunta práctica para empezar no sea “¿qué agente deberíamos usar?”, sino esta: si mañana una sesión nueva tuviera que continuar nuestro trabajo sin conocernos, ¿qué tendría que leer, qué límites debería respetar y cómo sabría que lo que ha producido está realmente bien?

Si esta pregunta te interpela, puedes seguir profundizando desde tres caminos complementarios.

• En Skill Arena tienes disponible el nuevo tema Harness Engineering, pensado para entrenar y medir competencias prácticas sobre diseño de arneses.
• Y, si eres miembro del Club Agile, encontrarás en Recursos dos state of the art más especializados:
  • Harness engineering para trabajadores de conocimiento, orientado al uso profesional de herramientas como ChatGPT y Claude,
  • y Harness engineering para desarrolladores, centrado en agentes de codificación como Codex y Claude Code.

Como siempre, el debate no está cerrado. ¿Qué parte de vuestro arnés está más madura hoy: las guías, los sensores, la gobernanza o la revisión humana? ¿Y cuál sigue dependiendo demasiado de hábitos individuales difíciles de escalar?

Referencias

• Anthropic Engineering,
  • (2024). Introducing the Model Context Protocol.
  • (2025). Effective harnesses for long-running agents.
  • (2026). Harness design for long-running application development.
  • (2026). Scaling Managed Agents: Decoupling the brain from the hands.
  • (2026). Demystifying evals for AI agents.
• Böckeler, B. (2026). "Harness engineering for coding agent users". Martin Fowler.
• Hsieh, C. P. et al. (2024). "RULER: What’s the Real Context Size of Your Long-Context Language Models?" NVIDIA / arXiv.
• Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2023/2024). "Lost in the Middle: How Language Models Use Long Contexts". arXiv / TACL.
• Lopopolo, R. (2026). "Harness engineering: leveraging Codex in an agent-first world." OpenAI Engineering.
• Linux Foundation. (2025). Linux Foundation announces the formation of the Agentic AI Foundation.