Mi equipo IA: cómo organizo agentes, subagentes y QA para construir producto real

La IA no como asistente, sino como equipo dirigido

Una de las diferencias más importantes en mi forma de trabajar con IA es que he dejado de verla como una conversación aislada.

No me interesa usarla solo para pedir una función, resolver una duda o acelerar una tarea puntual. Eso puede ser útil, pero se queda corto cuando trabajas sobre un producto real con app móvil, backend, datos, analítica, compras, notificaciones, documentación, QA, web y decisiones de negocio.

En ese contexto, la pregunta cambia. Ya no es simplemente:

¿Qué puede hacer una IA por mí?

La pregunta útil es otra:

¿Cómo organizo un sistema de trabajo donde varios agentes puedan aportar capacidad sin perder control, criterio ni trazabilidad?

En Enolisa he ido construyendo ese sistema poco a poco. No como un experimento teórico, sino como respuesta a una necesidad bastante práctica: poder avanzar en muchas capas del producto sin convertir cada cambio en una sucesión de prompts sueltos, decisiones implícitas y validaciones improvisadas.

La idea central es sencilla: la IA funciona mejor cuando no se comporta como un ayudante genérico, sino como un equipo con roles definidos, contexto compartido, límites claros y revisión independiente.

Hay un matiz importante, sobre todo para quien ya trabaja con agentes de IA. Este sistema no nace de instalar un plugin que genera una colección estándar de skills, subagentes o instrucciones. Tampoco es una plantilla genérica aplicada encima del repositorio.

La parte valiosa no está en tener ficheros de configuración o nombres de agentes. Está en el conocimiento específico que contienen: decisiones tomadas durante la construcción de Enolisa, criterios de QA, límites de seguridad, convenciones de producto, reglas de documentación, carriles de solo lectura y aprendizajes acumulados después de resolver problemas reales.

Cada pieza ha ido apareciendo porque el producto lo necesitaba. Un agente para una zona delicada, una regla para evitar una regresión, una instrucción para no repetir un error, una validación para cerrar mejor un flujo o una documentación que permite que el siguiente cambio no empiece desde cero.

Visto así, el valor no está en la instalación inicial ni en la lista de agentes. Está en haber ido convirtiendo experiencia acumulada, decisiones de producto y criterios de validación en una forma de trabajar que el proyecto puede reutilizar.

---

Por qué un solo agente no basta

Un modelo generalista puede escribir código, resumir documentación, revisar un error o proponer una solución. El problema aparece cuando esa misma entidad intenta hacerlo todo a la vez: analizar producto, decidir arquitectura, modificar código, tocar textos, ejecutar pruebas, revisar documentación y declarar que el trabajo está terminado.

En tareas pequeñas puede funcionar. En tareas reales, especialmente si afectan a varias capas, empieza a haber riesgos:

• se mezclan decisiones de producto con detalles de implementación;
• se asume contexto que no está documentado;
• se cambia código sin revisar contratos;
• se valida solo que compila, pero no que el comportamiento sea correcto;
• se actualiza una pantalla y se olvida la internacionalización;
• se toca un flujo sin mirar datos, analítica, QA o documentación;
• se acepta una solución porque parece razonable, no porque esté cerrada.

La solución no es añadir más IA de forma desordenada. La solución es organizarla.

Igual que en un equipo humano no tendría sentido que una persona hiciera de product manager, arquitecto, desarrollador, QA, responsable de documentación y release manager sin ninguna separación de responsabilidades, tampoco tiene sentido pedirle a un único agente que sea todas esas cosas sin reglas.

Mi flujo intenta evitar justo eso: separar trabajo, asignar ownership y cerrar cada cambio con evidencia.

---

El mapa visual del equipo IA

Este es el modelo simplificado del flujo. No representa todos los detalles internos, pero sí la lógica de organización: mi intención activa el sistema, pasa por contexto persistente, se reparte entre agentes especializados, se valida técnicamente de forma independiente y vuelve a mi revisión final antes de cerrar.

Lo importante del diagrama no es la herramienta concreta. La herramienta puede cambiar. Lo relevante es el patrón: dirección propia, contexto, especialización, QA independiente y aceptación final con criterio.

---

El coordinador IA: dirección operativa dentro de mi sistema

En mi flujo hay un agente principal que actúa como jefe de proyecto operativo dentro de la sesión.

Su papel no es escribir todo el código ni resolverlo todo por sí mismo. Su papel es entender la petición, leer el contexto necesario, decidir si la tarea es trivial o no, descomponer el trabajo, asignar responsabilidades, integrar resultados y hacer un doble check final.

Pero ese coordinador no sustituye mi criterio. Trabaja dentro de un marco que he construido previamente: instrucciones, documentación, límites, carriles permitidos, criterios de validación y decisiones acumuladas del producto. Yo estoy antes del proceso, porque defino la intención y el sistema; y estoy al final, porque reviso el resultado completo antes de aceptar el cierre.

Ese punto es importante porque una parte del valor no está en delegar más, sino en delegar mejor.

El coordinador debe decidir:

• qué documentos hay que leer antes de tocar nada;
• qué parte puede investigarse en paralelo;
• qué agente tiene ownership real sobre cada zona;
• qué cambios requieren mi confirmación;
• qué validación mínima hace falta;
• qué documentación queda afectada;
• qué riesgos residuales hay que dejar explícitos.

Este rol se parece más a dirección técnica que a generación de código. No se limita a ejecutar una orden. Interpreta el trabajo dentro del sistema.

Para mí, esa es una de las diferencias entre usar IA como herramienta y usar IA como capacidad operativa: hay una capa de gobierno.

---

Workers, QA y especialistas

Dentro de ese sistema, no todos los agentes hacen lo mismo. Algunos desarrollan. Otros validan. Otros solo leen datos o documentación. Otros ejecutan tareas mecánicas muy acotadas.

Una forma sencilla de verlo es esta:

Tipo de agente	Responsabilidad principal	Qué evita
🧭 Coordinador IA	Define alcance operativo, reparte ownership, integra y prepara el cierre.	Que la tarea avance sin dirección ni criterio global.
🛠️ Worker	Implementa una parte concreta del cambio.	Que el agente principal lo haga todo sin separación de responsabilidades.
🔎 QA independiente	Revisa comportamiento, pruebas, documentación y riesgos.	Que quien implementa sea el único que valida.
🧩 Especialista	Aplica reglas de una zona concreta: UI, i18n, compras, sync, analítica, backend o datos.	Que un cambio local rompa contratos o convenciones de producto.
✅ Agente mecánico	Ejecuta tareas cerradas como formato, generación o tests acotados.	Que tareas repetibles consuman atención de arquitectura.
📚 Agente readonly	Inspecciona logs, datos o estados reales sin mutarlos.	Que la investigación runtime mezcle lectura con operación peligrosa.

La separación más importante es la de desarrollo y QA.

Si un worker implementa un cambio, no debería ser el único que decide que todo está bien. Otro agente debe revisar la salida con una mirada distinta: tests, regresiones, documentación, edge cases, comportamiento esperado y riesgos.

Esto no elimina mi revisión. La mejora.

Cuando el trabajo vuelve al coordinador, no vuelve como una respuesta vaga de “hecho”. Debe volver como un paquete preparado para revisión: qué se tocó, qué se validó, qué quedó documentado, qué riesgos quedan y si el QA está OK. Después queda mi validación final: revisar si el resultado encaja con el objetivo, si el riesgo residual es aceptable y si realmente se puede cerrar.

---

Un ejemplo de flujo real

Imaginemos una mejora de producto que afecta a una pantalla, a un pequeño servicio de datos y a la comunicación con el usuario. No hace falta entrar en lógica sensible para explicar el flujo.

El proceso no empieza escribiendo código. Empieza con una lectura de alcance:

1. entender qué problema de producto se quiere resolver;
2. comprobar qué documentación viva aplica;
3. identificar si hay contratos, datos, UI, textos, analítica o QA afectados;
4. decidir si el cambio es local o necesita coordinación con otro repositorio;
5. separar lo que puede hacerse en paralelo de lo que debe mantenerse serializado.

Después, el coordinador puede repartir trabajo.

Un worker implementa el cambio principal. Un especialista de UI revisa que el layout no esté pensado solo para un móvil pequeño. Un especialista de i18n comprueba que no haya textos hardcodeados y que los idiomas queden alineados. Un agente de testing ejecuta el scope más acotado que cubre el cambio. Si hay datos reales que conviene inspeccionar, entra un carril readonly.

Cuando aparece un fallo, el QA no lo maquilla ni lo resuelve cambiando cualquier cosa. Devuelve el problema al worker o al coordinador con evidencia. El worker corrige y se vuelve a validar.

Solo después de esa validación técnica y de mi revisión final se cierra.

El cierre no significa “parece que funciona”. Significa que el resultado ha pasado por el nivel de validación razonable para su riesgo.

---

Reglas que dan seguridad al sistema

Trabajar con varios agentes no significa darles barra libre. De hecho, cuanto más capaz es el sistema, más importantes son los límites.

En mi flujo hay varias reglas que considero básicas:

• no desplegar a producción sin confirmación explícita;
• no cambiar dependencias o SDKs sin justificar motivo, alternativas, riesgos y plan de validación;
• no mutar datos reales desde carriles que son de solo lectura;
• no publicar secretos, contratos completos ni reglas sensibles;
• no aceptar una tarea de código sin validación técnica pertinente;
• no considerar format como validación funcional;
• no cerrar cambios de i18n dejando idiomas a medias;
• no permitir escritura concurrente sin ownership claro;
• no tratar una reducción de logs como solución si el problema de fondo sigue existiendo.

Estas reglas pueden parecer conservadoras, pero son las que permiten aumentar velocidad sin aumentar desorden.

La IA no necesita menos proceso. Necesita mejor proceso.

Cuando un agente puede modificar varios archivos, ejecutar comandos y razonar sobre arquitectura, el problema ya no es solo si sabe hacerlo. El problema es si lo hace dentro de un marco que protege el producto.

---

Documentación viva como memoria del equipo

Un equipo IA necesita memoria operativa.

No basta con que una conversación salga bien. Si el conocimiento se queda en un chat, se pierde contexto en la siguiente tarea. Por eso uso documentación viva: instrucciones locales, contratos, criterios de validación, mapas de repositorios, guías de dominio y notas de operación.

Esa documentación cumple varias funciones:

• reduce la necesidad de explicar lo mismo en cada sesión;
• convierte decisiones tácitas en reglas explícitas;
• permite que un agente nuevo entienda el estado vigente;
• obliga a diferenciar lo contractual de lo provisional;
• facilita detectar cuando un cambio de código no ha actualizado su documentación;
• evita que cada agente improvise su propio camino.

En la práctica, la documentación es una forma de management.

No documenta solo lo que existe. Dirige cómo debe trabajarse.

Y eso cambia mucho la calidad de la IA. Un agente sin memoria documental tiende a resolver localmente. Un agente con instrucciones, contratos y restricciones puede trabajar con más continuidad.

---

La tabla de mando: qué delego y qué no

Delegar no significa desaparecer.

Hay tareas que encajan muy bien con agentes:

• leer documentación y localizar contratos;
• comparar consistencia entre archivos;
• ejecutar pruebas;
• revisar internacionalización;
• detectar hardcodes o desalineaciones;
• generar borradores de specs;
• auditar riesgos de un cambio;
• hacer revisión visual o responsive;
• resumir logs o evidencias runtime en carriles readonly.

Pero hay decisiones que mantengo como responsabilidad de dirección:

• aceptar un trade-off de producto;
• cambiar una regla de negocio;
• modificar monetización;
• tocar dependencias;
• decidir un despliegue;
• publicar o no una explicación pública;
• convertir una hipótesis en desarrollo real;
• asumir un riesgo residual.

Este punto me parece fundamental.

La IA amplía capacidad, pero no elimina responsabilidad. Un sistema de agentes bien diseñado no sirve para abdicar decisiones. Sirve para llegar a esas decisiones con más contexto, más contraste y menos trabajo manual repetitivo.

---

Qué hace sofisticado al flujo

La sofisticación no está en tener muchos agentes. Tener muchos agentes mal gobernados solo crea ruido.

Lo sofisticado es que el sistema tenga:

• roles separados;
• criterios de entrada y salida;
• documentación que gobierna el comportamiento;
• carriles readonly para observar sin tocar;
• agentes mecánicos para tareas repetibles;
• especialistas para dominios con reglas propias;
• QA independiente;
• doble check final;
• confirmación mía en acciones sensibles;
• capacidad de volver del QA al worker sin cerrar en falso.

Esto se parece más a diseñar una organización que a escribir prompts.

Y esa es la parte que creo que muchas empresas van a tener que aprender: no basta con contratar una herramienta de IA ni con formar a la gente en prompts. Hay que rediseñar cómo se define, reparte, valida y cierra el trabajo.

---

Aprendizaje transferible

No hace falta empezar con decenas de agentes ni con una infraestructura compleja.

Una organización puede empezar con algo mucho más pequeño:

• un agente coordinador con instrucciones claras;
• un agente worker para implementación;
• un agente QA que no toque el mismo código salvo necesidad explícita;
• una checklist de cierre;
• una documentación mínima de contratos y decisiones;
• una regla estricta para acciones sensibles.

Eso ya cambia el comportamiento.

En mi caso, me ayuda dejar de pensar en la IA como una persona rápida que responde a todo. Prefiero dividir el trabajo en tareas con dueño: leer, implementar, revisar, documentar, contrastar y cerrar.

Cuando cada tarea tiene un rol y un criterio de cierre, el resultado deja de depender tanto de la conversación del momento.

---

Una conclusión práctica

Cuando hablo de mi equipo IA, hablo de una forma de ordenar mi trabajo diario. No de una estructura ideal ni de una presentación bonita sobre agentes. Hablo de cómo evito que la IA se convierta en una cadena de respuestas sueltas sin continuidad.

Enolisa me obliga a trabajar con restricciones reales: usuarios, costes, privacidad, stores, backend, documentación, QA, analítica y evolución continua. En ese contexto, si la IA no tiene contexto, límites y revisión, puede acabar generando más trabajo del que ahorra.

Por eso la organizo como un equipo:

• alguien dirige;
• alguien implementa;
• alguien valida;
• alguien observa sin tocar;
• alguien documenta;
• yo reviso el resultado y acepto o no el cierre;
• y las decisiones sensibles siguen bajo mi responsabilidad.

Lo que me interesa de este enfoque no es que suene avanzado. Me interesa porque me permite trabajar con más orden: separar implementación de revisión, dejar rastro de las decisiones y no confundir velocidad con cierre.

Para mí, ahí está el aprendizaje. La IA ayuda más cuando tiene una forma de trabajo alrededor. No sustituye mi criterio: me obliga a hacerlo más explícito desde el inicio hasta el final.