Diseño del harness para agentes de IA.

Durante el último año, construyendo sistemas agénticos en producción para clientes de fintech, legal y compliance, he visto repetirse el mismo fallo más veces de las que me gustaría admitir. La demo funciona. Staging funciona. El sistema se despliega. Y luego, en algún punto alrededor del minuto 40 de una tarea, el agente empieza a hacer algo que nadie esperaba: repite trabajo que ya había terminado, contradice decisiones que tomó hace una hora o produce outputs incorrectos con total confianza. Nada se ha caído. Ningún error en los logs. El modelo sigue ejecutándose. Simplemente ha descarrilado.

Cada vez que pasa, el instinto es culpar al modelo. Cambiar el prompt. Probar otra temperatura. Actualizar a la siguiente versión. A veces ayuda marginalmente. Pero en casi todos los casos que he diagnosticado, el problema real era el mismo: el harness no estaba diseñado.

El harness es todo lo que envuelve al modelo: la estructura que gestiona el contexto, coordina agentes, maneja fallos y mantiene el sistema coherente a lo largo del tiempo. En mi experiencia, los equipos pasan semanas en prompt engineering y casi nada en el diseño del harness. Ahí es donde falla la mayoría de los sistemas agénticos de larga duración, y donde se concentra buena parte del trabajo de ingeniería que de verdad importa.

El harness no es el modelo. Es el sistema que hace que el modelo sea útil en producción. Cubre cómo se gestiona el contexto a medida que las tareas se alargan, cómo se descompone el trabajo en pasos que el agente pueda ejecutar de forma fiable, cómo se detectan y gestionan los fallos, cómo se coordinan varios agentes, cómo se mueve el estado entre sesiones y cómo se evalúan los outputs antes de que cualquier otro componente actúe sobre ellos.

Quiero marcar una distinción importante en la práctica. El context engineering, decidir qué entra en la ventana de contexto en cada paso, es una pieza del diseño del harness, y ha recibido mucha atención últimamente. Pero el diseño del harness es más amplio. Puedes tener un context engineering excelente y, aun así, desplegar un sistema que colapse ante volúmenes de producción porque nadie diseñó la arquitectura de evaluación, o no se definió qué pasa cuando un paso falla dos veces seguidas, o nadie pensó en cómo sobrevive el estado a un reinicio. He heredado sistemas así. El contexto estaba muy bien gestionado; todo lo demás se sostenía sobre suposiciones que resultaron ser muros de carga.

La analogía que uso siempre: en software tradicional no desplegarías un servicio sin gestión de errores, lógica de reintentos y observabilidad. Nadie llama a eso funcionalidades, es infraestructura. El diseño del harness es exactamente lo mismo para los sistemas agénticos. La razón por la que los equipos se lo saltan es la misma por la que se descarta cualquier trabajo de infraestructura al principio de un proyecto: no importa hasta que importa, y cuando importa, ya estás en producción.

Después de unas cuantas retrospectivas, los modos de fallo empiezan a resultar familiares. Estos son los cuatro que he visto con más frecuencia.

La contaminación de contexto es de tipo gradual. A medida que el agente trabaja en una tarea larga, la ventana de contexto se llena de pasos anteriores, outputs de herramientas, decisiones intermedias y estado acumulado. El modelo trabaja con todo ello a la vez, y en algún momento el peso de ese historial empieza a degradar la coherencia. El agente no se cae, sino que empeora de forma progresiva. Las decisiones posteriores contradicen restricciones anteriores. El objetivo general se desvía. Los outputs parecen razonables de forma aislada, pero se desmoronan en conjunto. Es el tipo de fallo difícil de detectar en pruebas porque las tareas cortas no lo sacan a la luz.

La ansiedad de contexto está menos documentada, pero la he visto de forma consistente. Algunos modelos, al acercarse a lo que perciben como su límite de contexto, empiezan a cerrar el trabajo antes de tiempo. Producen un output final, a veces claramente incompleto, como si intentaran terminar antes de quedarse sin espacio. El sistema reporta que todo ha ido bien y el output parece una finalización correcta. Solo cuando un humano lo lee de verdad queda claro que se ha saltado la mitad del trabajo. En un sistema de compliance que construimos con Claude Sonnet 4.5, este comportamiento fue lo bastante marcado como para que los reinicios de contexto, no la compactación, sino reinicios completos con handoffs estructurados, pasaran a ser una parte central del harness. La compactación mantiene al mismo agente ejecutándose sobre un historial acortado. Eso aborda la contaminación de contexto, pero no limpia la pizarra, por lo que la ansiedad persistía. Solo un reinicio real lo resolvió.

El sesgo de autoevaluación es estructural, no específico de un modelo. Pide a un agente que evalúe la calidad de su propio output y casi siempre te dirá que es bueno, incluso cuando, para un revisor humano, sea obviamente mediocre. Es especialmente agudo en tareas subjetivas, pero también aparece en las verificables. En un sistema de monitorización de compliance que procesa llamadas de ventas, el evaluador, inicialmente el mismo agente que el procesador, aceptaba informes que cualquier revisor humano marcaría al instante. Lo que cambió las cosas no fue afinar el procesador. Fue separar la evaluación en un agente completamente distinto, con su propio contexto, sus propias instrucciones e incentivos explícitos para encontrar problemas. Ese agente seguía siendo un LLM con la misma tendencia general a ser generoso, pero afinar un evaluador escéptico independiente resultó mucho más abordable que conseguir que un generador fuera crítico con su propio trabajo.

La pérdida de estado entre sesiones es la cuarta, y a menudo la más cara cuando aparece. Muchos sistemas agénticos en producción no se ejecutan en una sola sesión continua. Pausan, pasan el testigo, recomienzan... porque son procesos largos, porque algo ha fallado o porque se ejecutan en paralelo en varias instancias. Si el artefacto de handoff no está bien diseñado, la siguiente sesión empieza sin una imagen completa de qué se ha hecho, qué decisiones se tomaron y qué restricciones aplican. En un sistema fintech que procesaba solicitudes de préstamo, vimos agentes duplicando trabajo ya completado y contradiciendo decisiones de sesiones anteriores; no porque el modelo estuviera confundido, sino porque el estado que recibía estaba incompleto. La solución no fue un modelo mejor, fue un mejor artefacto de handoff.

No son específicos de ningún framework. Son decisiones de arquitectura que aplican con cualquier conjunto de herramientas, y conviene tomarlas de forma explícita antes de construir, no después de haber topado con el modo de fallo en producción.

Los reinicios de contexto con handoffs estructurados abordan la contaminación, la ansiedad y la pérdida de estado a la vez. El planteamiento consiste en diseñar el sistema para reiniciar el contexto en intervalos definidos y pasar un estado estructurado a una nueva instancia del agente, en lugar de dejar que el contexto crezca indefinidamente o depender solo de la compactación. El artefacto de handoff es donde se concentra la mayor parte del trabajo de diseño. Debe contener qué se ha completado (con suficiente detalle para que el siguiente agente no lo repita), qué decisiones se tomaron y por qué (para que el siguiente no las contradiga), qué viene después (el paso concreto, no una descripción general) y el estado actual de los artefactos compartidos: ficheros, bases de datos, historial de git y todo lo que toque la tarea. El reinicio da al siguiente agente una ventana de contexto limpia. El artefacto de handoff le proporciona todo lo necesario para continuar con coherencia. Añade complejidad de orquestación y coste en tokens, que es real, pero en tareas donde la ansiedad de contexto es marcada, es la única intervención que de verdad funciona.

Separar generador y evaluador aborda el sesgo de autoevaluación. El principio es simple: nunca confíes en el mismo agente para evaluar la calidad de su propio output en nada que sea crítico. El evaluador necesita su propia ventana de contexto, una que no haya participado en la construcción del output. Necesita criterios claros y específicos; no un “¿esto está bien?”, sino un “¿cumple los criterios de aceptación definidos?”. Y necesita herramientas para verificar el output directamente: ejecutarlo, si es código; leerlos, si son documentos; o llamarlas, si son APIs. En el sistema de compliance que mencioné, el evaluador usaba Playwright para navegar por la aplicación en ejecución tal y como lo haría un usuario antes de puntuar cada criterio. Esa interacción con el sistema vivo, y no una revisión estática, fue lo que dio valor a las evaluaciones. Un evaluador escéptico con esas capacidades es mucho más efectivo que cualquier autocrítica del generador.

La descomposición en sprints con contratos predefinidos aborda la contaminación, el sesgo y la pérdida de estado a la vez. La idea es dividir tareas largas en unidades acotadas con un contrato definido para cada una: qué se construirá, cómo se verificará el éxito y cómo será el handoff al siguiente sprint. Lo crítico es que el contrato se negocia antes de empezar el trabajo, acordado entre generador y evaluador antes de escribir una sola línea de código. Eso elimina la fuente más común de trabajo desperdiciado: construir lo correcto de la forma incorrecta (o directamente lo incorrecto) y descubrirlo solo en la evaluación. También limita el radio de impacto de cualquier fallo. Si el sprint 4 produce un output mediocre, reinicias desde el handoff del sprint 3, no desde el principio.

La gestión explícita de fallos y rutas de escalado es la capa de infraestructura que le falta a la mayoría de los sistemas agénticos. Las preguntas que hay que responder antes de desplegar: ¿qué desencadena un reintento frente a un fallback o frente a un escalado humano? ¿Qué estado se preserva entre reintentos? Cuando un sprint falla en la evaluación, ¿el generador tiene otro intento o se escala tras el primer error? ¿Cómo es el human-in-the-loop en este sistema: revisión síncrona, notificación asíncrona o una alerta en un dashboard? Estas decisiones parecen prematuras mientras construyes, pero se vuelven urgentes a las 2 de la mañana cuando el sistema ejecuta una tarea crítica, pasa algo inesperado y no hay un camino definido.

La observabilidad como requisito de primer orden es lo que hace que el resto de los patrones sean depurables. Implica un logging estructurado que capture no solo errores, sino el razonamiento del agente en puntos de decisión clave, el contenido de los artefactos de handoff, las puntuaciones del evaluador a lo largo del tiempo y la tasa de fallos de sprint y reintentos. Sin ello, depurar un fallo de un agente de larga duración significa leer miles de líneas de output en bruto para reconstruir qué pasó. Con ello, puedes ver exactamente dónde empezó a degradarse la coherencia, si las puntuaciones del evaluador iban en la dirección equivocada antes del fallo y qué modos de fallo estás viendo en realidad. En el sistema de compliance, añadir esta capa fue lo que nos permitió rastrear el sesgo de autoevaluación hasta su origen: las puntuaciones del evaluador llevaban tres sprints derivando a positivo antes de que la calidad del output fuera visible para un revisor humano.

No todo sistema necesita un harness completo, y recomendarlo siempre sería el mismo error que saltárselo por completo.

Lo necesitas cuando el agente se ejecuta durante más de 10 o 15 minutos en una sola tarea, cuando la tarea implica más de cinco o seis pasos secuenciales, cuando varias instancias deben coordinarse o pasarse el estado, cuando el output va a producción sin revisión humana de cada detalle, o cuando el coste de un output incorrecto es significativo (compliance, finanzas, salud, legal).

Puedes aplazarlo en agentes de un solo turno o de sesión corta: Q&A, extracción o clasificación. También en herramientas internas con outputs de bajo riesgo donde la revisión humana ocurre de forma natural, o en fases tempranas de una PoC donde solo validas la viabilidad y no construyes para producción.

La prueba que uso siempre: si un humano haciendo la misma tarea necesitaría tomar notas para seguir su propio progreso, el agente necesita un harness. Si la tarea cabe en una sola sesión sin notas, un diseño más simple probablemente baste.

Algo que he aprendido a las malas: el diseño del harness es significativamente más difícil de añadir a posteriori que de diseñar desde el principio. Además, las estructuras de datos, los límites entre agentes y los puntos de evaluación que exige un buen harness suelen dar forma a todo el sistema. Construir sobre suposiciones que los ignoran hace que esas suposiciones se conviertan en muros de carga. Construye un harness mínimo desde el inicio. Es mucho más fácil ampliarlo que intentar acoplarlo a un sistema que no fue diseñado para ello.

El sistema de monitorización de compliance al que he hecho referencia a lo largo del post es el ejemplo más claro que tengo de lo que cambia el diseño del harness en producción. El sistema procesa llamadas de ventas de extremo a extremo, extrayendo datos estructurados de compliance, validando frente a requisitos regulatorios y marcando infracciones, con varias instancias de agente en paralelo y a gran volumen.

Antes de diseñar bien el harness, el sistema sufría los tres modos de fallo que describí. La contaminación de contexto por ejecuciones paralelas que se filtraban entre sí vía estado compartido producía informes inconsistentes para llamadas con contenido similar. El evaluador, el mismo agente que el procesador, aceptaba informes que cualquier revisor humano descartaría al instante. Y cuando el sistema reiniciaba tras un fallo, algunas llamadas se procesaban dos veces y otras se saltaban por completo, sin ruta de recuperación.

Los cambios del harness no fueron complicados. Aislamos el contexto por llamada, eliminando el estado compartido entre ejecuciones paralelas. Construimos un agente evaluador separado afinado a los criterios concretos de la revisión de compliance; no un evaluador genérico, sino uno calibrado a los estándares exactos del equipo. Y movimos el seguimiento del estado del job a un almacén externo, para que el harness supiera siempre qué llamadas se habían procesado, cuáles estaban en curso y cuáles necesitaban reintento.

El resultado: el sistema funciona ahora a pleno rendimiento en producción con una tasa de revisión humana por debajo del 8%. El otro 92% de los informes va directamente a la cola del equipo de compliance sin intervención manual. El modelo no cambió; la infraestructura a su alrededor, sí.

La mayoría de los sistemas agénticos no fallan porque el modelo no sea lo bastante capaz. Fallan porque la infraestructura alrededor del modelo no fue diseñada para mantenerlo coherente, evaluado y recuperable a lo largo del tiempo.

Los patrones no son complicados: reinicios de contexto, evaluación externa, descomposición en sprints, gestión explícita de fallos y observabilidad. El reto es diseñarlos antes de necesitarlos, no después de haber encontrado el modo de fallo a las 2 de la mañana con un sistema en producción ejecutando una tarea crítica.

Si estás construyendo un sistema agéntico de larga duración y quieres revisar el diseño del harness antes de desplegarlo, estamos disponibles para esa conversación.

→ Habla con nosotros sobre tu arquitectura

Más lectura: Desarrollo de agentes de IA · Qué es un sistema agéntico de IA · Caso de estudio: AI Call Compliance Agent