Agent Teams.
Un equipo técnico real, scripteado.

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.

Funciona con los 14 CLI de agente que AgentsRoom soporta (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor y 10 más). 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.

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.

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.

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.

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.

No. Teams es parte de AgentsRoom. Traes tus propias keys de provider (Claude, Codex, GitHub Copilot CLI, Cursor y otros 10 CLI de agente) 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.

Los equipos de proyecto viven con la room, sincronizados con tu cuenta y cacheados en {project}/.agentsroom/teams-cache.json (gitignored). Los equipos globales también se sincronizan con tu cuenta: tu biblioteca te sigue de máquina en máquina, con ~/.agentsroom/teams/ como caché offline. Las plantillas incluidas se quedan en local: cada máquina las instala en su propio idioma.

El estado de la ejecución se persiste en disco en {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), con escrituras atómicas y notas append-only. Una ejecución interrumpida se reanuda al reiniciar la app: el orquestador reentra en el paso activo, reabre el terminal y el agente recupera su contexto desde las notas y las herramientas de equipo. Una ejecución cuyo equipo fue borrado se cierra automáticamente en vez de quedarse ahí para siempre.

Sí. Cada ejecución es independiente, identificada por su runId. Puedes tener tres equipos distintos vivos en tres tickets del mismo proyecto. Dentro de una ejecución, el flujo sigue tu grafo: secuencial por defecto, paralelo donde dibujes ramas paralelas (por ejemplo QA y Seguridad revisando a la vez), siempre con una unión determinista.

Sí. Dibuja dos conexiones sin condición desde un nodo y ambos destinos corren como ramas paralelas, cada uno en su propio agente y terminal. Las ramas tienen un nodo de profundidad y deben converger en un nodo de unión común, que el editor valida antes de dejarte lanzar. Cuando todas las ramas han terminado, la unión recibe un payload fusionado: resúmenes etiquetados por rol, riesgos y pistas de prueba deduplicados, y flags fusionados con una regla fail-safe (un conflicto booleano se resuelve a false).

Escribes un comando de shell en el nodo, por ejemplo npm test, y opcionalmente un nombre de flag (checkPassed por defecto). Cuando el agente señala el fin de su paso, AgentsRoom ejecuta el comando en el workspace con un tope de cinco minutos. Código de salida 0 escribe true en el flag, cualquier otro escribe false, sobrescribiendo lo que el agente haya declarado sobre sí mismo. Si falla, los últimos kilobytes de salida viajan al siguiente agente: la vuelta atrás aterriza con el stack trace real, y el resultado se ve en la timeline de la ejecución.

Sí. Cada nodo puede fijar skills de tu Skills Library, de proyecto o globales. El agente recibe la instrucción de cargarlas antes de empezar el paso: una checklist de revisión, un runbook de despliegue o un procedimiento de pruebas se aplica en cada ejecución, en vez de depender de la memoria del agente.

Sí. El editor ejecuta una serie de comprobaciones del grafo y separa los errores bloqueantes de las advertencias. Los errores detienen la ejecución: falta un nodo Start o End, conexiones duplicadas, dos conexiones con las mismas condiciones, una conexión cuyas condiciones se contradicen, un fan-out inválido. Las advertencias no: un nombre de flag rodeado de espacios, una condición en una conexión que sale de Start, un nodo cuyas conexiones salientes son todas condicionales y donde la ejecución puede quedarse parada. Ambas se listan en un panel de comprobaciones y las conexiones culpables se recolorean en el lienzo, así que corriges el grafo antes de perder una ejecución por él.

No, y es deliberado. Mientras una ejecución sigue viva, la definición del equipo queda congelada frente a las escrituras que llegan por las herramientas MCP: nodos, conexiones, tope de ciclos, instrucciones de paso, skills, comando de control, rol, proveedor y modelo son de solo lectura para los agentes; una skill cargada por la ejecución tampoco se puede reescribir, y el bloqueo no se puede esquivar borrando y recreando el equipo. Un agente no debe reescribir la regla que lo gobierna. Tú sigues editándolo todo desde la interfaz en cualquier momento.

Sí. El compañero móvil puede arrancar un equipo en un proyecto, muestra un banner de ejecución con el progreso de cada paso y da acceso al terminal del agente que está trabajando en ese momento. La ejecución en sí sigue corriendo en tu escritorio, a través de las CLI reales, exactamente igual que si la hubieras lanzado allí.

Pregúntate en qué fallaría el run. Si fallaría por perder el hilo, elige relevo: una sola sesión interpreta todos los roles y nunca se reexplica una decisión a sí misma. Si fallaría por darse la razón a sí mismo, elige equipo: los roles corren como agentes separados, así que el que revisa el código no es el que lo escribió. El relevo es el modo por defecto porque es lo que ya hace todo equipo construido antes de que existiera el ajuste, no porque sea mejor.

No. Un compañero arranca la primera vez que hace falta, ya sea porque el grafo llega a su paso o porque otro agente le escribe, y a partir de ahí sigue vivo el resto del run. Así, un equipo de cuatro roles no quema cuatro sesiones para responder a una pregunta que solo afecta a dos, y un rol al que se escribe en el ciclo tres sigue siendo el mismo agente que respondió en el ciclo uno.

Solo lo que puede leer. Un compañero que entra a mitad del run tiene su propia sesión y ningún recuerdo del trabajo, que es exactamente por lo que su opinión vale algo. Se pone al día con las notas compartidas, la timeline del run y el diff de git desde que empezó el run, y todo eso lo lee con sus propias herramientas. Esa lectura es el coste del modo, y es la razón por la que el modo relevo sigue existiendo.

Sí, y es lo que viene por defecto. Con la conversación libre desactivada, un compañero solo puede escribir a los roles a los que apunta su nodo en el grafo, así que una puerta de calidad no se puede esquivar preguntándole a otro. Actívala cuando quieras un equipo de verdad: cualquiera escribe a cualquiera, en cualquier dirección y a varios a la vez. En ambos casos el grafo sigue arrancando el run y sigue terminándolo.