Agent-Delegation :
dein Dev-Agent delegiert den Test
Agent-Delegation lässt deinen Dev-Agent ein Feature fertigstellen und die Validierung an einen separaten QA-Agent abgeben. Der Dev liefert weiter Code mit dem Modell, dem du bei harten Problemen vertraust. Der QA-Agent führt den Test auf einem günstigeren Modell aus. Beide reden über die AgentsRoom-MCP-Server, also funktioniert Agent-Delegation Ende-zu-Ende, ohne dass du irgendetwas hin- und herkopierst.
Du hörst auf, Opus-Preise für Browserklicks zu zahlen. Du hörst auf, den Kontext deines Dev-Agents mit Screenshots und DOM-Dumps aufzublähen. Agent-Delegation leitet jede Aufgabe zum richtigen Modell zum richtigen Preis, und wenn der QA-Agent fertig ist, pingt er den Dev-Agent zurück, damit sich der Loop von selbst schließt.
Agent-Delegation in Aktion : der Codex-Dev-Agent stellt das Feature fertig, ruft run_qa_test auf, der QA-Agent öffnet den Browser auf einem günstigeren Modell und meldet zurück.
Hier ist das Problem, das Agent-Delegation löst. Du fährst einen starken Dev-Agent (Claude Opus, Codex, die Sorte Modell, die eine API entwirft oder einen Store refaktoriert). Der Agent liefert das Feature in 10 Minuten. Dann verbringt er die nächsten 8 Minuten damit, in einem Browser herumzuklicken, um zu prüfen, ob das Feature funktioniert. Gleiche teure Tokenrate. Gleiches Modell, das gerade noch hart über deine Domänenlogik nachgedacht hat, liest jetzt Buttonbeschriftungen.
Agent-Delegation behebt das. Wenn das Feature fertig ist, ruft der Dev-Agent ein einziges MCP-Tool auf, run_qa_test, mit einem Szenario. AgentsRoom spawnt einen ephemeren QA-Agent auf dem Modell, das du für QA gewählt hast : Claude Haiku, Codex mini, GPT-4 mini, was immer du willst. Der QA-Agent bekommt den AgentsRoom Browser MCP, steuert die Seite, prüft das Ergebnis und antwortet mit einem Verdikt. Der Dev-Agent liest das Verdikt und macht weiter.
Das ist Agent-Delegation, und das ist der einzige Loop, den die Seite abdeckt. Ein Dev, ein QA, ein MCP. Gleiche Idee wie ein Senior Engineer, der Regressionstests an einen Junior oder an QA delegiert : der Senior entwirft weiter, der Junior arbeitet die Checkliste ab. Agent-Delegation gibt dir genau diese Aufteilung zwischen Modellen.
Agent-Delegation visualisiert : der übergeordnete Dev-Agent (Codex) und der untergeordnete QA-Agent (Claude) tauchen in derselben Agentenliste auf, mit klarer Dev-zu-QA-Übergabe.
Warum Agent-Delegation es wert ist, eingerichtet zu werden
Erstens, Geld. Ein Testdurchlauf auf Claude Opus und ein Testdurchlauf auf Claude Haiku kosten extrem unterschiedliche Beträge. Gleicher Browser, gleiche Assertions, gleiche Screenshots. Agent-Delegation lässt das günstige Modell die günstige Arbeit machen. Leute, die das eingeschaltet haben, berichten, ihre Tokenrechnung an QA-lastigen Tagen um einen echten, messbaren Faktor zu senken, nicht um 5 bis 10 Prozent.
Zweitens, Kontext. Wenn ein Dev-Agent den Test selbst ausführt, landet jeder Screenshot, jeder DOM-Dump, jedes Console-Log im Kontextfenster des Dev-Agents. Zwanzig Minuten Klicken sind Megabytes an Rauschen, das der Dev-Agent durch den Rest der Sitzung tragen muss. Agent-Delegation isoliert dieses Rauschen im ephemeren QA-Agent. Der Dev-Agent bekommt eine saubere 'pass'- oder 'fail'-Nachricht zurück, nichts weiter.
Drittens, der ökologische Aspekt. Jede Agent-Delegation spart echte Rechenleistung. Haiku statt Opus laufen zu lassen halbiert den Energieabdruck dieses Schritts. Multipliziere das mit jedem im Team und mit jedem Testloop in einem Jahr, und Agent-Delegation wird zu einem nicht-trivialen Hebel auf der CO2-Seite deines Stacks.
Viertens, Zuverlässigkeit. Ein Dev-Agent, der den Browser selbst steuert, schweift gerne ab. Zwei Screenshots später hat er vergessen, was er eigentlich validieren wollte. Der QA-Agent in der Agent-Delegation hat einen einzigen Job und einen einzigen Prompt. Er testet, er meldet, er stirbt. Der Loop ist kurz, vorhersehbar und leicht zu debuggen.
Der einzige Flow, den Agent-Delegation hier abdeckt
Ein Dev-Agent. Ein QA-Agent. Ein MCP-Aufruf. Agent-Delegation, Ende-zu-Ende.
Dev-Agent liefert das Feature
Dein Dev-Agent (Claude Opus, Codex high reasoning, welches teure Modell du auch vertraust) schließt die Implementierung ab. Neuer Endpoint, neuer Screen, neuer Flow. Code ist geschrieben, Dateien sind gespeichert.
Dev-Agent ruft run_qa_test auf
Statt selbst den Browser zu öffnen, ruft der Dev-Agent ein einziges MCP-Tool vom AgentsRoom-Test-Runner-Server auf : run_qa_test, mit einem Szenario in einfachem Englisch. Das ist die gesamte API-Oberfläche von Agent-Delegation.
AgentsRoom spawnt den QA-Agent
Der AgentsRoom Test Runner spawnt einen ephemeren QA-Agent auf dem günstigeren Modell, das du konfiguriert hast (Claude Haiku, Codex mini, GPT-4 mini). Der QA-Agent bekommt die AgentsRoom-Browser-MCP-Tools : navigate, click, type, screenshot, evaluate, get_logs, get_state.
QA-Agent führt den Test aus
Der QA-Agent öffnet die Seite, geht das Szenario durch, prüft das Ergebnis, fängt bei Bedarf Screenshots ein und liest die Console-Logs, um die Laufzeitfehler zu erwischen, die ein Dev-Agent übersehen hätte.
QA-Agent reicht das Verdikt ein
Wenn er fertig ist, ruft der QA-Agent submit_verdict auf, mit einem pass-, fail- oder inconclusive-Ergebnis und einer kurzen Zusammenfassung. Screenshots und Logs werden angehängt. Der QA-Agent-Prozess wird zerstört. Sein Kontextfenster geht mit ihm.
Dev-Agent liest das Verdikt und macht weiter
Der Dev-Agent erhält das Verdikt als Antwort auf run_qa_test zurück. Bei pass committet der Dev-Agent oder geht zum nächsten Ticket. Bei fail liest der Dev-Agent die Fehlerzusammenfassung, behebt den Bug und löst einen neuen Agent-Delegation-Zyklus aus. Der Loop schließt sich von selbst.
Die Ökonomie der Agent-Delegation
Warum eine smarte Dev-zu-QA-Aufteilung deine KI-Rechnung senkt, ohne deine Ansprüche zu senken.
Browser-Tests sind repetitiv. Seite öffnen, Button klicken, Label lesen, Toast prüfen. Ein Modell zu 50 Dollar pro Million Tokens macht diese Arbeit genauso gut wie ein Modell zu 3 Dollar pro Million Tokens. Vielleicht besser, weil dem günstigen Modell nicht langweilig ist. Agent-Delegation setzt das günstige Modell auf die langweilige Hälfte des Jobs.
Echte Zahlen aus echten Sessions : ein typischer End-to-End-Test auf einem komplexen Flow verbrennt 60k bis 200k Tokens zwischen Screenshots, DOM-Dumps und Reasoning-Schritten. Auf Opus ist das echtes Geld pro Test. Auf Haiku ist das Kleingeld. Agent-Delegation verwandelt eine tägliche QA-Routine von einer Budgetfrage in einen kostenlosen Reflex.
Multipliziere das mit jedem Loop. Ein normaler Dev-Tag an einem nicht-trivialen Feature führt den Test fünf- bis zwanzigmal aus. Agent-Delegation summiert sich über diese Wiederholungen. Der Dev-Agent bleibt teuer (du willst ihn teuer), der QA-Agent bleibt günstig, und die Differenz ist pure Ersparnis.
Agent-Delegation ist auch freundlicher zum Planeten. Weniger Rechenleistung für denselben Job heißt weniger Energie, weniger Wasser im Rechenzentrum, weniger CO2. Nicht der einzige Grund, Agent-Delegation einzurichten, aber ein fairer Nebeneffekt, wenn man Aufgaben an passend dimensionierte Modelle weiterleitet.
Eine echte Modellaufteilung für Agent-Delegation
Was Leute tatsächlich auf der Dev-Seite und der QA-Seite der Agent-Delegation einsetzen.
Dev-Seite (absichtlich teuer gehalten)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex high reasoning
- GPT-4 with deep reasoning
- Gemini 2.5 Pro
QA-Seite (an günstigeres delegiert)
- Claude Haiku 4
- Claude Sonnet 4 (low effort)
- Codex mini
- GPT-4 mini
- Gemini 2.5 Flash
Agent-Delegation legt die Matrix nicht fest. Du konfigurierst das QA-Modell pro Projekt. Du kannst sogar an einen komplett anderen Anbieter delegieren : Opus auf Dev, Codex mini auf QA, kein gemeinsamer Kontext, einfach ein MCP-Aufruf.
Was Agent-Delegation tatsächlich unter der Haube macht
Agent-Delegation sitzt auf dem AgentsRoom-MCP-Stack. Der Dev-Agent läuft in seiner CLI (Claude Code, Codex, Gemini, OpenCode, Aider). AgentsRoom injiziert den Test-Runner-MCP-Server in diesen Agent. Der Test Runner stellt ein Tool bereit : run_qa_test. Das ist der Einstiegspunkt jedes Agent-Delegation-Aufrufs.
Wenn run_qa_test feuert, spawnt AgentsRoom einen neuen CLI-Prozess im selben Projekt, mit einer anderen Config. Diese Config hat den Browser MCP angeheftet, den QA-Systemprompt angeheftet und das Modell auf das umgestellt, was du auf der QA-Seite gesetzt hast. Der neue Prozess ist ein ephemerer QA-Agent : er lebt für die Dauer des Tests und stirbt nach submit_verdict.
Während der QA-Agent läuft, ist der Dev-Agent am run_qa_test-Aufruf pausiert. AgentsRoom zeigt den QA-Agent in derselben Agentenliste, eingerückt unter dem Dev-Agent (sichtbar im Bild oben). Wenn der QA-Agent fertig ist, wird sein Verdikt als run_qa_test-Resultat zurückgegeben und der Dev-Agent läuft weiter. Agent-Delegation ist aus Sicht des Dev-Agents ein einziger MCP-Round-Trip.
Der Dev-Agent bekommt die Browser-Tools nie. AgentsRoom entfernt die browser_*-Tools beim Spawnen aus der Allowed-Liste des Dev-Agents. Genau das macht Agent-Delegation zuverlässig : der Dev-Agent kann nicht darauf zurückfallen, den Test selbst zu machen, auch wenn sein Instinkt ist, einen Screenshot zu schnappen. Der einzige Weg nach vorn ist run_qa_test. Agent-Delegation durch Entzug, nicht durch Bitte.
Wo Agent-Delegation heute läuft, und wo als Nächstes
Agent-Delegation im AgentsRoom ist heute browser-first. Gleiche Form, mehr Oberflächen kommen.
Heute : Browser-Test-Delegation
Der QA-Agent steuert den eingebetteten AgentsRoom-Browser über das Browser MCP. Localhost-Dev-Server, öffentlicher Preview-Tunnel, Staging-URL, alles, was Chromium rendern kann. Formulare, Modals, Drag-and-Drop, Dialoge, Console-Logs, Netzwerkfehler. Agent-Delegation deckt die volle Oberfläche ab, die ein Web-QA-Engineer abdecken würde.
Electron-App-Test-Delegation
Wenn du selbst eine Electron-App ausspielst, kannst du die AgentsRoom-Electron-MCP-Library in deinem Projekt installieren. Der QA-Agent verbindet sich genauso mit deiner Electron-App, wie er sich mit einem Chromium-Tab verbindet. Agent-Delegation rückt in Desktop-App-Tests vor, ohne die Dev-Seite überhaupt zu ändern.
React-Native-App-Test-Delegation (Roadmap)
Dieselbe Form der Agent-Delegation kommt zu React Native. Der QA-Agent wird einen iOS- oder Android-Simulator über ein AgentsRoom React Native MCP steuern. Dev-Agent liefert einen Screen, QA-Agent tippt sich durch. Gleicher run_qa_test-Aufruf, gleiche Dev-zu-QA-Übergabe, mobiles Ziel.
Ohne Agent-Delegation vs mit Agent-Delegation
Gleiches Feature, gleicher QA-Durchlauf. Andere Rechnung, anderer Kontext, andere Zuverlässigkeit.
Ohne Agent-Delegation
- : Der Dev-Agent (teuer) öffnet den Browser selbst.
- : Jeder Screenshot, jeder DOM-Dump und jedes Console-Log landet im Kontext des Dev-Agents.
- : 20 Minuten Klicken verbrennen Opus-Tokens für Arbeit, die ein günstigeres Modell erledigen würde.
- : Der Dev-Agent vergisst zwei Screenshots später, was er eigentlich getan hat.
- : Du zahlst den vollen Preis für Browserklicks, und der Planet zahlt auch den vollen Preis.
Mit Agent-Delegation
- : Der Dev-Agent ruft run_qa_test auf und wartet.
- : Ein günstiger QA-Agent macht die Klicks, die Assertions, das Screenshot-Capturing.
- : Nur das Verdikt (pass, fail, Zusammenfassung) erreicht den Dev-Agent.
- : Der QA-Agent ist ephemer : er stirbt nach submit_verdict, kein Kontext-Aufblähen.
- : Tokenrechnung fällt, Dev-Agent bleibt fokussiert, Loop schließt sich von selbst.
Agent-Delegation ist der günstigste Zuverlässigkeitsgewinn, den du in ein Coding-Agent-Setup einbauen kannst.
Wie ein Agent-Delegation-Aufruf aussieht
Hier ist die gesamte Form einer Dev-zu-QA-Agent-Delegation. Der Dev-Agent feuert das über den Test Runner MCP ab und wartet auf die Antwort.
MCP-Tool-Aufruf (Dev-Agent)
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
Was ist Agent-Delegation im AgentsRoom ?
Agent-Delegation ist eine Dev-zu-QA-Übergabe zwischen zwei KI-Coding-Agents. Der Dev-Agent schließt ein Feature ab, ruft ein einziges MCP-Tool auf (run_qa_test), und ein ephemerer QA-Agent fährt den Test auf einem anderen Modell. Der Dev-Agent liest das Verdikt und macht weiter. Der ganze Agent-Delegation-Flow passiert über die AgentsRoom-MCP-Server.
Warum sollte ich Agent-Delegation überhaupt wollen ?
Drei Gründe. Geld : der QA-Agent läuft auf einem günstigeren Modell, also kosten Testdurchläufe einen Bruchteil dessen, was sie auf dem Dev-Modell kosten würden. Kontext : der Dev-Agent bleibt sauber, alle Screenshots und DOM-Dumps sterben mit dem QA-Agent. Zuverlässigkeit : der QA-Agent hat einen einzigen Job, also testet er besser als ein Dev-Agent, der nebenbei Browserklicks macht.
Welche Modelle funktionieren für Agent-Delegation ?
Jedes Modell, das AgentsRoom unterstützt : Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. Agent-Delegation ist anbieterübergreifend. Ein häufiger Split ist Claude Opus oder Codex auf der Dev-Seite und Claude Haiku oder Codex mini auf der QA-Seite, aber du entscheidest.
Ist Agent-Delegation nur für Browser-Tests ?
Heute ja, der QA-Agent steuert den eingebetteten Chromium-Browser im AgentsRoom. Morgen deckt dieselbe Form der Agent-Delegation Electron-Apps ab (installiere die AgentsRoom-Electron-MCP-Library in deinem Electron-Projekt) und React-Native-Apps (Roadmap, iOS- und Android-Simulatoren).
Wie verhindert Agent-Delegation, dass der Dev-Agent den Test selbst macht ?
AgentsRoom entfernt die browser_*-Tools beim Spawnen vom Dev-Agent. Der Dev-Agent kann buchstäblich kein browser_navigate oder browser_screenshot aufrufen. Der einzige Browserpfad ist run_qa_test, was die Agent-Delegation auslöst. Die Einschränkung ist mechanisch, keine höfliche Bitte im Prompt.
Ist Agent-Delegation Cloud oder lokal ?
Local-first. Der Dev-Agent, der ephemere QA-Agent, die MCP-Brücke und der Browser laufen alle auf deiner Maschine. Agent-Delegation nutzt die Cloud nur, wenn das zugrundeliegende Modell (Claude, Codex, Gemini) mit seinem eigenen Anbieter spricht, genau wie ein normaler Agentenlauf.
Spart Agent-Delegation echtes Geld ?
Ja, um einen relevanten Faktor an QA-lastigen Tagen. Ein komplexer End-to-End-Test auf Opus oder Codex high vs derselbe Test auf Haiku oder Codex mini ist grob ein 10-facher Kostenunterschied. Agent-Delegation über einen Dev-Tag im Team skaliert diese Lücke schnell.
Was bekommt der Dev-Agent aus der Agent-Delegation zurück ?
Ein kurzes strukturiertes Verdikt : pass, fail oder inconclusive, mit einer Zusammenfassung, optionalem Screenshot-Pfad und optionalen Console-Logs. Keine rohen Screenshots im Kontext, keine DOM-Dumps. Genau das ist der ganze Sinn der Agent-Delegation : das QA-Rauschen im QA-Agent isolieren.
Kann der QA-Agent ein Backlog-Ticket anlegen, wenn er fehlschlägt ?
Ja. Agent-Delegation gibt dem QA-Agent das Backlog MCP. Ein Fehlschlag kann als Backlog-Ticket im Projekt landen, mit Szenario, Screenshot und Console-Logs angehängt. Der Dev-Agent liest das Verdikt, und das Backlog-Ticket trägt die ausführlichen Details.
Wo passt Agent-Delegation im Verhältnis zu den anderen AgentsRoom-Features hin ?
Agent-Delegation lebt auf Browser Automation (das gibt dem QA-Agent den Browser) und den AgentsRoom-MCP-Servern (die jedem Agent seine Tool-Oberfläche geben). Agent Teams ist der breitere visuelle Multi-Agenten-Workflow-Editor : Agent-Delegation ist die Dev-zu-QA-Spielart dieses Workflows, aber als einziger MCP-Aufruf exponiert, sodass jeder Agent in jedem Anbieter sie ohne Graph-Konfiguration nutzen kann.
Passt gut zu
Browser Automation
Die Chromium- und Browser-MCP-Schicht, die die QA-Seite der Agent-Delegation steuert. Echter persistenter Browser pro Projekt.
Agent Teams
Visueller Multi-Agenten-Workflow-Editor. Agent-Delegation ist die Dev-zu-QA-Spielart, Agent Teams ist die volle Graph-Version mit N Knoten und Feedback-Loops.
AgentsRoom MCP
Die MCP-Server, die Agent-Delegation möglich machen : Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Lass Claude, Codex, Gemini, OpenCode und Aider nebeneinander laufen. Agent-Delegation ist der anbieterübergreifende Aspekt derselben Idee.
Claude Code Token Usage
Live-Token-Anzeige pro Session. Der schnellste Weg, die Dollar-Ersparnis zu bestätigen, die dir Agent-Delegation in der Praxis bringt.
Public Backlog
Wenn ein QA-Agent einen Agent-Delegation-Durchlauf nicht besteht, landet der Bug hier. Kunden und Teammitglieder sehen die Regression, der Dev-Agent greift sie wieder auf.
Hör auf, Opus-Preise für QA-Klicks zu zahlen
Lade AgentsRoom herunter und probier Agent-Delegation aus. Verdrahte deinen Dev-Agent auf dem Modell, dem du vertraust, deinen QA-Agent auf einem günstigeren Modell, und lass die Dev-zu-QA-Übergabe von selbst über MCP passieren.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Gemini CLI oder einen anderen AI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.