Ocho agentes para repaquetizar software legacy sin que ninguno firme su propio trabajo
Repaquetizado de software legacy con agentes de IA: separación de responsabilidades, triaje antes de ejecutar, triple verificación y rollback automático.
- arquitectura
- agentes-ia
- msix
- legacy
- orquestacion
- verificacion
Decenas de aplicaciones que ya nadie sabe explicar
Un catálogo corporativo de aplicaciones de escritorio, empaquetadas en un formato de virtualización que está en vía muerta, y que hay que llevar a un formato moderno de empaquetado y firma. Visto de lejos parece un problema de conversión de formato.
No lo es.
Los números del proceso manual están medidos y son públicos: un técnico experimentado tarda entre seis y ocho horas por aplicación, y la tasa de éxito que publica la propia comunidad técnica se mueve entre el 40% y el 60%. Con decenas de aplicaciones en el catálogo, eso son meses de trabajo con la mitad del resultado sin resolver y sin saber de antemano qué mitad.
En términos de negocio el problema es el plazo y la incertidumbre: no puedes planificar una migración de puestos cuando no sabes si el paquete de la semana que viene funcionará. En términos de sistema, el problema es otro y es más incómodo: nadie sabe ya qué hace por dentro cada aplicación. Windows Server 2003 dejó de tener soporte el 14 de julio de 2015 y sigue sosteniendo procesos críticos en organizaciones grandes; el software que corre encima tiene la misma edad y la gente que lo construyó ya no está.
El enunciado real, entonces: el cuello de botella de una migración legacy no es convertir, es entender qué estás convirtiendo. Todo lo demás se deriva de eso.
Las decisiones que sostienen la fábrica
Separación de responsabilidades entre ocho agentes. Inventario, investigación, triaje, conversión, ingeniería de compatibilidad, reescritura, control de calidad y empaquetado final. Un agente por fase, con una responsabilidad cada uno, y una regla dura por encima de todas: ningún agente valida ni firma lo que él mismo ha construido. El que convierte no valida. El que valida no firma. El que investiga no ejecuta.
La razón es la misma que en cualquier organización humana: un agente que revisa su propio trabajo aprueba siempre. No porque mienta, sino porque revisa con el mismo modelo mental que usó para construir, y ese modelo mental es precisamente el que contiene el error.
Trade-off aceptado: más saltos, más latencia por aplicación y más coste de inferencia que un agente único haciendo todo el ciclo, a cambio de verificación adversarial real. Esta decisión, y no la elección de modelo, es la que sostiene la calidad.
Triaje antes de ejecutar. Un agente clasifica cada aplicación en una de cuatro estrategias —conversión directa, conversión con capa de compatibilidad a medida, reescritura asistida, o mantenimiento documentado del formato original— y escribe un plan específico para esa aplicación antes de que nadie toque nada.
Trade-off aceptado: construir y mantener cuatro caminos de ejecución en vez de uno, a cambio de no heredar la tasa de éxito del proceso manual.
Triple verificación con rollback automático. Validación del artefacto, certificación técnica automatizada, y prueba funcional en una máquina limpia restaurada desde snapshot antes de cada test. Si cualquiera de las tres falla, el pipeline revierte y devuelve la aplicación a la fase anterior con el diagnóstico adjunto.
El detalle del snapshot parece menor y no lo es. Sin restaurar la máquina de pruebas a cero antes de cada test, arrastras residuos del paquete anterior: dependencias que ya quedaron instaladas, claves de registro que otro test dejó puestas. Al décimo paquete, tu control de calidad no valida un producto, valida una máquina.
Trade-off aceptado: minutos de restauración de snapshot por cada test, y un pipeline que se detiene y retrocede en vez de avanzar, a cambio de que un "pasa" siga significando lo mismo en el paquete diez que en el primero.
Base de conocimiento compartida como único canal entre agentes. Los agentes no se hablan directamente. Escriben sus hallazgos en un almacén común —expuesto como servidor MCP— y otros los consumen desde ahí.
Trade-off aceptado: más latencia por salto y una indirección extra en cada intercambio, a cambio de que todo lo aprendido sobre una aplicación quede disponible para el siguiente lote y para el siguiente proyecto. Es el trade-off que peor supe vender: lo que queda cuando termina el trabajo no son los paquetes, es la base de conocimiento — y el segundo lote cuesta una fracción del primero porque la fábrica persiste.
Aislamiento por rol en cuatro máquinas virtuales. Una para el cerebro orquestador, una con el stack pesado de herramientas de empaquetado, y dos de control de calidad limpias que simulan el puesto de trabajo final. La máquina donde se construye nunca es la máquina donde se prueba.
Trade-off aceptado: cuatro entornos que mantener, aprovisionar y sincronizar en vez de uno, a cambio de poder distinguir "funciona" de "funciona en la máquina donde lo compilé".
Auditoría central de cada acción. Cada acción de cada agente con marca de tiempo, comando y resultado. Trade-off aceptado: volumen de registro y disciplina de instrumentación en todas las fases, a cambio de que el sistema sea explicable. Sin eso, un sistema multiagente es una caja negra en la que nadie confía, y con razón.
En el diagrama hay que mirar dos cosas: que el nodo de control de calidad es distinto del de conversión, y el bucle que devuelve al agente de compatibilidad cuando algo falla.
Qué descarté y por qué
Un pipeline único para todo el catálogo. La opción que sale sola cuando piensas en la conversión como problema de formato. Produce exactamente el 40-60% del operario humano, y por el mismo motivo: aplica la misma receta a problemas distintos.
Un entorno único para construir y probar. Más barato, y hace estructuralmente imposible detectar el fallo más común en repaquetizado: la dependencia que está en la máquina de build y no en el puesto de trabajo.
Comunicación directa entre agentes. Un bus de mensajes entre pares arranca antes. Descartado porque el conocimiento se queda en el mensaje: cuando la conversación termina, lo aprendido sobre esa aplicación se ha ido.
Un modelo único para las ocho fases. Descartado a favor de enrutar cada tarea al modelo que le corresponde. Inventariar no exige lo mismo que reescribir código, y pagar el modelo más caro para leer un manifiesto es un impuesto sobre cada aplicación del lote.
Dejar que un agente firme su propio trabajo. La simplificación que ahorra más piezas y la que invalida el sistema entero: el output no es verificable y, por tanto, no es entregable.
Estado real
Diseño entregado, no ejecutado. Y aquí no hay medias tintas: la fábrica completa —los ocho agentes, las cuatro máquinas por rol, el triaje y la triple verificación— es una arquitectura que diseñé y entregué, no un sistema que haya procesado un catálogo. Presenté una propuesta comercial concreta para convertir el catálogo de una gran corporación con esta fábrica y se rechazó por precio: el lote nunca entró. El diseño entregado incluía la arquitectura de los ocho agentes, el catálogo triado por estrategia, la especificación de infraestructura y el plan de ejecución por fases, con un objetivo de diseño del 87-97% de éxito frente al 40-60% manual. Ese 87-97% es exactamente eso: un objetivo de diseño, jamás una medición. No hay medición porque no hubo lote.
Lo que sí está construido y en uso diario es el toolchain de empaquetado y firma MSIX sobre el que se apoyaría la fase 8: una pieza del pipeline, no el pipeline. Y lo que se transfiere de todo esto es la metodología.
Lecciones transferibles
La primera vale para cualquier sistema multiagente: antes de elegir modelo, separa quién ejecuta de quién valida. La calidad no sale de la inteligencia del modelo, sale de que exista alguien distinto revisando. Es separación de poderes, no ingeniería de prompts.
La segunda es sobre el estado: la verificación caduca si el entorno de prueba no se restaura. Da igual que valides código, paquetes o respuestas de un modelo — si el entorno acumula residuos de la ejecución anterior, tu suite pierde significado sin avisarte.
La tercera: el activo que persiste no es el entregable, es lo que el sistema aprendió produciéndolo. Si tus agentes se comunican de forma efímera, cada proyecto empieza de cero y pagas la curva de aprendizaje entera cada vez.
Y la incómoda, que es de negocio y no de sistema: sobre el papel el diseño batía a la alternativa manual en coste, plazo y tasa de éxito esperada, y la propuesta se cayó igual — así que nunca llegó a demostrarlo. Presenté horas de arquitecto cuando lo que se compra son unidades entregadas. Y el argumento más fuerte del diseño —que el segundo lote cuesta una fracción del primero porque la fábrica persiste— lo enterré en la última página. La ingeniería estaba resuelta; la unidad de venta, no.
Relacionado
- Aislamiento de instancias para orquestación paralela — la utilidad que hace posible correr varios de estos orquestadores en paralelo en una sola máquina.
- Una utilidad de sistema con cero superficie de red — la otra cara de la misma disciplina: restringir la arquitectura como decisión de producto.
Este diseño lo conté resumido en LinkedIn: Ocho agentes IA, una regla: ninguno puede firmar lo que él mismo construyó (linkedin.com/in/carlosdelatorre-ai).