El harness: por qué el sistema alrededor del modelo importa más que el modelo

Este artículo cierra la serie Del prompt al sistema. La primera parte trató sobre cómo una persona deja de escribir prompts y le da contexto a su herramienta. La segunda, sobre cómo un equipo convierte lo que alguien hace bien en instrucciones que todos reutilizan. Esta trata sobre lo que aparece cuando juntas las dos: el sistema que construyes alrededor del modelo, y por qué importa más que el modelo.

"Probamos la IA y no funcionó." La he oído en el comité de una empresa de servicios, en la junta de un colegio y en una fintech que había pagado un piloto caro. Cuando pregunto qué probaron, la respuesta es casi siempre el nombre de un modelo: ChatGPT, Claude, Gemini, Copilot. Cuando pregunto qué le dieron al modelo para trabajar, qué podía consultar, qué recordaba de la semana anterior y quién revisaba lo que entregaba, viene un silencio. Y ese silencio es el diagnóstico. Evaluaron el motor y se olvidaron del carro.

El ejemplo más claro que conozco lo tengo en mi propio escritorio. Claude en la ventana de chat y Claude Code en la terminal usan exactamente el mismo modelo. El primero responde preguntas. El segundo lee los archivos de un proyecto, ejecuta pruebas, ve que fallan, corrige, vuelve a probar y me entrega algo que funciona una hora después. Nadie diría que son la misma herramienta. Y el modelo es idéntico. Lo que cambia es todo lo que está alrededor: qué ve, qué puede tocar, qué recuerda y cómo comprueba que terminó. A eso, en la industria, se le llama harness. En español, andamiaje. Es la palabra que no aparece en ninguna presentación de proveedor y la que explica casi todos los pilotos que fracasaron.

Lo que de verdad probaste

Ethan Mollick, que lleva años explicando esto mejor que nadie, separa tres cosas que en las empresas se confunden en una sola: el modelo, la aplicación y el harness. El modelo es el motor: lo que entrenaron OpenAI, Anthropic o Google. La aplicación es la ventana por la que lo usas: el chat, el botón en el CRM, el asistente dentro del correo. Y el harness es lo que está entre los dos: el contexto que se carga antes de cada tarea, las herramientas a las que el modelo puede llegar, la memoria que conserva entre una sesión y la siguiente y las comprobaciones que decide si el trabajo quedó bien. Cuando una empresa dice que probó "la IA", casi siempre probó un modelo bueno con un harness vacío. Un chat abierto, sin contexto, sin acceso a nada, sin memoria y sin nadie definido para revisar. Y concluyó que el modelo no sirve.

Anthropic publicó a finales de 2025 un caso que vale la pena contar porque aísla la variable. Querían que un agente construyera una aplicación completa a lo largo de muchas sesiones de trabajo, y al principio fallaba: dejaba funciones a medias, declaraba terminado lo que no había probado y en cada sesión nueva arrancaba sin saber qué había hecho en la anterior. No cambiaron el modelo. Cambiaron el andamiaje: un agente inicial que prepara el entorno y deja la lista de tareas escrita, un archivo de progreso que cada sesión lee al empezar y actualiza al terminar, y una regla de que cada sesión cierra una sola tarea y la verifica antes de pasar a la siguiente. Con el mismo motor, el agente pasó de abandonar el trabajo a entregarlo. Esa es toda la tesis de este artículo en un párrafo.

Las cinco piezas del sistema

Si leíste las dos partes anteriores, ya construiste la mitad sin llamarla así. Un harness completo tiene cinco piezas, y las dos primeras son exactamente lo que hicimos en esos artículos.

1. Contexto. Lo que el modelo sabe antes de empezar: quién es la empresa, cómo trabaja, con qué material y qué pasó antes. Es la carpeta de contexto de la primera parte, en su versión personal, y el contexto compartido de la segunda, en su versión de equipo. Un harness con esta pieza sola ya cambia la calidad de las respuestas más que cualquier cambio de modelo.

2. Procedimientos. Cómo hace el modelo las tareas que se repiten: las skills de la segunda parte, con sus pasos, su formato de salida, sus ejemplos y su lista de verificación. Es la diferencia entre un asistente que cada vez improvisa y uno que ejecuta la receta de la persona que mejor lo hace.

3. Herramientas. Qué puede tocar el modelo fuera de la conversación: consultar el CRM, leer el estado de un pedido, buscar en la base de conocimiento, crear un borrador en el correo. Hasta hace poco cada conexión era un proyecto; hoy hay un estándar para eso y conectar una herramienta cuesta horas, no meses. Aquí vive la decisión más delicada del sistema: qué permisos tiene cada herramienta. La regla que aplicamos en Saphia Labs no cambia nunca: todo empieza en solo lectura, y el permiso de escribir se gana con meses de uso, no se regala el primer día.

4. Memoria y estado. Qué sabe el modelo de lo que hizo ayer y de lo que falta. Un chat olvida todo al cerrarse. Un harness guarda, en un lugar que el modelo lee al empezar, qué se decidió, qué quedó pendiente y en qué va cada cosa. Es el archivo de progreso del caso de Anthropic y es la memoria del asistente que hay que curar para que no siga mencionando el proyecto cancelado en marzo. Sin esta pieza no hay trabajo largo posible: cada sesión arranca de cero y repite los errores de la anterior.

5. Verificación. Cómo sabe el sistema, y cómo sabes tú, que el trabajo quedó bien. Es la lista de verificación al final de cada skill, las pruebas que el agente corre antes de declarar terminado, un conjunto de veinte casos reales con los que comparas el resultado antes y después de cada cambio, y una persona con nombre en el punto donde el error cuesta dinero. El límite de la IA en una empresa es cuánto cuesta verificarla, y esta pieza existe para bajar ese costo de forma sistemática, no con buena voluntad.

Las cinco piezas se construyen en ese orden, y cada una vale poco sin la anterior. Herramientas sin contexto son un modelo que consulta el CRM sin saber qué buscar. Memoria sin verificación es un sistema que recuerda con confianza sus propios errores. La mayoría de los pilotos que "no funcionaron" tenían una pieza, o ninguna.

Por qué importa más que el modelo

Sé que suena a exageración. Los modelos son lo que sale en las noticias, lo que se compara en tablas y lo que los proveedores venden. Pero hay tres razones concretas por las que, para una empresa, el harness pesa más.

El modelo cambia cada pocos meses; el harness se acumula. El modelo que elegiste en enero ya tiene un reemplazo mejor y más barato. Cambiarlo, cuando el harness está bien hecho, es cambiar una línea de configuración. El contexto, las skills, las conexiones, la memoria y las pruebas se quedan y pasan al modelo siguiente intactos. Es la única inversión en IA que no se deprecia con el próximo lanzamiento. Todo lo que invertiste en aprender los trucos de un modelo específico, sí.

Las fallas viven en el harness, no en el modelo. Haz el ejercicio con cualquier historia de IA que haya salido mal en tu empresa. La propuesta con la lista de precios vieja: contexto vencido. El asistente que mandó un correo que no debía: herramienta con permisos de más. El agente que volvió a proponer lo que se descartó en marzo: sin memoria. El informe con una cifra inventada que nadie vio hasta la junta: sin verificación. He revisado decenas de estos casos y no recuerdo uno que se hubiera resuelto cambiando de modelo. Todos se resolvían arreglando una pieza del sistema.

Es la única parte que controlas. No vas a entrenar un modelo. Ninguna empresa mediana de la región lo va a hacer, y no tiene por qué. Lo que sí decides, y nadie decide por ti, es qué ve el modelo antes de empezar, qué puede tocar, qué recuerda y quién revisa. Esa es la parte donde tu empresa puede ser distinta a la competencia que usa exactamente el mismo modelo. Y lo usa: el modelo ya no es ventaja de nadie.

Cinco preguntas para evaluar un sistema

Esto sirve igual para evaluar lo que te vende un proveedor y para revisar lo que armó tu propio equipo. Son las preguntas que hago en cada diagnóstico, y en cada una hay una respuesta que delata un harness vacío.

¿Qué sabe antes de empezar? Pide ver el contexto que se carga. Si la respuesta es "el usuario le explica lo que necesita", no hay contexto: cada persona vuelve a contratar un consultor nuevo cada mañana.

¿Qué puede tocar y con qué permisos? Pide la lista de herramientas conectadas y, para cada una, si lee o escribe. Si nadie sabe la respuesta exacta, los permisos son los que vinieron por defecto, y los que vienen por defecto casi siempre son demasiados.

¿Qué recuerda entre una sesión y la siguiente? Pide que te muestren dónde queda escrito lo que se decidió y lo que falta. Si vive en el historial del chat, no es memoria: es un registro que nadie vuelve a leer.

¿Cómo sabes que hizo bien el trabajo? Pide los casos de prueba. Si no hay un conjunto de casos reales con el resultado esperado, nadie puede decirte si la versión de este mes es mejor o peor que la del anterior. Están adivinando, con confianza.

¿Qué pasa cuando falla? Y va a fallar. Pide que te cuenten el último error y cómo se enteraron. Si se enteraron por el cliente, no hay verificación. Si no se acuerdan de ninguno, es peor: significa que no están mirando.

Si estás evaluando un proveedor, estas cinco preguntas valen más que cualquier demo, porque la demo corre sobre un harness afinado para la demo. Lo que tienes que entender es qué pasa cuando ese sistema se conecta a tus datos, con tus reglas y tus casos raros. Y si estás revisando el piloto que "no funcionó", vuelve a él con estas preguntas antes de cerrar el tema. Lo normal es que falle en dos. Arregla esas dos y vuelve a correrlo con el mismo modelo. La conclusión suele cambiar.

Los errores que se repiten

Cambiar de modelo como primer reflejo. Es la reacción más común y la menos útil. Cuando algo no funciona, el equipo prueba con otro proveedor, obtiene un resultado parecido y concluye que "la IA no está lista". Lo que no estaba listo era el sistema, y se lo llevaron intacto al modelo nuevo.

Comprar la demo. El harness del proveedor está construido alrededor de un proceso genérico. El tuyo tiene excepciones, nombres propios y reglas que nadie escribió. Adaptar ese andamiaje a tu proceso es trabajo real y hay que presupuestarlo. Si el proveedor dice que no hace falta, pregunta cómo maneja tu caso raro favorito. Tienes uno. Todos tienen uno.

Dar permisos de escritura el primer día. Un asistente que lee todo y no escribe nada ya resuelve la mayor parte del valor y casi ningún riesgo. Uno que puede enviar, borrar o modificar desde el primer día puede causar daño real antes de que nadie entienda cómo trabaja. Los permisos se amplían cuando el sistema lleva meses demostrando que acierta, no antes.

Construir sin medir. Un harness sin casos de prueba mejora o empeora en cada cambio y nadie lo sabe. Veinte casos reales, con lo que debería salir en cada uno, es la inversión más barata del sistema y la que más se omite. Es también la única forma de responder si la IA está funcionando con algo distinto a una impresión.

Dejarlo sin dueño. La misma regla de la segunda parte, ahora para el sistema completo. Un harness sin alguien que lo cuide se degrada en tres meses: el contexto vence, las conexiones cambian, los casos de prueba dejan de representar el trabajo real. Un nombre, una revisión al mes, quince minutos.

Conclusión

La serie empezó con una persona que deja de coleccionar prompts y le da contexto a su herramienta. Siguió con un equipo que escribe lo que alguien hace bien para que todos lo reutilicen. Y termina aquí, con una idea que a mí me tomó tiempo aceptar: la calidad de lo que entrega tu empresa con IA ya casi no depende del modelo. Depende del sistema que construiste alrededor. El modelo es lo que compras. El sistema es lo que te diferencia.

Esta semana, toma el proyecto de IA que en tu empresa "no funcionó" y hazle las cinco preguntas. Escribe las respuestas. Si falla en dos, que es lo normal, arregla esas dos y vuelve a probarlo con el mismo modelo de antes. Si después de eso sigue sin funcionar, escríbeme: será el primer caso que veo.

Y si te interesa el detalle técnico de cómo se construye cada pieza, con los patrones que Anthropic y otros han publicado para agentes que trabajan horas sin supervisión, ese es el siguiente paso natural y será una guía completa en nuestro Hub IA. Este artículo es la versión para decidir. Esa será la versión para construir.