Delegación de agente :
tu agente dev delega el test
La delegación de agente permite a tu agente dev terminar una feature y pasar la validación a un agente QA separado. El dev sigue codificando con el modelo en que confías para los problemas duros. El agente QA corre el test en un modelo más barato. Ambos hablan vía los servidores MCP de AgentsRoom, así la delegación de agente funciona de punta a punta sin que copies nada.
Dejas de pagar precios Opus por clics de browser. Dejas de inflar el contexto de tu agente dev con screenshots y dumps DOM. La delegación de agente enruta cada tarea al modelo correcto al precio correcto.
En el panel Tests, el agente de test del proyecto pasa de Sonnet a Claude Haiku, más barato. Un agente Claude Opus añade un botón Buy y luego delega el test en el navegador: un agente QA aparece debajo de él en Haiku, abre la tienda en el navegador integrado, hace clic en Buy y ve el carrito pasar a 1. El veredicto, aprobado, vuelve a la conversación del agente Opus.
Este es el problema que la delegación de agente resuelve. Corres un agente dev fuerte (Claude Opus, Codex). El agente entrega la feature en 10 minutos. Después pasa 8 minutos haciendo clic en un browser para verificarla. Mismo precio caro de tokens. Mismo modelo que pensaba en tu lógica de dominio, ahora leyendo labels de botones.
La delegación de agente arregla eso. Cuando la feature está lista, el agente dev llama una sola herramienta MCP, run_qa_test, con un escenario. AgentsRoom lanza un agente QA efímero en el modelo que elegiste para QA. El agente QA recibe el Browser MCP, drive la página, valida el resultado y devuelve un veredicto.
Eso es la delegación de agente, y ese es el único loop que esta página cubre. Un dev, un QA, un MCP. Misma idea que un ingeniero senior delegando tests de regresión a un junior : el senior sigue diseñando, el junior corre la checklist.
Delegación de agente visualizada : el agente dev padre (Codex) y el agente QA hijo (Claude) en la misma lista, con un handoff dev a QA claro.
Por qué la delegación de agente vale la pena
Primero, el dinero. Una pasada de test en Claude Opus y una pasada en Claude Haiku cuestan cantidades radicalmente diferentes. Mismo browser, mismos asserts, mismos screenshots. La delegación de agente deja que el modelo barato haga el trabajo barato. La gente que activó esto reporta una factura de tokens dividida por un factor real en los días pesados de QA, no por 5 a 10 por ciento.
Segundo, el contexto. Cuando un agente dev corre el test él mismo, cada screenshot, cada dump DOM, cada log de consola termina en la ventana de contexto del dev. Veinte minutos de clics son megabytes de ruido que el agente dev arrastra por el resto de la sesión. La delegación de agente aísla ese ruido dentro del agente QA efímero. El agente dev recibe un 'pass' o 'fail' limpio, nada más.
Tercero, el ángulo ecológico. Cada delegación de agente ahorra cómputo real. Correr Haiku donde corría Opus reduce a la mitad la huella energética de ese paso. Multiplica por todo el equipo y por cada loop de test al año, y la delegación de agente se vuelve una palanca no trivial sobre el lado carbono de tu stack.
Cuarto, la fiabilidad. Un agente dev que drive el browser él mismo tiende a desviarse. Dos screenshots después, ya olvidó qué intentaba validar. El agente QA en la delegación de agente tiene un solo trabajo y un solo prompt. Testea, reporta, muere. El loop es corto, predecible y fácil de debuggear.
El único flow que esta página cubre
Un agente dev. Un agente QA. Una llamada MCP. Delegación de agente, de punta a punta.
El agente dev entrega la feature
Tu agente dev (Claude Opus, Codex en razonamiento alto, cualquier modelo caro en que confíes) termina la implementación. Nuevo endpoint, nueva pantalla, nuevo flow. Código escrito, archivos guardados.
El agente dev llama run_qa_test
En vez de abrir el browser él mismo, el agente dev llama una sola herramienta MCP del servidor AgentsRoom Test Runner : run_qa_test, con un escenario en lenguaje natural. Esa es toda la superficie API de la delegación de agente.
AgentsRoom lanza el agente QA
AgentsRoom Test Runner lanza un agente QA efímero en el modelo más barato que configuraste (Claude Haiku, Codex mini, GPT-4 mini). El agente QA recibe las herramientas Browser MCP de AgentsRoom : navigate, click, type, screenshot, evaluate, get_logs, get_state.
El agente QA corre el test
El agente QA abre la página, ejecuta el escenario, valida el resultado, captura screenshots si hace falta y lee los logs de consola para detectar los errores de runtime que un agente dev habría pasado por alto.
El agente QA envía el veredicto
Al terminar, el agente QA llama submit_verdict con un resultado pass, fail o inconclusive y un resumen corto. Screenshots y logs adjuntos. El proceso del agente QA se destruye. Su ventana de contexto se va con él.
El agente dev lee el veredicto y sigue
El agente dev recibe el veredicto como respuesta a run_qa_test. En pass, el agente dev commitea o pasa al siguiente ticket. En fail, el agente dev lee el resumen del fallo, arregla el bug y dispara un nuevo ciclo de delegación de agente. El loop se cierra solo.
La economía de la delegación de agente
Por qué un partido dev a QA inteligente baja tu factura IA sin bajar tus estándares.
Los tests de browser son repetitivos. Abre la página, clica el botón, lee la etiqueta, verifica el toast. Un modelo de 50 dólares por millón de tokens hace ese trabajo tan bien como uno de 3 dólares por millón. Tal vez mejor, porque el modelo barato no se aburre. La delegación de agente pone al modelo barato en la mitad aburrida del trabajo.
Números reales de sesiones reales : un test end-to-end típico en un flow complejo quema entre 60k y 200k tokens entre screenshots, dumps DOM y pasos de razonamiento. En Opus, eso es dinero real por test. En Haiku, es calderilla. La delegación de agente convierte un hábito diario de QA de una preocupación de presupuesto en un reflejo gratis.
Multiplica por cada loop. Un día normal de dev en una feature no trivial corre el test entre 5 y 20 veces. La delegación de agente compone sobre esas repeticiones. El agente dev sigue caro (lo quieres caro), el agente QA sigue barato, y la diferencia es ahorro puro.
La delegación de agente también es más amable con el planeta. Menos cómputo en el mismo trabajo significa menos energía, menos agua en el datacenter, menos carbono. No es la única razón para cablear la delegación de agente, pero es un buen efecto colateral de enrutar tareas a modelos del tamaño correcto.
Un partido de modelos real para la delegación de agente
Lo que la gente realmente conecta del lado dev y del lado QA de la delegación de agente.
Lado dev (caro a propósito)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex razonamiento alto
- GPT-4 razonamiento profundo
- Gemini 3 Pro
Lado QA (delegado al más barato)
- Claude Haiku 4
- Claude Sonnet 4 (esfuerzo bajo)
- Codex mini
- GPT-4 mini
- Gemini 3 Flash
La delegación de agente no fija la matriz. Configuras el modelo QA por proyecto. Incluso puedes delegar a un provider totalmente distinto : Opus en dev, Codex mini en QA, sin contexto compartido, solo una llamada MCP.
Lo que la delegación de agente hace bajo el capó
La delegación de agente se apoya en el stack MCP de AgentsRoom. El agente dev corre dentro de su CLI (Claude, Codex, GitHub Copilot CLI, Cursor y otros 15 CLI de agente). AgentsRoom inyecta el servidor MCP Test Runner en ese agente. El Test Runner expone una sola herramienta : run_qa_test. Ese es el punto de entrada de cada llamada de delegación de agente.
Cuando run_qa_test se dispara, AgentsRoom lanza un nuevo proceso CLI en el mismo proyecto, con una config distinta. Esa config tiene el Browser MCP adjunto, el system prompt QA adjunto, y el modelo cambiado al que pusiste en el lado QA. El nuevo proceso es un agente QA efímero : vive durante el test y muere tras submit_verdict.
Mientras el agente QA corre, el agente dev está en pausa sobre la llamada run_qa_test. AgentsRoom muestra al agente QA en la misma lista de agentes, indentado bajo el agente dev (visible en la imagen de arriba). Cuando el agente QA termina, su veredicto vuelve como resultado de run_qa_test y el agente dev retoma. La delegación de agente es un solo round trip MCP desde el punto de vista del agente dev.
El agente dev nunca recibe las herramientas de browser. AgentsRoom le quita las herramientas browser_* a la lista permitida del agente dev en el momento del spawn. Esa es la parte que hace fiable la delegación de agente : el agente dev literalmente no puede caer en hacer el test él mismo, ni siquiera cuando su instinto es agarrar un screenshot. El único camino adelante es run_qa_test. Delegación de agente por sustracción, no por petición.
Dónde corre la delegación de agente hoy, y qué viene después
La delegación de agente en AgentsRoom es browser-first hoy. Misma forma, más superficies por venir.
Hoy : delegación de tests browser
El agente QA drive el browser embebido de AgentsRoom vía el Browser MCP. Servidor de dev en localhost, túnel público de preview, URL de staging, todo lo que Chromium pueda renderizar. Formularios, modales, drag and drop, dialogs, logs de consola, errores de red. La delegación de agente cubre toda la superficie que cubriría un ingeniero QA web humano.
Delegación de tests de apps Electron
Si tú mismo shippeas una app Electron, puedes instalar la librería AgentsRoom Electron MCP en tu proyecto. El agente QA se conecta a tu app Electron del mismo modo que a una pestaña Chromium. La delegación de agente cruza al testing de app desktop sin cambiar nada del lado dev.
Delegación de tests de apps React Native (roadmap)
La misma forma de delegación de agente viene en camino a React Native. El agente QA driverá un simulador iOS o Android vía un AgentsRoom React Native MCP. El agente dev entrega una pantalla, el agente QA toca a través de ella. Misma llamada run_qa_test, mismo handoff dev a QA, target móvil.
Sin delegación de agente vs con delegación de agente
Misma feature, misma pasada de QA. Factura distinta, contexto distinto, fiabilidad distinta.
Sin delegación de agente
- : El agente dev (caro) abre el browser él mismo.
- : Cada screenshot, cada dump DOM y cada log de consola aterriza en el contexto del agente dev.
- : 20 minutos de clics queman tokens Opus en un trabajo que un modelo más barato haría.
- : El agente dev olvida lo que hacía dos screenshots después.
- : Pagas precio completo por clics de browser, el planeta también.
Con delegación de agente
- : El agente dev llama run_qa_test y espera.
- : Un agente QA barato hace los clics, los asserts, la captura de screenshots.
- : Solo el veredicto (pass, fail, resumen) llega al agente dev.
- : El agente QA es efímero : muere tras submit_verdict, cero contaminación de contexto.
- : Factura de tokens en baja, agente dev concentrado, loop que se cierra solo.
La delegación de agente es la ganancia de fiabilidad más barata que puedes cablear en un setup de agente de coding.
Cómo se ve una llamada de delegación de agente
Aquí está toda la forma de una delegación de agente dev a QA. El agente dev dispara esto a través del Test Runner MCP y espera la respuesta.
Llamada a herramienta MCP (agente dev)
run_qa_test({
scenario: "Abre http://localhost:3000/login.\n Tipea el usuario de test seedeado en el campo email.\n Envía el form.\n Verifica que la URL del dashboard se alcanza y el nombre del usuario aparece en el header.\n Captura un screenshot en éxito, captura logs de consola en fallo."
})¿Qué es la delegación de agente en AgentsRoom?
¿Por qué querría delegación de agente?
¿Qué modelos sirven para la delegación de agente?
¿La delegación de agente es solo para tests de browser?
¿Cómo evita la delegación de agente que el agente dev haga el test él mismo?
¿La delegación de agente es cloud o local?
¿La delegación de agente ahorra dinero real?
¿Qué recibe el agente dev de vuelta de la delegación de agente?
¿El agente QA puede abrir un ticket de backlog si falla?
¿Dónde encaja la delegación de agente respecto a las otras features de AgentsRoom?
Combina bien con
Browser Automation
La capa Chromium y Browser MCP que el lado QA de la delegación de agente drive. Browser real, persistente, por proyecto.
Agent Messaging
La delegación crea un agente desechable que entrega un veredicto y muere. La mensajería entre agentes va en el otro sentido : miembros permanentes que se escriben, con una inbox que sobrevive a cada sesión.
Agent Teams
Editor visual de workflows multi-agente. La delegación de agente es la variante dev a QA, Agent Teams es la versión grafo completo con N nodos y feedback loops.
AgentsRoom MCP
Los servidores MCP que hacen posible la delegación de agente : Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Corre Claude, Codex, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe y Kimi Code en paralelo. La delegación de agente es el ángulo cross-provider de la misma idea.
Claude Code Token Usage
Medidor de tokens en vivo por sesión. La forma más rápida de confirmar el ahorro en dólares que te da la delegación de agente en la práctica.
Public Backlog
Cuando un agente QA falla una pasada de delegación de agente, el bug aterriza aquí. Clientes y compañeros ven la regresión, el agente dev la retoma.
Deja de pagar precios Opus por clics QA
Descarga AgentsRoom y prueba la delegación de agente. Conecta tu agente dev en el modelo en que confías, tu agente QA en un modelo más barato, y deja que el handoff dev a QA pase solo vía MCP.
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.
Agentes que lees como una conversación
Cada agente tiene un rol, una cara y un hilo que lees como una app de mensajería.
