Más allá del código: La arquitectura multiagente es la próxima frontera de nuestra gobernanza de IT

Tommy Lambert, director de Sistemas de Información e IA en Converteo, lidera la modernización y unificación del ecosistema tecnológico para impulsar el crecimiento empresarial. Como miembro del comité ejecutivo, combina la gobernanza de datos, la ciberseguridad y la integración de la IA para automatizar flujos de trabajo y maximizar la eficiencia operativa.

Ideas clave:

• Solución al cuello de botella técnico: la arquitectura multiagente responde al principal desafío de los departamentos de TI, ya que automatiza no solo la generación de código, sino también la supervisión y validación de su ejecución.
• Gobernanza operativa estricta: exige reglas rigurosas, como informes de relevo estructurados para garantizar la trazabilidad y un desarrollo secuencial que evite conflictos de código.
• Productividad con el mismo equipo: implantar este enfoque agnóstico permite triplicar la productividad en los flujos de trabajo sin necesidad de ampliar la plantilla.

Como responsables de tecnología y datos, pasamos gran parte del día resolviendo una ecuación compleja: cómo acelerar los plazos de nuestra hoja de ruta de TI sin disparar los presupuestos, sin acumular deuda técnica y, sobre todo, sin quemar a nuestros equipos.

Durante mucho tiempo pensamos que la inteligencia artificial generativa resolvería este problema escribiendo código en lugar de los humanos. Fue un error de perspectiva.

Hoy en día, la inteligencia bruta de los modelos ya no es el factor limitante. El verdadero cuello de botella de nuestros departamentos de TI es la atención humana (Luke Alvoeiro, Factory, 2026). Un ingeniero sénior, por muy brillante que sea, solo puede supervisar y validar dos o tres proyectos complejos a la vez.

Aquí es donde el enfoque de la arquitectura multiagente cambia las reglas del juego: no se limita a generar líneas de código, sino que automatiza la propia supervisión de la ejecución.

Estructurar el caos: Una taxonomía para nuestras decisiones de arquitectura

Al explorar el ecosistema de los frameworks multiagente, nos enfrentamos a un ruido de marketing considerable. Para guiar nuestras decisiones tecnológicas, debemos apoyarnos en una taxonomía clara y pragmática. Luke Alvoeiro (Factory) identifica cinco modos de interacción fundamentales:

• Delegación: Un agente maestro distribuye subtareas a agentes especializados (por ejemplo, la modelización de un esquema de base de datos). Es el primer nivel de automatización.
• La pareja creador / verificador: Indispensable para la calidad. El agente que escribe el código tiene el denominado sesgo del creador, que le impulsa a querer que su obra funcione. Confiar la revisión a un tercer agente, dotado de un contexto limpio, elimina este sesgo cognitivo.
• Comunicación directa: Intercambios peer-to-peer sin supervisor. Un modelo atractivo sobre el papel, pero de alto riesgo para nuestra gobernanza, ya que el estado de la información se fragmenta rápidamente.
• Negociación: Ideal para la gestión de recursos compartidos (acceso a API, conflictos de fusión de código o merge conflicts) mediante protocolos de compromiso no conflictivos.
• Difusión: La transmisión síncrona de las reglas de negocio y las restricciones de arquitectura a todo el sistema, garantizando la alineación continua de los agentes.

El framework de “Misiones”: Dirigir la tecnología mediante contratos de validación

Para superar la fase de simple herramienta experimental, una arquitectura multiagente debe poder funcionar de manera autónoma durante varios días. Esto es lo que propone el concepto de “Misiones”, un enfoque industrializado basado en tres roles estrictos: un Orquestador (que define la necesidad y gestiona la división de tareas), Trabajadores (que ejecutan el código en un contexto propio) y Validadores (que controlan la calidad).

Desde el punto de vista del Director de IT, la verdadera disrupción radica en la validación adversarial (por oposición).

Para evitar la trampa clásica del vibe coding —donde el código se produce sobre la marcha y sin salvaguardas—, el framework de Factory invierte el paradigma: el Orquestador redacta el contrato de validación durante la fase de diseño preliminar, antes de escribir la más mínima línea de código de producción. La validación se convierte así en una barrera de seguridad independiente, dividida en dos etapas:

• La validación de rigor: análisis estático del código, linters, tipado y revisiones de código automatizadas.
• La validación de comportamiento (QA): mediante la interacción directa con el sistema (computer use), los agentes despliegan la aplicación en un entorno seguro (sandbox), simulan el comportamiento de un usuario real (clics, rellenado de formularios) y verifican la coherencia funcional de extremo a extremo.

Gobernanza de datos y rendimiento: 2 reglas de oro

Para que estos ecosistemas de agentes se integren en nuestros sistemas de información sin crear desviaciones, se deben respetar dos principios operativos:

1. El traspaso estructurado (Handoffs)

El mayor riesgo de las sesiones de ejecución largas es la pérdida de contexto. Los agentes no deben simplemente enviar código; deben generar informes de relevo estructurados que detallen los objetivos alcanzados, los errores encontrados, los códigos de salida de los terminales y las decisiones tomadas. Esta trazabilidad macroscópica es la que permite al sistema autocorregirse al avanzar entre hitos (milestones).

2. El pragmatismo de la ejecución secuencial

La tentación de la paralelización masiva entre agentes de desarrollo es fuerte, pero resulta contraproducente. Genera conflictos de fusión (merge conflicts) insolubles e incoherencias de arquitectura que consumen en exceso nuestros tokens. La buena práctica consiste en ejecutar las funcionalidades de manera secuencial, y paralelizar únicamente las tareas de solo lectura (búsqueda documental, exploración de bases de código, revisiones de código).

Droid Whispering: Hacia un departamento de IT agnóstico y especializado

Para nosotros, los líderes de tecnología, esta transición marca el nacimiento de una nueva competencia de gestión dentro de nuestros equipos: el “droid whispering”. Ya no se trata de elegir un único LLM para toda la empresa, sino de saber colocar el modelo adecuado en el puesto correcto:

• Capacidades de razonamiento lento y estructurado para el orquestador.
• Fluidez sintáctica y rapidez para los trabajadores.
• Cumplimiento estricto y rígido de las instrucciones para los Validadores (utilizando idealmente un proveedor de modelos diferente al de los creadores para evitar sesgos de aprendizaje).

Este enfoque agnóstico protege a nuestras organizaciones del bloqueo de proveedor (vendor lock-in) y transforma nuestra estructura de costes gracias al uso eficiente de la caché de consultas (prompt caching).

¿Qué ROI aporta a nuestras organizaciones?

El despliegue en producción de estas arquitecturas (probadas en ciclos continuos de hasta 16 días) ofrece resultados cuantitativos tangibles:

• Productividad de los equipos: Volumen de flujos de trabajo activos multiplicado por 3 con un equipo constante.
• Calidad del código: Tasa de cobertura de pruebas que alcanza frecuentemente el 90 %.
• Distribución del esfuerzo: ~60 % del tiempo y de los tokens consumidos se concentran en la implementación de base.