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.
Delegación de agente en acción : el agente dev Codex termina la feature, llama run_qa_test, el agente QA abre el browser en un modelo más barato y reporta.
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 2.5 Pro
Lado QA (delegado al más barato)
- Claude Haiku 4
- Claude Sonnet 4 (esfuerzo bajo)
- Codex mini
- GPT-4 mini
- Gemini 2.5 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 Code, Codex, Gemini, OpenCode, Aider). 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."
})FAQ
¿Qué es la delegación de agente en AgentsRoom?
La delegación de agente es un handoff dev a QA entre dos agentes de coding IA. El agente dev termina una feature, llama una sola herramienta MCP (run_qa_test), y un agente QA efímero corre el test en un modelo distinto. El agente dev lee el veredicto y sigue. Todo el flow de delegación de agente pasa por los servidores MCP de AgentsRoom.
¿Por qué querría delegación de agente?
Tres razones. Dinero : el agente QA corre en un modelo más barato, así las pasadas de test cuestan una fracción de lo que costarían en el modelo dev. Contexto : el agente dev se mantiene limpio, todos los screenshots y dumps DOM mueren con el agente QA. Fiabilidad : el agente QA tiene un solo trabajo, así testea mejor que un agente dev haciendo malabarismos con clics de browser.
¿Qué modelos sirven para la delegación de agente?
Cualquier modelo que AgentsRoom soporte : Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. La delegación de agente es cross-provider. Un partido común es Claude Opus o Codex del lado dev y Claude Haiku o Codex mini del lado QA, pero tú eliges.
¿La delegación de agente es solo para tests de browser?
Hoy, sí, el agente QA drive el browser Chromium embebido de AgentsRoom. Mañana, la misma forma de delegación de agente cubre apps Electron (instala la librería AgentsRoom Electron MCP en tu proyecto Electron) y apps React Native (roadmap, simuladores iOS y Android).
¿Cómo evita la delegación de agente que el agente dev haga el test él mismo?
AgentsRoom quita las herramientas browser_* del agente dev en el spawn. El agente dev literalmente no puede llamar browser_navigate ni browser_screenshot. El único camino browser es run_qa_test, que dispara la delegación de agente. La restricción es mecánica, no una petición educada en un prompt.
¿La delegación de agente es cloud o local?
Local-first. El agente dev, el agente QA efímero, el bridge MCP y el browser corren en tu máquina. La delegación de agente solo usa la nube cuando el modelo subyacente (Claude, Codex, Gemini) habla con su propio provider, exactamente como un run de agente normal.
¿La delegación de agente ahorra dinero real?
Sí, por un factor importante en los días pesados de QA. Un test end-to-end complejo en Opus o Codex high vs el mismo test en Haiku o Codex mini es alrededor de una diferencia de costo 10x. La delegación de agente estirada sobre un día dev de equipo escala esa brecha rápido.
¿Qué recibe el agente dev de vuelta de la delegación de agente?
Un veredicto estructurado corto : pass, fail o inconclusive, con resumen, ruta de screenshot opcional y logs de consola opcionales. Sin screenshots crudos en el contexto, sin dumps DOM. Ese es todo el punto de la delegación de agente : aislar el ruido QA dentro del agente QA.
¿El agente QA puede abrir un ticket de backlog si falla?
Sí. La delegación de agente le da al agente QA el Backlog MCP. Un fallo puede aterrizar como ticket de backlog en el proyecto, con el escenario, el screenshot y los logs de consola adjuntos. El agente dev lee el veredicto, el ticket de backlog lleva los detalles largos.
¿Dónde encaja la delegación de agente respecto a las otras features de AgentsRoom?
La delegación de agente vive arriba de Browser Automation (que le da el browser al agente QA) y de los servidores MCP de AgentsRoom (que dan a cada agente su superficie de herramientas). Agent Teams es el editor de workflows multi-agente más amplio : la delegación de agente es el sabor dev a QA de ese workflow, expuesto como una sola llamada MCP para que cualquier agente de cualquier provider pueda usarla sin configurar un grafo.
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 Teams
Editor visual de workflows multi-agente. La delegación de agente es el sabor 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, Gemini, OpenCode y Aider 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, Gemini CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.