¿Cuáles son las buenas prácticas para diseñar agentes de IA sin duplicar roles?
No hay un decálogo cerrado para crear agentes, pero sí una heurística simple: partir del flujo de trabajo humano real y no inventar capas que no existen. Cómo evitar la duplicación entre agentes, reglas y skills.
La pregunta real
A medida que un equipo empieza a definir agentes especializados (uno de backend, uno de revisión, uno de QA...), aparece la duda de cuáles son en realidad las buenas prácticas para crear un agente: cuántos hacen falta, qué debe vivir dentro del propio agente frente a lo que debería ser una skill compartida, y cómo evitar acabar con una jerarquía de agentes redundante que nadie sabe ya por qué existe.
No existe un decálogo cerrado y universal para esto — el ecosistema todavía cambia demasiado rápido como para fijar reglas absolutas — pero sí hay una heurística práctica que funciona bien en la mayoría de los casos.
La regla central: no duplicar nada
La heurística más útil es no duplicar responsabilidades entre agentes, reglas y skills, y limitar cada agente estrictamente a lo que realmente hace falta. Es tentador crear un agente por cada concepto que suena bien (uno de "arquitectura", uno de "seguridad", uno de "documentación"), pero si dos agentes acaban necesitando la misma lógica para funcionar, esa lógica probablemente debería vivir en una skill compartida, referenciada por ambos, en lugar de copiarse o reimplementarse en cada agente por separado.
Igual de importante es no inventar capas o roles que no existan ya en el flujo real de trabajo del equipo. Crear un agente de QA tiene sentido si el equipo ya tiene un proceso real de verificación separado del desarrollo — pero si ese proceso no existe hoy en el equipo humano, forzar un agente de QA no soluciona nada: solo añade una capa artificial de interacción entre agentes sin un proceso real detrás que la sustente.
Partir del flujo sin IA como plantilla
El punto de partida más fiable es imaginar cómo funcionaría el equipo si no existiera ningún sistema de IA ni orquestador de por medio: qué roles humanos intervienen realmente en llevar una necesidad de negocio hasta producción (por ejemplo: quien recoge el requisito, quien lo diseña técnicamente, quien lo implementa, quien lo revisa). Cada uno de esos roles humanos reales, y solo esos, es un buen candidato a convertirse en un agente independiente. Esto evita tanto la duplicación como la inflación artificial de agentes, porque el límite lo pone el propio flujo de trabajo del equipo, no una lista genérica de "buenas prácticas" copiada de otro contexto.
Cómo evitar bucles entre agentes
Con varios agentes especializados en juego aparece un riesgo adicional: las interacciones excesivas entre ellos, donde un agente delega en otro que a su vez delega de vuelta, generando bucles o intercambios que consumen tokens sin avanzar el trabajo real. Diseñar cada agente como el equivalente a un rol humano ayuda también aquí: un rol humano rara vez necesita "ida y vuelta" constante con otro rol para completar su parte del trabajo, y un agente bien acotado debería poder decir lo mismo.
En proyectos pequeños o con un solo desarrollador, tiene sentido empezar con muy pocos agentes —a veces uno solo— e ir separando roles únicamente cuando aparece una necesidad real de especialización, no de forma anticipada "por si acaso".
Resumen rápido
- No dupliques lógica entre agentes, reglas y skills: si dos agentes necesitan lo mismo, esa lógica va en una skill compartida.
- No inventes agentes para roles que no existen ya en el flujo de trabajo real del equipo humano — cada agente debería reflejar un rol que ya existía.
- Evita bucles: si dos agentes necesitan un ida y vuelta constante, probablemente su alcance está mal definido, no falta un tercer agente que arbitre.
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.