Agent Teams.
Un equipo técnico real, scripteado.
AgentsRoom Teams encadena tus agentes IA de código como un equipo de ingeniería real. Un Fullstack Dev entrega la feature, un QA Engineer la valida, un PM la firma. Cada rol está scripteado, el workflow es visual, y cada handoff lleva el resumen de feature, el diff, los riesgos y las pistas de testing. Se acabó el agente único que lo hace todo mal.
Construye el equipo dev IA de tus sueños en un canvas visual, igual que un workflow n8n. Edges condicionales, bucles de feedback, retries, guard de max-cycles. Guárdalo una vez, lánzalo en cada ticket, y mira a tus agentes pasarse el testigo como seniors.
AgentsRoom Teams: editor visual de workflow multi-agente, handoff automático entre agentes Claude Code, bucle de feedback Dev a QA, comunicación inter-agente vía MCP.
Agent Teams es la respuesta de AgentsRoom a una verdad brutal sobre los agentes IA de código: un agente único que intenta hacerlo todo termina haciéndolo todo mal. El agente Fullstack que codea, testea, hace review, despliega y escribe la spec al mismo tiempo olvida la mitad de sus instrucciones por el camino. La respuesta correcta, la que usa todo equipo de software serio del mundo, es dividir el trabajo en roles. Un developer codea. Un QA engineer valida. Un product manager firma. Un security reviewer audita. Cada rol tiene su propio contexto, su propio focus, su propio tooling.
Esto es exactamente lo que Agent Teams trae a AgentsRoom. Pones nodes en un canvas infinito (basado en React Flow, el mismo motor que n8n, Make, Retool y Pipedream), cada node es un agente Claude Code, Codex, OpenCode, Gemini CLI o Aider asignado a un rol específico, y los conectas. Lanza el equipo en un ticket de tu backlog, o engánchalo a cualquier nuevo spawn de agente. AgentsRoom orquesta la cadena: spawn del primer agente, espera del handoff, resume del trabajo, spawn del siguiente agente con ese resume como contexto de entrada, repite hasta que el equipo llegue al node final.
Otras herramientas intentan hacer esto con un super-agente único y prompts ingeniosos. Lo probamos, no funciona más allá de tres pasos. Los roles derivan, el contexto se pierde, el agente olvida lo que tenía que verificar. Agent Teams trata a los agentes como verdaderos compañeros de equipo: cada uno recibe una sesión limpia, un system prompt enfocado, un payload de handoff estructurado, y un scratchpad compartido para hablar con los demás. Este es el workflow de equipo dev IA que realmente quieres.
Editor AgentsRoom Teams: pon nodes para cada rol, conéctalos, añade condiciones, guarda el equipo, lánzalo en cualquier ticket.
Orquestación multi-agente que escala de verdad
Cada node del canvas es un agente. Eliges su rol (Fullstack, Frontend, Backend, QA, Security, DevOps, PM, Architect, Mobile, Marketing, Git, SEO, Localization, o cualquier rol custom que hayas creado), su modelo (Opus, Sonnet, Haiku, GPT-5, o3, Gemini Pro, etc.), su modo de handoff (auto vía Stop hook, o manual vía botón) y unas líneas de instrucciones específicas del paso. Eso es todo. Sin ceremonia de prompt engineering, sin archivo YAML que escribir.
Los edges conectan los nodes. Un edge simple significa: cuando el primer agente termina su paso, pasa al siguiente. Un edge condicional lleva un check de flag, por ejemplo qaPassed equals true. El agente QA pone ese flag en su payload de handoff, el runner elige el edge que coincide. Así es como construyes bucles de feedback: QA termina, qaPassed equals false, el edge devuelve a Dev con las pistas de testing y los riesgos. Dev arregla, hace handoff de nuevo. Loop hasta que el QA pase o hasta que el guard de max-cycles dispare.
La comunicación inter-agente es robusta por diseño. AgentsRoom incluye un servidor MCP dedicado (agentsroom-team) que da a cada agente del run un set de tools: leer el contexto del equipo, leer el scratchpad NOTES.md compartido, postear una nota para los compañeros, enviar una pregunta a otro rol, leer la inbox, leer la timeline, leer el diff git contra el baseline del run, y completar el paso con un payload estructurado. Estos tools se reinyectan en la sesión Claude en cada turn, así que sobreviven a la compactación de contexto. Incluso después de un /compact o un /clear, el agente sigue viendo sus tools de equipo.
Encima de eso, un hook UserPromptSubmit recuerda al agente cualquier nota nueva de los compañeros antes de cada mensaje de usuario. Un archivo NOTES.md en el workspace es append-only y sobrevive a crashes, reinicios y reboots de Mac. Un schema de payload de handoff validado del lado servidor evita que los agentes hagan handoffs vacíos o basura. Esta es la parte que la mayoría de las demos multi-agente saltan en silencio, y la razón por la que la mayoría se desmoronan en el cycle 3.
Todo lo que necesitas para llevar un equipo de ingeniería IA
Workflow visual, handoff real, bucles de feedback reales, comunicación inter-agente real. Construido para que entregues una feature en un ping de Slack en lugar de cincuenta.
Canvas de workflow visual
Canvas zoomable infinito impulsado por React Flow, el mismo motor detrás de n8n, Retool, Pipedream y Make. Pon nodes, conéctalos, guarda el equipo. Sin código, sin YAML.
14 roles de agente integrados
Fullstack, Frontend, Backend, DevOps, QA, Security, PM, Architect, Mobile, Marketing, Git Expert, SEO, i18n. Más cualquier rol custom que ya hayas guardado en tu proyecto.
Modelo y prompt por node
Cada node elige su provider, su modelo y sus instrucciones de paso. Usa Opus para Architect, Haiku para QA, Codex para el backend pesado, Gemini para el frontend barato. Mix and match.
Handoff automático
Cuando un agente llama team_complete_step, AgentsRoom construye el payload de handoff (resumen de feature, archivos cambiados, riesgos, pistas de testing, flags) y spawnea el siguiente node con ese payload como contexto inicial.
Opción de handoff manual
¿Prefieres validar cada paso? Pasa el node a modo manual. El agente espera, tú haces clic en 'Hand off' cuando estés contento con el resultado. Lo mejor de ambos mundos.
Edges condicionales
Cada edge puede llevar un check de flag (por ejemplo qaPassed equals true). Construye branches: si QA pasa, ve al PM, si no, vuelve en bucle a Dev. Lógica de workflow real, sin scripting.
Bucles de feedback
Dev a QA a Dev a QA. Cuando QA devuelve el ticket, el agente Dev original es reutilizado con memoria completa del cycle anterior, así que arregla la regresión de verdad en lugar de empezar de cero.
Guard de max-cycles
Tope configurable (3 por defecto). Evita bucles infinitos QA-rechaza-Dev. Cuando se alcanza el tope, el run pausa en awaiting-finalization y tú decides qué hacer.
Scratchpad NOTES.md compartido
Cada agente del run lee y escribe en un archivo markdown del workspace. Sobrevive a la compactación, al crash, al reinicio. La fuente única de verdad para el razonamiento del equipo.
Inbox de rol a rol
¿Necesitas que QA haga una pregunta al Architect en mitad del run? team_ask postea un mensaje en la inbox del rol. El siguiente agente de ese rol lo lee y responde. Chat real entre agentes.
Comm inter-agente vía MCP
Todos los tools del equipo se exponen vía servidor MCP. Los tools sobreviven a la compactación de contexto Claude (Anthropic los reenvía en cada turn). Resistentes a /clear, /compact y bucles largos.
Resumen de handoff con Haiku
Si un agente no escribe su propio resumen de feature, una pequeña llamada a Haiku genera uno a partir del diff git. Barato, rápido, y el siguiente agente siempre aterriza con contexto.
Propagación Browser MCP
Un node de equipo con verifyInBrowser cambia su agente a modo browser-access automáticamente. El node QA aterriza con todos los tools de browser (navigate, click, type, screenshot, get logs).
Agentes efímeros por run
Cada run de equipo spawnea agentes nuevos y los destruye al dismiss. Tu lista de agentes del proyecto se mantiene limpia. El equipo es el workflow, los agentes son el runtime.
Equipos globales y de proyecto
Guarda equipos reutilizables en tu biblioteca global (~/.agentsroom/teams) o engánchalos a un proyecto específico (commiteados con la room). Mismo editor, scope diferente.
Templates de equipo incluidos
Tres templates iniciales vienen con la app: Dev a QA, Dev a QA con bucle de feedback, y Dev a Security a QA. Duplica, edita, lanza. Empieza en 30 segundos.
UI de timeline del run
Cada handoff aparece como una tarjeta en la timeline del run: qué rol acaba de terminar, qué dice el resumen, qué archivos cambiaron, qué flags se pusieron. Auditable, replayable.
Lanza en cualquier ticket de backlog
Pon un ticket en un equipo y la cadena arranca en ese ticket. El primer agente lee el título y el body del ticket, el resto del equipo lo retoma desde ahí.
14 roles especializados, listos para conectar
Cada rol tiene su propio system prompt, áreas de focus y tareas de ejemplo. Mézclalos en el canvas. Añade tus propios roles custom en cualquier momento.
Por qué un equipo real le gana a un super-agente
La orquestación multi-agente suena a buzzword. Aquí está la diferencia práctica, en una feature que entregarías de verdad.
Escenario: añadir un flow de checkout Stripe a un sitio de e-commerce
Super-agente solo
- • Lee el ticket. Escribe 600 líneas entre la API, el formulario React, el webhook, la migración y los tests.
- • Olvida la idempotency key en el webhook. Olvida testear el camino de fallo. Olvida la variable de entorno de staging.
- • Dice 'Done'. Pasas dos horas cazando bugs en producción.
Agent Team (Dev a Security a QA)
- • Agente Fullstack entrega la implementación, commit, hace handoff con un resumen y una lista de riesgos marcando el cambio de auth.
- • Agente Security lee el diff, audita la verificación de firma del webhook, escribe pistas de testing para QA en el payload de handoff.
- • Agente QA ejecuta las pistas de testing en el navegador integrado, da con un bug de idempotencia, pone qaPassed equals false, devuelve el ticket a Dev con la repro exacta.
- • Dev arregla, hace handoff de nuevo. QA pasa. El PM finaliza. El run va a done.
Mismo ticket, mismos modelos, mismo proyecto. Forma de trabajo distinta. El enfoque de equipo atrapa lo que el agente solo se pierde, porque cada rol tiene un brief enfocado y un handoff estructurado.
Cómo funciona un run de equipo
Abre la pestaña Teams
En la vista de proyecto, la pestaña Teams lista tres templates iniciales (Dev a QA, Dev a QA con bucle de feedback, Dev a Security a QA) más cualquier equipo que ya hayas guardado. Duplica un template o haz clic en 'Nuevo equipo'.
Construye el workflow en el canvas
Pon nodes de agente en el canvas React Flow. Para cada node, elige el rol (Fullstack, QA, Security, PM, etc.), el provider, el modelo, y unas líneas de instrucciones de paso. Conéctalos con edges. Añade condiciones a los edges si necesitas branching.
Dev → QA → PMConfigura el modo de handoff por node
Handoff auto: el agente llama team_complete_step cuando su trabajo está hecho, el runner toma el relevo. Handoff manual: el agente espera a que hagas clic en 'Hand off'. Mezcla ambos según necesidad.
Lanza el equipo
Desde un ticket de backlog, haz clic en 'Run with team'. Desde un slot de agente vacío, haz clic en 'Create as team'. El primer node spawnea como agente efímero en el workspace del proyecto.
Mira cómo ocurre el handoff
Cuando el agente N termina, AgentsRoom construye el payload de handoff (resumen de feature vía agente o vía Haiku, diff git, riesgos, pistas de testing, flags), añade una nota a NOTES.md, elige el edge saliente correcto en función de los flags, y spawnea el agente N+1 con ese payload como contexto de entrada.
Loop, fin, finalización
Los bucles de feedback re-entran en el agente original (memoria completa preservada). El node final dispara awaiting-finalization. Haces clic en 'Finish run'. Dismiss del banner para destruir los agentes y liberar los PTYs.
Comunicación inter-agente que sobrevive a todo
El detalle que la mayoría de las demos multi-agente se saltan. Aquí está lo que hace que Agent Teams aguante en runs largos y muchos cycles.
Los agentes Claude Code tienen una ventana de contexto y la compactan. El error clásico de los sistemas multi-agente es poner la coordinación de equipo solo en el system prompt. Después de dos cycles de /compact, el agente no tiene ni idea de que está en un equipo. AgentsRoom no hace eso.
Toda la coordinación de equipo vive en tres sitios que sobreviven a la compactación. Primero, un servidor MCP (agentsroom-team) expone tools (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_ask, team_read_timeline, team_read_diff, team_complete_step). Los tools MCP los reenvía la CLI a Claude en cada turn, así que son inmunes a la compresión de contexto.
Segundo, un hook UserPromptSubmit corre antes de cada mensaje de usuario y prepende un pequeño recordatorio si hay notas nuevas o mensajes nuevos en la inbox de ese rol. Barato cuando no pasa nada, decisivo cuando sí.
Tercero, NOTES.md y state.json viven en disco en el workspace. El agente puede releerlos en cualquier momento con un Read simple o con team_read_notes. Sobreviven a crashes, reinicios, /clear, /compact y reboots de Mac. El system prompt nunca es la fuente de verdad, el disco y los tools MCP lo son.
Lo que la gente construye con Agent Teams
Pipeline Dev a QA
El clásico. Fullstack entrega la feature. QA la valida en el navegador integrado, ejecuta las pistas de testing, firma. Equipo de dos nodes, corre en cada ticket del backlog.
Dev a QA con bucle de feedback
Como arriba, pero con un edge condicional: qaPassed equals false devuelve el ticket a Dev con las pistas de testing. Máx 3 cycles. Atrapa regresiones antes de que lleguen a un reviewer humano.
Dev a Security a QA
Para features que tocan auth, pagos o PII. Agente Security hace review del diff, marca riesgos, escribe pistas de testing para QA. Usado por equipos que entregan fintech, healthtech y SaaS B2B.
PM a Architect a Dev
Workflow spec-first. El agente PM convierte el ticket en una spec estructurada. El Architect elige el enfoque. El Dev implementa. Tres roles, separación limpia, decisiones trazables.
Fan-out Frontend, Backend, DevOps
División secuencial para features full-stack. Frontend entrega la UI. Backend entrega la API. DevOps añade la config de infra. Cada rol trabaja en su área, hace handoff con un diff limpio.
Marketing a SEO a i18n
Sí, AgentsRoom Teams no es solo para código. Marketing escribe el copy de la landing. SEO inyecta los keywords. Localization traduce a 14 idiomas. Un equipo, un ticket, un ship.
Cómo se compara con otros enfoques multi-agente
La orquestación multi-agente es un buzzword saturado. Aquí está lo que de verdad entrega, y dónde encaja AgentsRoom Teams.
Anthropic Subagents (tool Task, .claude/agents) permiten que una sesión Claude única delegue a agentes helper especializados. Genial para delegación inline, pero la sesión padre sigue siendo el coordinador y un contexto único. AgentsRoom Teams está un nivel por encima: cada node de equipo es una sesión Claude top-level separada con su propia ventana, su propio estado, su propio scrollback. CrewAI, AutoGen y LangGraph son frameworks Python excelentes para flows multi-agente, pero viven fuera de tu IDE y no corren CLIs reales de Claude Code, Codex o Gemini end-to-end en tu repo local. n8n, Make, Pipedream y Retool entregan el mismo tipo de editor canvas que usamos, pero son plataformas de automatización generalistas, no construidas para agentes IA de código. AgentsRoom Teams es el editor de workflow multi-agente estilo canvas, pero conectado específicamente a tus agentes CLI, tu proyecto, tu git, tus terminales y tu navegador.
Si construyes sistemas agénticos en Python, sigue con CrewAI o LangGraph para pipelines de producción. Si entregas código con Claude Code, Codex CLI, OpenCode, Gemini CLI o Aider, Agent Teams es el workflow de equipo que corre donde de verdad codeas.
FAQ
¿En qué se diferencia esto de los subagents Claude Code (el tool Task, .claude/agents)?
Los subagents Claude son delegaciones inline desde una sesión Claude padre única. El padre decide cuándo llamar a un subagent, el subagent corre en una ventana de contexto aislada, devuelve un resultado, y el padre sigue. AgentsRoom Teams está un nivel por encima: cada node es una sesión Claude Code top-level con su propia terminal, su propio estado y su propio scrollback. Ves a cada agente correr en vivo en su propia pestaña, puedes hablar con cualquiera en cualquier momento, puedes pausar el equipo, cambiar el workflow y reanudar. No es un reemplazo de los subagents Claude, puedes usar ambos perfectamente. Un node de equipo puede usar subagents internamente.
¿Esto funciona solo con Claude Code?
Funciona con todos los providers soportados por AgentsRoom (Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider). Cada node de equipo elige su propio provider y modelo. Los tools de coordinación de equipo basados en MCP funcionan idénticamente en todos los providers porque están expuestos a través del Model Context Protocol estándar. Puedes correr un equipo con Codex en el node backend pesado y Haiku en el node QA si es lo que encaja con tu presupuesto y tu latencia.
¿Qué es un payload de handoff?
Un objeto estructurado que viaja de un agente al siguiente. Campos: featureSummary (una descripción corta de lo que se acaba de entregar), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (cualquier cosa por la que el siguiente agente debería preocuparse), testHints (prioridades para QA), flags (booleanos como qaPassed, usados por edges condicionales). El agente llama team_complete_step con este payload, el runner lo valida del lado servidor, el siguiente agente lo recibe como su contexto inicial.
¿Los agentes pueden ir y volver de verdad (Dev a QA a Dev)?
Sí. Cuando un node se vuelve a entrar (cycle mayor que 1), AgentsRoom no spawnea un agente nuevo. Reutiliza el agente original del cycle 1, escribe el nuevo payload de handoff directamente en su terminal existente, y el agente conserva toda su memoria de sesión Claude de los cycles previos. Esto es crítico: un agente Dev que ya sabe lo que QA marcó la vez anterior arregla el bug. Un agente Dev fresco sin memoria simplemente repetiría el mismo error.
¿Qué pasa si QA rechaza a Dev para siempre?
La config del equipo tiene un guard de max-cycles, por defecto 3. Cuando se alcanza el tope, el run pausa con estado 'blocked' y te espera. Puedes finalizar el run, hacer un handoff manual una vez más, o cancelarlo todo. Sin bucles infinitos, sin facturas sorpresa de la noche.
¿Todos los agentes del equipo comparten el mismo workspace git?
Sí. El equipo corre en un workspace único y una rama única (o un worktree si usas la feature Worktrees de AgentsRoom). Cada agente ve el trabajo del anterior a través de git. El payload de handoff incluye un diff git contra el baseline del run para que el siguiente agente sepa exactamente qué es nuevo.
¿Esto requiere una suscripción extra?
No. Teams es parte de AgentsRoom. Traes tus propias keys de provider (Claude, Codex, OpenCode, Gemini, Aider) y pagas solo por los tokens que usas, como con un agente único. Correr un equipo Dev a QA en un ticket pequeño normalmente cuesta lo mismo que correr un agente Fullstack único, porque Haiku/Sonnet en el paso de QA es barato.
¿Dónde se guardan los equipos? ¿Se commitean a git?
Los equipos con scope de proyecto viven con la room, sincronizados a la nube y cacheados en {project}/.agentsroom/teams-cache.json (gitignored). Los equipos globales viven en ~/.agentsroom/teams/{teamId}.json en tu máquina, un archivo por equipo. Tú decides qué scope encaja con cada workflow.
¿Qué pasa si un agente crashea o la app reinicia en mitad del run?
El estado del run está persistido en disco en {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl). NOTES.md es append-only, cada escritura de estado es atómica. Los agentes pueden releerlo todo en cualquier momento con team_read_notes o team_get_context. La capa de orquestación se está endureciendo para replayar completamente un run interrumpido al reiniciar la app, pero la historia on-disk ya es crash-safe.
¿Puedo correr varios equipos en paralelo en distintos tickets?
Sí. Cada run de equipo es independiente y está identificado por su runId. Puedes tener un equipo Dev a QA corriendo en el ticket A, un equipo Dev a Security a QA en el ticket B y un equipo PM a Architect a Dev en el ticket C, todos en vivo en el mismo proyecto. Dentro de un run único, la ejecución es secuencial (un node activo a la vez) por predictibilidad.
Construye el equipo dev IA de tus sueños
Tres templates vienen con la app. Abre AgentsRoom, pon nodes, dibuja edges, lanza en cualquier ticket. Tu equipo de ingeniería IA está a un clic.
App complementaria: supervisa tus agentes en movimiento
Compatible con Claude, Codex, OpenCode, Gemini CLI y Aider
Envía bugs y peticiones directamente a tu backlog público.