Delegação de agente :
seu agente de dev delega o teste
A delegação de agente permite que o seu agente de dev finalize uma funcionalidade e passe a validação para um agente de QA separado. O dev continua entregando código com o modelo em que você confia para problemas difíceis. O agente de QA executa o teste em um modelo mais barato. Os dois conversam pelos servidores MCP do AgentsRoom, então a delegação de agente funciona de ponta a ponta sem você copiar nada entre janelas.
Você para de pagar preço de Opus por cliques de browser. Você para de inchar o contexto do seu agente de dev com screenshots e dumps de DOM. A delegação de agente encaminha cada tarefa para o modelo certo no preço certo, e quando o agente de QA termina, ele avisa o agente de dev de volta, então o loop se fecha sozinho.
Delegação de agente em ação : o agente de dev Codex termina a funcionalidade, chama run_qa_test, o agente de QA abre o browser em um modelo mais barato e reporta de volta.
Aqui está o problema que a delegação de agente resolve. Você roda um agente de dev forte (Claude Opus, Codex, o tipo de modelo que projeta uma API ou refatora uma store). O agente entrega a funcionalidade em 10 minutos. Depois passa os 8 minutos seguintes clicando num browser para verificar se a feature funciona. Mesma taxa cara de tokens. Mesmo modelo que estava pensando duro na sua lógica de domínio, agora lendo rótulos de botão.
A delegação de agente resolve isso. Quando a feature está pronta, o agente de dev chama uma única ferramenta MCP, run_qa_test, com um cenário. O AgentsRoom faz spawn de um agente de QA efêmero no modelo que você escolheu para QA : Claude Haiku, Codex mini, GPT-4 mini, o que você quiser. O agente de QA recebe o AgentsRoom Browser MCP, conduz a página, valida o resultado e responde com um veredito. O agente de dev lê o veredito e segue.
Isso é delegação de agente, e é o único loop que esta página cobre. Um dev, um QA, um MCP. Mesma ideia de um engenheiro sênior delegando testes de regressão a um júnior ou ao QA : o sênior continua projetando, o júnior roda a checklist. A delegação de agente lhe dá essa mesma divisão entre modelos.
Delegação de agente visualizada : o agente de dev pai (Codex) e o agente de QA filho (Claude) aparecem na mesma lista de agentes, com um handoff claro de dev para QA.
Por que vale a pena ligar a delegação de agente
Primeiro, dinheiro. Uma passagem de teste no Claude Opus e uma passagem de teste no Claude Haiku custam valores muito diferentes. Mesmo browser, mesmas asserções, mesmos screenshots. A delegação de agente deixa o modelo barato fazer o trabalho barato. Quem ligou isso relata derrubar a conta de tokens em dias pesados de QA por um fator real e mensurável, não em 5 a 10 por cento.
Segundo, contexto. Quando um agente de dev roda o teste sozinho, cada screenshot, cada dump de DOM, cada log de console acaba na janela de contexto do agente de dev. Vinte minutos de clique é megabytes de ruído que o agente de dev tem que carregar pelo resto da sessão. A delegação de agente isola esse ruído dentro do agente de QA efêmero. O agente de dev recebe uma mensagem limpa de 'pass' ou 'fail' de volta, nada mais.
Terceiro, o ângulo ecológico. Cada delegação de agente economiza computação real. Rodar Haiku onde Opus rodava corta pela metade a pegada energética nesse passo. Multiplique por todo mundo no time e por cada loop de teste em um ano e a delegação de agente vira um botão não trivial no lado de carbono da sua stack.
Quarto, confiabilidade. Um agente de dev que conduz o browser sozinho tende a se perder. Dois screenshots depois, ele esquece o que estava tentando validar. O agente de QA na delegação de agente tem um único trabalho e um único prompt. Ele testa, ele reporta, ele morre. O loop é curto, previsível e fácil de debugar.
O único fluxo que a delegação de agente cobre aqui
Um agente de dev. Um agente de QA. Uma chamada MCP. Delegação de agente, de ponta a ponta.
Agente de dev entrega a funcionalidade
Seu agente de dev (Claude Opus, Codex high reasoning, qualquer modelo caro em que você confia) finaliza a implementação. Novo endpoint, nova tela, novo fluxo. Código escrito, arquivos salvos.
Agente de dev chama run_qa_test
Em vez de abrir o browser ele mesmo, o agente de dev chama uma única ferramenta MCP do servidor AgentsRoom Test Runner : run_qa_test, com um cenário em inglês simples. Essa é toda a superfície de API da delegação de agente.
AgentsRoom faz spawn do agente de QA
O AgentsRoom Test Runner faz spawn de um agente de QA efêmero no modelo mais barato que você configurou (Claude Haiku, Codex mini, GPT-4 mini). O agente de QA recebe as ferramentas do AgentsRoom Browser MCP : navigate, click, type, screenshot, evaluate, get_logs, get_state.
Agente de QA roda o teste
O agente de QA abre a página, percorre o cenário, valida o resultado, captura screenshots se necessário e lê os logs de console para pegar os erros de runtime que um agente de dev teria perdido.
Agente de QA envia o veredito
Quando termina, o agente de QA chama submit_verdict com um resultado pass, fail ou inconclusive e um resumo curto. Screenshots e logs são anexados. O processo do agente de QA é destruído. A janela de contexto vai junto.
Agente de dev lê o veredito e segue
O agente de dev recebe o veredito de volta como resposta de run_qa_test. Em caso de pass, o agente de dev comita ou vai para o próximo ticket. Em caso de fail, o agente de dev lê o resumo da falha, corrige o bug e dispara um novo ciclo de delegação de agente. O loop se fecha sozinho.
A economia da delegação de agente
Por que uma divisão inteligente entre dev e QA diminui a sua conta de IA sem baixar o seu nível.
Testes de browser são repetitivos. Abrir a página, clicar no botão, ler o rótulo, conferir o toast. Um modelo a 50 dólares por milhão de tokens faz esse trabalho tão bem quanto um modelo a 3 dólares por milhão de tokens. Talvez melhor, porque o modelo barato não fica entediado. A delegação de agente coloca o modelo barato na metade chata do trabalho.
Números reais de sessões reais : um teste end to end típico em um fluxo complexo queima de 60k a 200k tokens entre screenshots, dumps de DOM e passos de raciocínio. No Opus, isso é dinheiro de verdade por teste. No Haiku, é troco. A delegação de agente transforma o hábito diário de QA de uma preocupação de orçamento em um reflexo gratuito.
Multiplique por cada loop. Um dia normal de dev em uma feature não trivial roda o teste de cinco a vinte vezes. A delegação de agente acumula ao longo dessas repetições. O agente de dev continua caro (você quer ele caro), o agente de QA continua barato, e a diferença é pura economia.
A delegação de agente também é mais gentil com o planeta. Menos computação no mesmo trabalho significa menos energia, menos água no datacenter, menos carbono. Não é a única razão para ligar a delegação de agente, mas é um efeito colateral justo de encaminhar tarefas para modelos do tamanho certo.
Uma divisão real de modelos para delegação de agente
O que as pessoas realmente plugam no lado dev e no lado QA da delegação de agente.
Lado dev (mantido caro de propósito)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 with deep reasoning
- Gemini 2.5 Pro
Lado QA (delegado ao mais barato)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 2.5 Flash
A delegação de agente não trava a matriz. Você configura o modelo de QA por projeto. Você pode até delegar a um provedor totalmente diferente : Opus no dev, Codex mini no QA, sem contexto compartilhado, apenas uma chamada MCP.
O que a delegação de agente realmente faz por baixo do capô
A delegação de agente roda em cima da stack MCP do AgentsRoom. O agente de dev roda dentro do seu CLI (Claude Code, Codex, Gemini, OpenCode, Aider). O AgentsRoom injeta o servidor MCP Test Runner nesse agente. O Test Runner expõe uma ferramenta : run_qa_test. Esse é o ponto de entrada de toda chamada de delegação de agente.
Quando run_qa_test dispara, o AgentsRoom faz spawn de um novo processo CLI no mesmo projeto, com uma config diferente. Essa config tem o Browser MCP anexado, o system prompt de QA anexado e o modelo trocado para o que você setou no lado QA. O novo processo é um agente de QA efêmero : ele vive pela duração do teste e morre depois de submit_verdict.
Enquanto o agente de QA roda, o agente de dev fica pausado na chamada de run_qa_test. O AgentsRoom mostra o agente de QA na mesma lista de agentes, indentado abaixo do agente de dev (visível na imagem acima). Quando o agente de QA termina, o seu veredito é retornado como resultado de run_qa_test e o agente de dev retoma. A delegação de agente é um único round trip MCP do ponto de vista do agente de dev.
O agente de dev nunca recebe as ferramentas de browser. O AgentsRoom remove as ferramentas browser_* da lista permitida do agente de dev no momento do spawn. Essa é a parte que torna a delegação de agente confiável : o agente de dev não pode voltar a fazer o teste sozinho, mesmo quando o instinto dele é pegar um screenshot. O único caminho à frente é run_qa_test. Delegação de agente por remoção, não por pedido.
Onde a delegação de agente roda hoje, e onde rodará a seguir
A delegação de agente no AgentsRoom é browser-first hoje. Mesma forma, mais superfícies a caminho.
Hoje : delegação de teste de browser
O agente de QA conduz o browser embarcado do AgentsRoom via Browser MCP. Servidor de dev em localhost, túnel público de preview, URL de staging, qualquer coisa que o Chromium consiga renderizar. Formulários, modais, drag and drop, dialogs, logs de console, erros de rede. A delegação de agente cobre toda a superfície que um engenheiro de QA web cobriria.
Delegação de teste de app Electron
Se você publica um app Electron, você pode instalar a biblioteca AgentsRoom Electron MCP no seu projeto. O agente de QA conecta no seu app Electron da mesma forma que conecta em uma aba do Chromium. A delegação de agente cruza para testes de app desktop sem mudar o lado dev em nada.
Delegação de teste de app React Native (roadmap)
A mesma forma de delegação de agente está chegando para React Native. O agente de QA vai conduzir um simulador iOS ou Android via um AgentsRoom React Native MCP. Agente de dev entrega uma tela, agente de QA toca por ela. Mesma chamada run_qa_test, mesmo handoff de dev para QA, alvo mobile.
Sem delegação de agente vs com delegação de agente
Mesma feature, mesma passagem de QA. Conta diferente, contexto diferente, confiabilidade diferente.
Sem delegação de agente
- : O agente de dev (caro) abre o browser ele mesmo.
- : Cada screenshot, cada dump de DOM e cada log de console pousa no contexto do agente de dev.
- : 20 minutos de clique queimam tokens de Opus em trabalho que um modelo mais barato faria.
- : O agente de dev esquece o que estava fazendo dois screenshots depois.
- : Você paga preço cheio por cliques de browser, e o planeta paga preço cheio também.
Com delegação de agente
- : O agente de dev chama run_qa_test e espera.
- : Um agente de QA barato faz os cliques, as asserções, a captura de screenshot.
- : Só o veredito (pass, fail, resumo) chega ao agente de dev.
- : O agente de QA é efêmero : ele morre depois de submit_verdict, sem inchar o contexto.
- : Conta de tokens cai, agente de dev fica focado, loop se fecha sozinho.
A delegação de agente é a vitória de confiabilidade mais barata que você consegue plugar em um setup de coding agent.
Como é uma chamada de delegação de agente
Aqui está toda a forma de uma delegação de agente dev-para-QA. O agente de dev dispara isso pelo Test Runner MCP e espera a resposta.
Chamada de ferramenta MCP (agente de dev)
run_qa_test({
scenario: "Open http://localhost:3000/login.\n Type the seeded test user in the email field.\n Submit the form.\n Assert the dashboard URL is reached and the user's name is shown in the header.\n Capture a screenshot on success, capture console logs on failure."
})FAQ
O que é delegação de agente no AgentsRoom ?
Delegação de agente é um handoff de dev para QA entre dois agentes de IA de programação. O agente de dev finaliza uma feature, chama uma única ferramenta MCP (run_qa_test), e um agente de QA efêmero roda o teste em um modelo diferente. O agente de dev lê o veredito e segue. Todo o fluxo de delegação de agente acontece pelos servidores MCP do AgentsRoom.
Por que eu iria querer delegação de agente ?
Três razões. Dinheiro : o agente de QA roda em um modelo mais barato, então as passagens de teste custam uma fração do que custariam no modelo de dev. Contexto : o agente de dev fica limpo, todos os screenshots e dumps de DOM morrem com o agente de QA. Confiabilidade : o agente de QA tem um único trabalho, então ele testa melhor que um agente de dev fazendo multitask em cliques de browser.
Quais modelos funcionam para delegação de agente ?
Qualquer modelo que o AgentsRoom suporta : Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. A delegação de agente é entre provedores. Uma divisão comum é Claude Opus ou Codex no lado dev e Claude Haiku ou Codex mini no lado QA, mas você escolhe.
A delegação de agente é só para testes de browser ?
Hoje, sim, o agente de QA conduz o browser Chromium embarcado do AgentsRoom. Amanhã, a mesma forma de delegação de agente cobre apps Electron (instale a biblioteca AgentsRoom Electron MCP no seu projeto Electron) e apps React Native (roadmap, simuladores iOS e Android).
Como a delegação de agente evita que o agente de dev faça o teste sozinho ?
O AgentsRoom remove as ferramentas browser_* do agente de dev no momento do spawn. O agente de dev literalmente não consegue chamar browser_navigate ou browser_screenshot. O único caminho de browser é run_qa_test, que dispara a delegação de agente. A restrição é mecânica, não um pedido educado no prompt.
A delegação de agente é em nuvem ou local ?
Local-first. O agente de dev, o agente de QA efêmero, a ponte MCP e o browser rodam todos na sua máquina. A delegação de agente só usa a nuvem quando o modelo subjacente (Claude, Codex, Gemini) conversa com o seu próprio provedor, exatamente como uma execução normal de agente.
A delegação de agente economiza dinheiro real ?
Sim, por um fator relevante em dias pesados de QA. Um teste end-to-end complexo em Opus ou Codex high vs o mesmo teste em Haiku ou Codex mini é aproximadamente uma diferença de custo de 10x. A delegação de agente ao longo de um dia de dev no time escala essa diferença rápido.
O que o agente de dev recebe de volta da delegação de agente ?
Um veredito estruturado curto : pass, fail ou inconclusive, com um resumo, caminho opcional de screenshot e logs de console opcionais. Sem screenshots crus no contexto, sem dumps de DOM. Esse é o ponto inteiro da delegação de agente : isolar o ruído de QA dentro do agente de QA.
O agente de QA pode abrir um ticket de backlog quando falha ?
Sim. A delegação de agente dá ao agente de QA o Backlog MCP. Uma falha pode pousar como um ticket de backlog no projeto, com o cenário, screenshot e logs de console anexados. O agente de dev lê o veredito e o ticket do backlog carrega os detalhes em formato longo.
Onde a delegação de agente se encaixa em relação às outras features do AgentsRoom ?
A delegação de agente vive em cima de Browser Automation (que dá ao agente de QA o browser) e dos servidores MCP do AgentsRoom (que dão a cada agente a sua superfície de ferramentas). Agent Teams é o editor de workflow multi-agente mais amplo : a delegação de agente é o sabor dev-para-QA desse workflow, mas exposto como uma única chamada MCP para que qualquer agente em qualquer provedor possa usar sem configurar um grafo.
Combina bem com
Browser Automation
A camada Chromium e Browser MCP que o lado QA da delegação de agente conduz. Browser real persistente por projeto.
Agent Teams
Editor visual de workflow multi-agente. A delegação de agente é o sabor dev-para-QA, Agent Teams é a versão completa em grafo com N nós e loops de feedback.
AgentsRoom MCP
Os servidores MCP que tornam a delegação de agente possível : Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Rode Claude, Codex, Gemini, OpenCode e Aider lado a lado. A delegação de agente é o ângulo entre provedores da mesma ideia.
Claude Code Token Usage
Medidor de tokens ao vivo por sessão. A maneira mais rápida de confirmar a economia em dólares que a delegação de agente te dá na prática.
Public Backlog
Quando um agente de QA falha uma passagem de delegação de agente, o bug pousa aqui. Clientes e colegas veem a regressão, o agente de dev pega de volta.
Pare de pagar preço de Opus por cliques de QA
Baixe o AgentsRoom e experimente a delegação de agente. Pluge o seu agente de dev no modelo em que você confia, o seu agente de QA em um modelo mais barato, e deixe o handoff de dev para QA acontecer sozinho via MCP.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Gemini CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.