Cuando se piensa en un flujo de trabajo con agentes de IA, casi todos imaginan un agente, una tarea larga y una espera por el resultado. Eso funciona para trabajos pequeños. En algo grande, como «mover los pagos a un proveedor nuevo», un solo agente investiga, planifica e implementa todo a la vez: el contexto se hincha, nunca ves un plan y los errores salen a la luz solo cuando el código ya está escrito.
Este artículo muestra tres formas en que AgentVera reparte ese trabajo entre varios agentes: un equipo con manager y roles, un equipo paralelo que ejecuta partes independientes a la vez y flows que pasan la salida de un agente al siguiente.
¿Por qué repartir un flujo de trabajo con agentes de IA?
Los problemas de una sesión con un solo agente:
- El contexto crece. Cada archivo leído durante la investigación se queda en el contexto durante la implementación.
- El plan es invisible. El agente decide qué hacer y se pone directamente a programar.
- Los errores aparecen tarde. Una suposición equivocada solo sale a la luz cuando fallan los tests.
Varios agentes con trabajos claros lo solucionan. Un investigador no escribe código, un planificador solo escribe el plan, un desarrollador lo implementa y un revisor lo comprueba. Cada uno trabaja con su propio contexto pequeño.
Opción 1: un equipo con manager y roles
La vista de equipo convierte los agentes abiertos en tu espacio de trabajo en un equipo. En la ventana Team structure los colocas en un organigrama: uno pasa a ser el manager, los demás reciben un rol, instrucciones, alguien a quien reportar y alguien a quien pasar su trabajo. Un equipo admite hasta 24 agentes.
No hace falta construirlo desde cero. Los roles predefinidos rellenan un investigador, planificador, desarrollador, revisor, tester y más; los equipos predefinidos, como el software team (tech lead, planificador, desarrollador, revisor y tester), abren por ti los agentes que necesitan. El equipo y cada rol pueden llevar sus propios servidores MCP, así que el tester arranca con Playwright sin que lo configures agente por agente.
Nada empieza cuando el equipo está construido. Escribes el trabajo en el cuadro de abajo y eliges Give to the team. Va al manager, que lo divide, lo reparte y comprueba los resultados. Los agentes lo resuelven mediante el chat de agentes y una lista de tareas compartida.
Mientras se ejecuta, la vista de equipo muestra quién trabaja en qué, los mensajes que viajan entre agentes y en qué punto está cada tarea. Las solicitudes de permiso llegan a la barra de atención sobre el organigrama, donde las apruebas o rechazas en el sitio. Status report le pide al manager un resumen breve; Interrupt all detiene a todos.
Esto encaja con trabajos en los que los agentes necesitan hablar entre sí: un planificador que le hace una pregunta de seguimiento al investigador, un revisor que devuelve un cambio al desarrollador.
Opción 2: un equipo paralelo que termina en un PR
Algunos trabajos se dividen en partes independientes: la API, la interfaz y la migración de una funcionalidad nueva, por ejemplo. Un equipo paralelo las ejecuta a la vez.
Un agente inicia el equipo por su cuenta cuando un cambio grande se divide así. Escribe las partes, o le das solo el objetivo y dejas que Claude Sonnet lea el repositorio y las planifique. Después:
- Cada parte va a su propio agente en su propio worktree y rama, así que los agentes nunca tocan los archivos de los demás. Por defecto se ejecutan 3 a la vez, como máximo 6.
- Un agente termina con el marcador
[[TESLİM]]cuando acaba, o[[YARDIM]]cuando se atasca. Una parte atascada te espera: acepta lo que hizo, déjala continuar u omítela. - Las partes terminadas se fusionan en una rama de integración y el comando de tests del proyecto se ejecuta como comprobación final. Si una fusión tiene conflictos o la comprobación falla, interviene un agente de integración.
- Abres un único pull request, o pones la rama en la cola de fusión.
Esto encaja con cambios grandes cuyas partes no necesitan hablar entre sí, solo encajar al final.
Opción 3: flows que pasan el trabajo
Cuando quieres una cadena fija, constrúyela en flows. La secuencia clásica de investigar, planificar y construir queda así:
| Paso | Agente | Qué recibe | Regla |
|---|---|---|---|
| Investigar | Investigador | El objetivo | Sin código; informar del estado actual y las opciones |
| Planificar | Planificador | La última respuesta del investigador | Objetivo, fuera de alcance, archivos, pasos, estrategia de tests, criterios de aceptación |
| Aprobación | Tú | El plan | Nodo Human approval |
| Construir | Constructor | El plan aprobado | Implementar el plan, ejecutar los tests |
Cuando un agente termina su turno, su última respuesta se inserta en la plantilla de mensaje de la conexión ({{output}}) y se envía al siguiente agente. Si el siguiente agente está ocupado, el flow espera a que termine su turno. Los nodos que hacen segura la cadena:
- Condition: avanza solo cuando la respuesta contiene una frase o coincide con una regex, para que una pregunta hecha a mitad de camino no dispare el siguiente paso.
- Transform: envía solo el último bloque de código o las primeras N líneas.
- Human approval: se detiene hasta que apruebes, desde la app o desde Telegram.
- Wait y Notify: deja tiempo entre pasos y recibe aviso de los importantes.
- Turn limit: pausa una conexión que entra en bucle.
El paso de aprobación es el que más importa
Elijas la opción que elijas, leer el plan antes de que se escriba código es el momento más valioso. Un plan equivocado se arregla en cinco minutos ahí y en horas cuando ya existe código. Los problemas que más se detectan:
- Un módulo que debería quedar fuera de alcance y se cuela en el plan.
- Tests existentes que faltan en la estrategia de tests.
- El orden de los pasos, como la interfaz primero y después la implementación.
En un equipo, pide al manager que te envíe el plan antes de repartir el trabajo. En un flow, pon un nodo Human approval antes del constructor.
Cómo escribir un buen objetivo
La primera entrada es el objetivo que escribes. Un buen objetivo:
- Describe el resultado: «Mover el proveedor de pagos de X a Y sin cambiar el contrato actual de la API.»
- Fija los límites: «No toques el módulo de facturación.»
- Define el éxito: «Los tests de pagos existentes deben pasar, y añade un test de integración para el nuevo proveedor.»
Un objetivo como «mejorar los pagos» empuja a todos los agentes a leer todo el código.
¿Cuál deberías usar?
- Un agente: un arreglo de un archivo, una errata o un pequeño cambio de estilo. Dividirlo lleva más tiempo que el propio trabajo.
- Vista de equipo: trabajo continuo en el que agentes con distintos roles necesitan hablar, preguntar y revisarse entre sí.
- Equipo paralelo: un cambio grande con partes independientes que debe terminar como una rama y un PR.
- Flows: una secuencia fija que ejecutas una y otra vez, con aprobaciones y condiciones entre medias.
Ejecutar trabajos largos mientras estás fuera
No tienes que estar sentado frente al ordenador mientras corre un trabajo largo:
- Notificaciones de Telegram: aprueba un paso de un flow desde el móvil y responde a una notificación para enviar texto a ese agente.
- App móvil de AgentVera: sigue el chat, la terminal y el diff de cada agente en iOS o Android y responde a sus solicitudes de permiso.
- Tareas programadas: envía un mensaje a un agente con un horario cron, por ejemplo para iniciar cada mañana la investigación de dependencias.
- Prevent sleep: el ajuste que mantiene el ordenador despierto mientras trabajan los agentes evita que los trabajos nocturnos se detengan.
Lista de comprobación
- ¿Describe el objetivo el resultado y los límites en un párrafo?
- ¿Tiene cada agente un trabajo claro?
- ¿Verás el plan antes de que se escriba código?
- ¿Se ejecutarán los tests antes de dar el trabajo por terminado?
- ¿Recibirás un aviso cuando termine?
Para terminar
Repartir un flujo de trabajo con agentes de IA entre varios agentes los hace más predecibles en trabajos grandes: cada contexto se mantiene pequeño, el plan es visible y los errores salen pronto. AgentVera te da tres formas de hacerlo, desde un equipo en directo hasta una ejecución paralela que termina en un PR.
Empieza con el plan gratuito y consulta notificaciones y aprobaciones para gestionar las aprobaciones en remoto.