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.
Monta tu equipo de desarrollo IA ideal en un canvas visual, como un workflow de n8n. Conexiones condicionales, bucles de feedback, ramas de revision paralelas, puertas de calidad verificadas por la maquina, tope de ciclos. Guardalo una vez, lanzalo 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe o Kimi Code 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, Antigravity 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, Antigravity 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.
Puertas de calidad verificadas por la maquina
Fija un comando de control en un nodo (npm test, un lint, un build). El runner lo ejecuta cuando el agente se declara terminado: codigo de salida 0 pone el flag de enrutado en true, cualquier otro en false. El resultado medido reemplaza siempre lo que el agente declare.
Ramas de revision paralelas
Dibuja dos conexiones sin condicion desde un nodo y ambos destinos corren a la vez: QA y Seguridad revisan el mismo diff lado a lado, y un nodo de union fusiona sus informes. Una sola rama en rojo mantiene la puerta cerrada.
Skills fijadas por paso
Adjunta entradas de tu Skills Library a un nodo. El agente las carga antes de empezar el paso: tu checklist de revision o tu runbook de despliegue se aplica en cada ejecucion, no solo cuando el agente se acuerda.
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.
Las ejecuciones sobreviven a los reinicios
Cierra la app a mitad de ejecucion, vuelve a abrirla: la ejecucion retoma el paso donde estaba. Estado, notas y timeline viven en disco; el orquestador retoma el trabajo en vez de dejar un zombi.
Biblioteca de equipos en tu cuenta
Los equipos globales se sincronizan con tu cuenta y te siguen de maquina en maquina; los equipos de proyecto viajan con la room. Ambos guardan cache offline, y los cambios hechos sin conexion se reproducen al reconectar.
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.
Cuatro plantillas de equipo incluidas
Construir y verificar, Especificar construir verificar, Caza de bugs (reproducir, corregir, demostrar) y Escudo de release con QA y Seguridad en paralelo. Duplica, edita, lanza. Listo 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.
La confianza se mide, no se declara
Un agente que corrige su propio examen acabara aprobandose solo. Agent Teams mantiene el pipeline honesto con dos mecanismos.
El codigo de salida decide
Cualquier nodo puede declarar un comando de control: npm test, un lint, un build, cualquier cosa que devuelva un codigo de salida. Cuando el agente llama a team_complete_step, el runner ejecuta el comando en el workspace y escribe el resultado medido en el flag de enrutado. Verde: la ejecucion avanza. Rojo: la salida de error aterriza al principio del contexto del siguiente agente, con el stderr real. Un agente que asegura que todos los tests pasan mientras la suite esta en rojo es enrutado por la suite en rojo, no por su afirmacion.
Cuatro ojos, al mismo tiempo
Divide un nodo en ramas paralelas: QA recorre los flujos mientras Seguridad audita el diff, cada uno en su propio agente, ciego a las conclusiones del otro. Un nodo de union espera a todas las ramas, fusiona resumenes, riesgos y flags, y enruta sobre el resultado combinado. Los conflictos booleanos se resuelven a false por diseno: un solo revisor en fallo basta para retener la release.
Dev → [ QA ∥ Security ] → Release gateCómo funciona un run de equipo
Abre la pestaña Teams
En la vista de proyecto, la pestana Teams lista cuatro plantillas incluidas (Construir y verificar, Especificar construir verificar, Caza de bugs, Escudo de release) mas los equipos que ya hayas guardado. Duplica una plantilla o pulsa 'New team'.
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 via el agente o via Haiku, diff de git, riesgos, pistas de prueba, flags), anade una nota a NOTES.md, elige la conexion de salida correcta segun los flags y pasa el relevo al agente N+1 con ese payload como contexto de entrada. Si el nodo declara un comando de control, el runner lo ejecuta primero: el codigo de salida medido, no la afirmacion del agente, fija el flag de enrutado.
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.
Escudo de release: QA y Seguridad en paralelo
Un nodo dev se divide en QA y Seguridad corriendo lado a lado, y una puerta de release fusiona ambos informes. Incluido con la app como plantilla. Todo el escudo vuelve al Dev si cualquiera de las ramas reporta un problema.
Caza de bugs: reproducir antes de corregir
Un agente QA reproduce el bug y anota los pasos exactos. Un dev corrige la causa raiz. Un segundo QA repite los mismos pasos para demostrar el arreglo. Se acabo el 'en mi maquina funciona'.
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 Antigravity 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe o Kimi Code, 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, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code). 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, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code) 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 de proyecto viven con la room, sincronizados con tu cuenta y cacheados en {project}/.agentsroom/teams-cache.json (gitignored). Los equipos globales tambien se sincronizan con tu cuenta: tu biblioteca te sigue de maquina en maquina, con ~/.agentsroom/teams/ como cache offline. Las plantillas incluidas se quedan en local: cada maquina las instala en su propio idioma.
¿Qué pasa si un agente crashea o la app reinicia en mitad del run?
El estado de la ejecucion se persiste en disco en {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), con escrituras atomicas y notas append-only. Una ejecucion 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 ejecucion cuyo equipo fue borrado se cierra automaticamente en vez de quedarse ahi para siempre.
¿Puedo correr varios equipos en paralelo en distintos tickets?
Si. Cada ejecucion es independiente, identificada por su runId. Puedes tener tres equipos distintos vivos en tres tickets del mismo proyecto. Dentro de una ejecucion, 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 union determinista.
De verdad pueden correr dos agentes a la vez?
Si. Dibuja dos conexiones sin condicion 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 union comun, que el editor valida antes de dejarte lanzar. Cuando todas las ramas han terminado, la union recibe un payload fusionado: resumenes etiquetados por rol, riesgos y pistas de prueba deduplicados, y flags fusionados con una regla fail-safe (un conflicto booleano se resuelve a false).
Como funcionan exactamente las puertas de calidad?
Escribes un comando de shell en el nodo, por ejemplo npm test, y opcionalmente un nombre de flag (checkPassed por defecto). Cuando el agente senala el fin de su paso, AgentsRoom ejecuta el comando en el workspace con un tope de cinco minutos. Codigo de salida 0 escribe true en el flag, cualquier otro escribe false, sobrescribiendo lo que el agente haya declarado sobre si mismo. Si falla, los ultimos kilobytes de salida viajan al siguiente agente: la vuelta atras aterriza con el stack trace real, y el resultado se ve en la timeline de la ejecucion.
Puede un paso cargar mis procedimientos de la Skills Library?
Si. Cada nodo puede fijar skills de tu Skills Library, de proyecto o globales. El agente recibe la instruccion de cargarlas antes de empezar el paso: una checklist de revision, un runbook de despliegue o un procedimiento de pruebas se aplica en cada ejecucion, en vez de depender de la memoria del agente.
Construye el equipo dev IA de tus sueños
Cuatro plantillas vienen con la app. Abre AgentsRoom, coloca nodos, dibuja conexiones, lanza en cualquier ticket. Tu equipo de ingenieria IA esta a un clic.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Un vistazo a AgentsRoom en acción.