MSTech Geeks

Harness Engineering: un agente potente sin harness es solo una demo con buena prensa

Todos hemos visto el mismo vídeo de demo: un agente resuelve una tarea compleja en treinta segundos, la sala aplaude, y alguien publica un post diciendo que esto lo cambia todo. Luego llega el lunes, hay que meter ese agente en un sistema que ya existe, con usuarios reales, con fallos reales, con la necesidad de recordar qué pasó ayer, y el vídeo de la demo deja de servir de guía. Lo que separa una demo de un sistema en producción casi nunca es el modelo. Es el harness, todo lo que rodea al modelo y que decide si sobrevive fuera del vídeo.

Harness Engineering es el nombre que le pongo a esa disciplina: memoria persistente, orquestación de varios agentes trabajando a la vez, puntos de control con intervención humana, skills reutilizables entre agentes, y la capacidad de retomar exactamente donde se quedó algo que se cayó a mitad de camino. Y aquí viene la parte buena para cualquiera que trabaje con tecnología Microsoft: buena parte de este harness ya viene integrado de fábrica en Microsoft Agent Framework, no hay que inventarlo desde cero.

Memoria y estado entre sesiones

Un agente sin memoria entre ejecuciones es, en la práctica, un desconocido nuevo cada vez que le hablas. Agent Framework resuelve esto en dos capas. La más sencilla: los threads de cada agente se persisten entre ejecuciones de un mismo workflow, así que si un agente generó algo en la primera ejecución, ese contenido sigue disponible en la siguiente. Hay una advertencia importante en la propia documentación de Microsoft que conviene tomarse en serio: esa persistencia puede provocar que estado de una tarea se filtre a otra si reutilizas la misma instancia de workflow para peticiones distintas. La solución recomendada es envolver la creación de agentes y workflow en un método auxiliar para que cada llamada produzca instancias nuevas con sus propios threads.

La capa más profunda es el checkpointing. Los workflows de Agent Framework corren en supersteps, siguiendo un modelo de ejecución tipo Pregel, y al final de cada superstep se puede guardar un checkpoint con el estado completo: mensajes pendientes, variables internas de cada executor, y el estado compartido del workflow entero. Para desarrollo local hay almacenamiento en sistema de ficheros; para producción, CosmosCheckpointStorage guarda cada checkpoint como documento JSON en Azure Cosmos DB, usando el nombre del workflow como partition key. Si el proceso se cae a mitad de una tarea de dos horas, no la repites desde cero, la retomas desde el último superstep completado.

Orquestación del trabajo en oleadas

Agent Framework no obliga a elegir un único patrón de coordinación entre agentes, trae varios integrados: secuencial, concurrente, handoff (un agente le pasa el testigo a otro) y magentic, un patrón de colaboración en grupo pensado para tareas abiertas donde no está claro de antemano qué agente debería encargarse de cada parte. El modelo de supersteps de Pregel es lo que hace posible patrones de fan-out y fan-in sin que tengas que escribir tú la sincronización a mano: varios agentes procesan la misma entrada en paralelo, y el workflow espera a que todos terminen esa ronda antes de avanzar a la siguiente.

Esto es justo lo que hace posible construir algo como un equipo de agentes especializados, uno de investigación, uno de validación, uno de redacción, sin que la coordinación entre ellos se convierta en el código más frágil de todo el sistema.

Puntos de control con intervención humana

No todo debería resolverlo un agente solo, y Agent Framework tiene un mecanismo específico para esto: el patrón RequestPort. Un workflow puede emitir un RequestInfoEvent en mitad de la ejecución, pausarse, y esperar una respuesta externa antes de continuar. Lo interesante es que estas peticiones pendientes se guardan como parte del propio checkpoint, así que si restauras un workflow desde un punto guardado, cualquier solicitud de intervención humana que estuviera pendiente se vuelve a emitir automáticamente. No se pierde la pausa por el camino.

Esto conecta directamente con la capa de evaluación de la que hablamos en el artículo anterior de esta serie: los mismos umbrales que definías como gate en tu pipeline de evaluación pueden convertirse en el disparador que decide si un workflow sigue solo o pide intervención antes de continuar.

Skills reutilizables entre agentes

Aquí Microsoft resuelve algo que la mayoría de equipos construye a mano y mal: Agent Skills permite construir bases de conocimiento específicas de dominio a partir de varias fuentes (ficheros, código inline, librerías de clases) para que cualquier agente las descubra y las use. En vez de copiar la misma lógica de negocio dentro del prompt de cada agente nuevo que montas, la escribes una vez como skill y la conectas donde haga falta. Es la diferencia entre mantener una fuente de verdad y mantener seis copias ligeramente distintas de la misma idea, cada una desincronizándose a su ritmo.

De desarrollo a producción sin reescribir nada

La prueba de que esto está bien diseñado como harness, y no como un apaño, es que puedes cambiar de entorno de ejecución sin tocar la lógica del workflow. El mismo workflow que corre en memoria durante desarrollo puede pasar a ejecutarse sobre Durable Task Scheduler para producción: checkpointing distribuido, orquestaciones de minutos, horas o incluso días, panel de monitorización incluido, y cada executor de tu workflow se convierte automáticamente en una actividad duradera. La definición del workflow no cambia una línea. Solo cambia el runtime que lo hospeda.

Y si quieres desplegarlo como agente hospedado en Foundry, la propia documentación lo resume así: dos líneas de código adicionales. La observabilidad viene integrada vía OpenTelemetry de serie, así que cada ejecución queda conectada con las trazas y evaluaciones del Foundry Control Plane del que hablamos en el primer artículo de esta serie, sin montar tú el pipeline de telemetría por tu cuenta.

El harness es la parte que no sale en la demo

Nadie graba un vídeo de treinta segundos enseñando un checkpoint restaurándose después de un fallo, o una skill reutilizada entre tres agentes distintos sin duplicar una línea. Por eso no se ve, y por eso se subestima. Pero es exactamente lo que decide si lo que construiste el fin de semana sigue funcionando dentro de seis meses, con usuarios reales, con fallos reales, y sin que tengas que estar tú delante para explicarlo cada vez que algo se cae.