En el post anterior vimos que los prompts complejos han perdido buena parte de su razón de ser porque los sistemas actuales asumen trabajo que antes hacía el usuario. La pregunta que quedaba pendiente era: ¿qué parte del sistema hace ese trabajo? La respuesta es el harness. ## Qué es el harness  El modelo de IA -el núcleo que razona y genera texto- no funciona solo. Para que haga algo útil en una tarea real, necesita una capa alrededor que le diga qué herramientas puede usar, qué información tiene disponible, cómo ordenar los pasos, cuándo revisar un resultado y cuándo parar. Esa capa es el harness. El harness no es el modelo. Es la maquinaria que rodea al modelo y le da capacidad operativa. Sin harness, el modelo predice texto. Con un buen harness, el modelo ejecuta tareas. Un harness típico incluye varias piezas: acceso a herramientas externas (leer y escribir ficheros, ejecutar código, hacer búsquedas, conectarse a otros sistemas), un planificador que descompone la tarea en pasos, un bucle de razonamiento que revisa el plan según los resultados que va obteniendo, gestión de memoria a corto y largo plazo, y mecanismos para validar y reintentar cuando algo falla. La distinción es útil porque permite entender qué está mejorando realmente. Cuando la IA de hace seis meses no mantenía bien el hilo de una conversación larga, eso no era necesariamente un fallo del modelo: era, con frecuencia, un problema de gestión del contexto por parte del harness. ## La gestión del contexto como palanca principal El modelo trabaja con lo que tiene presente en cada momento: las instrucciones que recibe, los ficheros que ha leído, los resultados de los pasos anteriores, la memoria que el harness ha decidido cargar. Eso es el contexto. Y la ventana de contexto -la cantidad de información que el modelo puede tener activa a la vez- es limitada y costosa de usar. Un harness bien diseñado selecciona en cada paso qué información entra, qué se descarta, qué se resume para no ocupar espacio y qué se recupera de una memoria externa cuando hace falta. Esa selección es lo que el usuario percibe como "la IA mantiene el hilo" o "la IA recuerda bien lo que le dije antes". Cuando los resultados de la IA mejoran de forma notable en un periodo corto, la explicación está aquí más que en un salto cualitativo del modelo. El modelo base puede haber mejorado, pero la gestión del contexto -que es una propiedad del harness- suele ser la palanca más visible. Hay sistemas que van un paso más allá. En lugar de gestionar solo el contexto de una sesión, construyen una capa de conocimiento persistente sobre el usuario: su correo, sus ficheros, su calendario, sus conversaciones anteriores. El contexto no se reinferiere desde cero en cada petición; está disponible como una estructura estable que el harness mantiene actualizada. El efecto perceptible es que una petición sencilla produce resultados muy buenos, porque el sistema ya sabe quién eres y en qué estás trabajando. ## Qué es un agente, revisado Con el concepto de harness en mano, la definición de agente se vuelve más precisa y menos misteriosa. Un agente no es una entidad autónoma con objetivos propios, ni tampoco una pieza de infraestructura técnica compleja que requiere un equipo de ingenieros. Un agente es un modelo, un harness capaz y un propósito definido por texto. Eso es todo. El propósito puede expresarse en un fichero de texto que describe el rol, los criterios con los que debe actuar, las directivas de lenguaje y el formato de entrega esperado. La herramienta agéntica -el entorno con el harness- carga ese fichero como su comportamiento operativo. Cambiar el fichero cambia el agente. Esta formulación tiene consecuencias prácticas. Si el propósito de un agente es un fichero de texto, cualquier persona que sepa escribir instrucciones puede definir uno. No hace falta código, ni integración técnica, ni un equipo especializado. ## Por qué un buen harness sustituye la arquitectura multiagente en la mayoría de casos Hace un año, si querías construir un sistema donde varios "roles" colaborasen en una tarea compleja -por ejemplo, un sistema editorial donde un agente estructurara las fuentes, otro redactara, otro revisara y otro refinara el resultado- la arquitectura natural era la multiagente: varios agentes independientes, cada uno con su propio harness, comunicándose mediante protocolos de integración construidos a medida. El problema era que esa arquitectura trasladaba el trabajo al sistema en vez de eliminarlo. Cada agente exigía su propia integración técnica. Los protocolos de comunicación entre agentes se convertían en software que alguien tenía que mantener. Y la gestión del contexto entre agentes distintos era el punto de fallo más frecuente: cada agente conocía su parte, pero nadie tenía el cuadro completo. Lo que hace el harness moderno es asumir internamente el rol de orquestador. En lugar de varios agentes con harnesses independientes hablando entre sí, hay un único entorno con un harness capaz que carga perfiles distintos según la fase del trabajo. El usuario define un perfil por rol -cada uno en un fichero de texto-, y el entorno los va activando en el orden adecuado, con el contexto compartido disponible en todo momento. El resultado funcional es el mismo que el de la arquitectura multiagente clásica. La diferencia está en el coste: no hay código de integración, no hay protocolos a mantener, no hay gestión distribuida del contexto entre sistemas separados. Para que el ejemplo sea concreto: el sistema con el que se escribe este texto usa varios perfiles -uno que estructura el material de fuente, uno que redacta, uno que revisa con criterio crítico, uno que refina el estilo. No son cuatro aplicaciones distintas comunicándose. Son cuatro ficheros de texto que un único entorno ejecuta en secuencia, con el hilo del trabajo intacto de principio a fin. ## Cuándo sí hace falta la arquitectura multiagente Esto no significa que la arquitectura multiagente haya desaparecido. Hay casos donde sigue siendo la respuesta correcta. Cuando varias tareas deben ejecutarse en paralelo real, con agentes corriendo en máquinas distintas de forma simultánea, un solo harness no puede absorberlo. Cuando hay que integrarse con sistemas externos que imponen sus propios protocolos, la orquestación interna no es suficiente. Y cuando el volumen de trabajo o los requisitos de latencia superan lo que un único entorno puede procesar, la distribución sigue siendo necesaria. Pero para el trabajo personal, profesional individual o de equipos pequeños, esta capa de complejidad es innecesaria en casi todos los casos. El harness moderno cubre el terreno que hasta hace poco justificaba esa arquitectura. ## Qué queda en manos del usuario Si el harness asume la orquestación, la gestión del contexto y la ejecución multipaso, ¿qué hace el usuario? Principalmente dos cosas. Define los propósitos -los ficheros que describen cada perfil o agente- con la precisión suficiente para que el sistema produzca lo que necesita. Y valida los resultados. La validación es la tarea que no se puede delegar. El harness puede ejecutar cien pasos de forma autónoma, pero alguien tiene que revisar el resultado final con criterio, detectar lo que no está bien y decidir si publicar, usar o descartar. Esa capacidad -saber qué es un buen resultado y qué no lo es- es lo que determina si el sistema trabaja para ti o te produce trabajo. Los prompts no han muerto. Lo que ha cambiado es que el esfuerzo se concentra en definir bien los propósitos y en tener criterio para evaluar lo que el sistema devuelve. El prompt mínimo bien hecho sigue siendo necesario. Lo que ha dejado de ser necesario es el prompt elaborado como sustituto de lo que el sistema ya sabe hacer solo.