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.
No painel Tests, o agente de teste do projeto passa de Sonnet para o Claude Haiku, mais barato. Um agente Claude Opus cria um botão Buy e depois delega o teste no navegador: um agente de QA aparece abaixo dele no Haiku, abre a loja no navegador integrado, clica em Buy e vê o carrinho passar para 1. O veredito, aprovado, volta para a conversa do agente Opus.
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 escrito em linguagem natural. 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 3 Pro
Lado QA (delegado ao mais barato)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 3 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, Codex, GitHub Copilot CLI, Cursor e outras 15 CLIs de agentes). 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."
})O que é delegação de agente no AgentsRoom ?
Por que eu iria querer delegação de agente ?
Quais modelos funcionam para delegação de agente ?
A delegação de agente é só para testes de browser ?
Como a delegação de agente evita que o agente de dev faça o teste sozinho ?
A delegação de agente é em nuvem ou local ?
A delegação de agente economiza dinheiro real ?
O que o agente de dev recebe de volta da delegação de agente ?
O agente de QA pode abrir um ticket de backlog quando falha ?
Onde a delegação de agente se encaixa em relação às outras features do AgentsRoom ?
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 Messaging
A delegação cria um agente descartável que entrega um veredito e morre. As mensagens entre agentes vão na direção oposta: membros permanentes que se escrevem, com uma caixa de entrada que sobrevive a cada sessão.
Agent Teams
Editor visual de workflow multi-agente. A delegação de agente é a variante 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, Antigravity, OpenCode, Aider, Grok Build, Mistral Vibe e Kimi Code 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, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.
Agentes que você lê como uma conversa
Cada agente tem uma função, um rosto e um fio que você lê como um app de mensagens.
