Un sistema multiagente en acción: 46 ejecuciones sobre un producto real

Del modelo de equipo a una traza real completa

Hace unos meses publiqué cómo organizo agentes, subagentes y QA para construir producto real. Aquel artículo explicaba el modelo: un agente coordinador, agentes de implementación, especialistas, control de calidad (QA) independiente, fuentes de verdad, documentación viva y límites operativos.

Era una descripción de la forma de trabajo que había integrado alrededor de Enolisa. Faltaba enseñar una ejecución completa: qué ocurre cuando una especificación transversal entra en el sistema, se convierte en un grafo de tareas, atraviesa varias rondas de implementación y QA y termina desplegada y validada en producción.

Esa traza ya existe.

La tarea duró 3 horas y 24 minutos y produjo 46 ejecuciones de agentes de IA. De ellas, 41 dependieron directamente del coordinador y 5 fueron delegaciones anidadas. El trabajo afectó a cinco repositorios, diez consumidores en Google Cloud y terminó distribuido en 20 cambios versionados. También permitió retirar de forma controlada 237 revisiones históricas que ya no debían seguir formando parte del recorrido productivo.

Las cifras ayudan a dimensionar la ejecución, pero no son la tesis. Lo relevante es observar cómo un sistema previamente diseñado pudo repartir responsabilidad, integrar resultados y corregir desviaciones sin convertir cada decisión en una intervención manual.

El caso demostrador: diez servicios y una evolución de acceso a datos

La especificación planteaba una evolución interna de la conexión PostgreSQL utilizada por varias funciones y servicios de Enolisa.

El sistema estaba operativo y los contratos con la aplicación eran estables. El objetivo era pasar de un usuario técnico compartido y una contraseña configurada en variables de entorno a un modelo basado en Cloud SQL Connector, autenticación IAM automática, credenciales efímeras, identidades de ejecución separadas por dominio y roles NOLOGIN con permisos mínimos.

La migración tenía que cubrir diez consumidores distribuidos por función de producto:

Dominio	Superficie	Responsabilidad
Catálogo de vinos y API	Cinco puntos de entrada	Búsqueda, ficha de vino, región y lectura/escritura de votos
Inicio, recomendaciones y opinión de usuario	Tres servicios	Contenido de inicio, recomendaciones, caché y opinión de usuario
Resultados de IA	Una función orientada a eventos	Preparación y persistencia de resultados generados
Telemetría de escaneo	Una función Pub/Sub conectada con GCS	Registro técnico del flujo de reconocimiento
Gobierno transversal	Contratos y documentación	Inventario, evidencias y compatibilidad con la aplicación

El cambio debía ser invisible para el frontal. Las entradas, respuestas, errores y estructuras de datos tenían que mantenerse. La aplicación no debía necesitar una nueva versión para adaptarse a la evolución de identidad, conexión y permisos que ocurría por debajo.

Este era un buen caso para probar el sistema multiagente porque combinaba código, base de datos, Google Cloud, despliegues, observabilidad, contratos funcionales y documentación en varios repositorios. También exigía intervenir en producción y demostrar el resultado con pruebas reales.

Qué hice yo y qué hizo el sistema

La atribución importa, especialmente al hablar de autonomía.

Yo había diseñado e integrado previamente el sistema de coordinación: instrucciones globales y locales, mapa de repositorios, agentes especializados, reglas de responsabilidad, fuentes de verdad, carriles operativos, controles de QA y condiciones de cierre.

Para esta evolución definí el objetivo y los límites, revisé la especificación previa, autoricé las mutaciones productivas necesarias y acepté el resultado final después de recibir las evidencias. Esas decisiones no se delegaron.

La coordinación de las 46 ejecuciones correspondió al agente coordinador. A partir de la especificación:

1. identificó las superficies afectadas;
2. separó el trabajo por dominio y repositorio;
3. asignó agentes de implementación y QA;
4. reservó agentes de solo lectura para arquitectura y observabilidad;
5. integró los paquetes devueltos por cada línea;
6. devolvió las carencias al responsable adecuado;
7. utilizó los carriles autorizados para desplegar y validar;
8. cerró con documentación, doble comprobación y auditoría independiente.

Mi papel se concentró en diseñar el marco, definir la intención, conservar las decisiones sensibles y revisar si la evidencia final justificaba aceptar el cierre. El reparto de subtareas, los intercambios entre agentes y las devoluciones de QA quedaron dentro del sistema de coordinación.

Esa diferencia es central. Un grupo de agentes ejecutando instrucciones aisladas no constituye por sí mismo un sistema. La capacidad aparece cuando existe una estructura persistente que puede transformar una intención en trabajo coordinado sin perder límites ni responsabilidad.

La especificación como contrato de entrada

El coordinador no empezó editando código. Recibió una especificación respaldada por un inventario previo de consumidores, mecanismos de conexión, identidades, permisos efectivos y evidencias de uso.

Ese documento cerraba los elementos que no debían improvisarse durante la ejecución:

• alcance y exclusiones;
• mapa de consumidores confirmados;
• arquitectura de identidad objetivo;
• permisos necesarios por operación;
• orden de aplicación;
• pruebas anteriores y posteriores;
• criterios para detener una fase;
• documentación y evidencias esperadas;
• definición de cierre.

La especificación no intentaba adivinar cada problema que podía aparecer en producción. Su función era dar al coordinador una base suficientemente precisa para descomponer el trabajo y una referencia contra la que evaluar cualquier desviación.

Sin ese contrato de entrada, los agentes habrían tenido que descubrir la arquitectura al mismo tiempo que la modificaban. Con él, cada agente podía trabajar sobre una superficie delimitada y el QA podía revisar contra decisiones ya establecidas.

De documento a grafo de trabajo

El coordinador convirtió la especificación en varias líneas que podían avanzar en paralelo sin competir por los mismos archivos ni por la misma autoridad.

Una línea se ocupó de la capa de catálogo y API. Otra cubrió Inicio, recomendaciones y opinión de usuario. Una tercera atendió el procesamiento de resultados de IA. La cuarta se centró en la telemetría de escaneo. En paralelo, una línea común preparó las migraciones SQL, las comprobaciones de identidades y las herramientas de validación.

Alrededor de ellas trabajaron agentes de arquitectura de Google Cloud, observabilidad, sincronización documental y auditoría final.

El coordinador no esperaba respuestas genéricas. Cada línea tenía que devolver un paquete con:

• cambios realizados;
• archivos afectados;
• migraciones y configuración;
• pruebas ejecutadas y resultado;
• revisión independiente;
• documentación actualizada;
• riesgos residuales o confirmación de que no quedaban riesgos relevantes.

Ese formato permitió integrar entregables, no conversaciones. El estado compartido vivía en código versionado, migraciones, resultados de pruebas, inventarios y documentos; no dependía únicamente del contexto acumulado por el coordinador.

Qué produjeron los agentes

Los entregables cubrieron varias capas del sistema:

• paquetes de implementación separados por dominio;
• adaptación del código al nuevo mecanismo de conexión;
• migraciones SQL versionadas;
• carriles de despliegue ajustados a las nuevas identidades;
• pruebas unitarias y de contrato;
• ejecutores de pruebas de extremo a extremo en producción;
• inventarios de identidades y revisiones activas;
• evidencias estructuradas en JSON;
• análisis de registros posteriores al despliegue;
• matriz transversal de consumidores;
• documentación viva del estado final.

Esto conecta con una idea que desarrollé en Cuando un agente toca producción, el prompt ya no es suficiente: una instrucción puede orientar el razonamiento, pero una condición importante necesita una comprobación externa al modelo.

Aquí no bastaba con que un agente afirmara que una función utilizaba su nueva identidad. La configuración observada tenía que demostrarlo. Tampoco bastaba con declarar que los permisos eran mínimos o que el contrato seguía intacto: había que ejecutar consultas, pruebas funcionales y comparaciones sobre el resultado real.

Siete iteraciones y una misma mecánica de corrección

La ejecución no fue una secuencia lineal. Las pruebas encontraron diferencias entre el diseño esperado y el comportamiento efectivo de distintos componentes. El valor del grafo se vio en cómo procesó esas diferencias.

El patrón se repitió en cada caso:

evidencia → carencia localizada → responsable correcto → corrección mínima → nuevo QA

El permiso adicional de una operación UPSERT

Una función registraba eventos mediante una inserción o actualización. Los permisos iniciales cubrían la escritura, pero la sentencia real también necesitaba leer columnas concretas.

La prueba de extremo a extremo detectó el fallo. El coordinador no abrió una revisión global de permisos: devolvió la evidencia al agente responsable de la migración SQL. Ese agente añadió únicamente la lectura necesaria y el QA repitió el flujo completo.

La normalización del usuario IAM

La identidad de Google Cloud y el usuario IAM de PostgreSQL no utilizaban exactamente la misma representación. La diferencia solo apareció al validar la conexión real.

La carencia volvió a la línea que gestionaba el alta de identidades. Se verificó el formato efectivo del servicio, se corrigió el recurso versionado y se repitieron las pruebas de conexión y membresía.

El entorno heredado por los despliegues

Aunque el código ya no dependía de credenciales persistentes, un carril de despliegue podía heredar variables de la terminal local y trasladarlas a una revisión nueva.

El coordinador asignó la corrección a los propietarios de cada carril. Los scripts limpiaron de forma explícita ese entorno y el QA verificó después la configuración efectiva de las revisiones desplegadas, no solo los archivos del repositorio.

Los límites del propio sistema de pruebas

Una prueba de la API alcanzó un límite de cuota por la forma en que preparaba datos sintéticos. La función productiva era correcta; la prueba consumía más recursos de los necesarios.

La incidencia volvió al responsable del ejecutor. Se redujo el consumo manteniendo la misma cobertura y el QA confirmó que el ajuste no debilitaba la evidencia.

Una diferencia de la versión gestionada de PostgreSQL

Otra comprobación asumía una forma de resolver la dirección principal de la instancia que no coincidía con la versión gestionada en producción.

El coordinador separó el fallo de la arquitectura funcional y lo dirigió al agente propietario de las herramientas auxiliares. Se adaptó la comprobación a la fuente de verdad vigente y se repitieron los casos afectados sin modificar las funciones para acomodar una suposición del test.

El objeto de prueba protegido por retención

La validación de telemetría utilizó un objeto sintético diminuto en GCS. La política de retención impedía borrarlo o sobrescribirlo al terminar.

En lugar de cambiar la política de plataforma, el responsable del dominio transformó ese objeto en un canario inmutable y documentado. Las pruebas posteriores dejaron de escribir sobre él y limpiaron únicamente los datos que sí eran temporales.

El saneado de las propias trazas

Cuando implementación, despliegues y pruebas ya estaban en verde, la auditoría independiente amplió preventivamente la cobertura del saneado de trazas a más formatos de configuración que las herramientas podían generar.

El coordinador devolvió el hallazgo al carril de despliegue. Se añadieron casos adversariales, se reprocesaron artefactos históricos bajo la misma política y otro QA comprobó que el resultado era idempotente.

Ninguna de estas iteraciones requirió abandonar el plan ni ampliar indiscriminadamente permisos y alcance. La combinación de responsabilidad explícita y evidencia permitió corregir cada carencia en la superficie que realmente la había producido.

Producción formó parte de la validación

La ejecución debía demostrar dos propiedades al mismo tiempo: que la nueva arquitectura de identidad funcionaba y que el producto seguía comportándose igual.

Para ello combinó:

• pruebas unitarias por repositorio;
• pruebas de contrato sobre entradas, salidas y errores;
• inspección de la configuración desplegada;
• conexiones reales con las nuevas identidades;
• pruebas de extremo a extremo sobre catálogo, Inicio, recomendaciones, opinión de usuario, resultados de IA y telemetría;
• lectura de registros de las revisiones activas;
• revisión de permisos efectivos;
• comprobación final de los contratos consumidos por la aplicación.

Los datos de prueba eran sintéticos, identificables y tenían limpieza explícita. Cuando una política de plataforma impedía eliminar un artefacto, la excepción quedaba inventariada y convertida en una condición comprobable.

Tras desplegar, se observaron las diez revisiones activas para buscar errores de autenticación, permisos o ejecución. También se verificó que cada servicio utilizara la identidad prevista y que el tráfico ya no alcanzara revisiones históricas con configuración anterior.

El cambio se mantuvo por debajo de la interfaz funcional. Identidad, conexión y privilegios evolucionaron, mientras las estructuras enviadas y recibidas por la aplicación permanecieron intactas.

La trazabilidad permite reconstruir el trabajo

Al terminar quedaron 20 cambios versionados repartidos en cinco repositorios, las migraciones, los resultados de pruebas, los inventarios de Google Cloud y PostgreSQL, las evidencias JSON, los registros de despliegue y la documentación final.

También quedó la traza de coordinación: qué agente recibió cada tarea, qué QA la revisó, qué carencia devolvió, qué corrección se aplicó y qué evidencia permitió avanzar al siguiente control de paso.

Los registros brutos contienen información interna y no son publicables, pero permiten reconstruir el recorrido sin depender de la memoria de una conversación. Un agente futuro puede leer las fuentes vigentes, comparar el entorno observado y saber qué condiciones sostienen el estado aceptado.

La documentación no fue un resumen administrativo añadido al final. Formó parte del entregable técnico y de la continuidad del sistema.

Qué demuestra este caso sobre el método

La primera conclusión es que el coordinador necesita un contrato de entrada útil. La autonomía no compensa un objetivo ambiguo, límites incompletos o una arquitectura sin fuentes de verdad.

La segunda es que paralelizar funciona cuando existe responsabilidad clara. Cada dominio tenía un propietario, una superficie de escritura y una salida esperada. El coordinador podía integrar sin resolver continuamente conflictos entre agentes.

La tercera es que el QA aporta valor cuando puede detener el avance y devolver una carencia concreta. La revisión no era una opinión general sobre el código, sino una comprobación contra contratos, permisos, configuración y comportamiento productivo.

La cuarta es que los controles de paso deben corresponder al riesgo. Leer arquitectura, modificar una migración, desplegar una función y aceptar el cierre no tienen la misma autoridad ni requieren la misma evidencia.

La quinta es que una iteración no representa un fracaso del sistema. Cuando la evidencia localiza una diferencia, el grafo identifica al responsable, aplica una corrección mínima y vuelve a validar. Esa capacidad de retorno es parte del diseño.

Y la sexta es que el volumen por sí solo no acredita calidad. Cuarenta y seis ejecuciones pueden producir ruido si carecen de responsabilidad, contratos y criterios de cierre. En este caso resultaron útiles porque trabajaban dentro de una estructura persistente y convergían sobre evidencias comunes.

El sistema que describí, ahora observado en funcionamiento

El artículo anterior explicaba el modelo organizativo. Este caso permite verlo actuando de principio a fin sobre una evolución real: especificación, grafo de tareas, implementación paralela, QA, iteraciones, despliegue, observabilidad, documentación y aceptación final.

La evolución PostgreSQL/IAM reunió en una sola ejecución las condiciones que más exigen al modelo: varios repositorios, contratos que preservar, acciones productivas, decisiones con distinta autoridad y suficiente complejidad como para que una única línea de trabajo perdiera contexto.

Yo aporté el objetivo, los límites, la autorización y la aceptación. El sistema previamente integrado convirtió esas decisiones en trabajo coordinado y auditable.

Ahí está el valor que me interesa: no en sustituir el criterio ni en acumular agentes, sino en convertir una intención bien definida en una secuencia de responsabilidades, controles y evidencias capaz de avanzar sobre un producto real.