Agent Teams.
Eine echte Tech-Crew, scripted.

Claude-Subagents sind Inline-Delegationen von einer einzelnen Parent-Claude-Session. Der Parent entscheidet, wann ein Subagent aufgerufen wird, der Subagent läuft in einem isolierten Kontextfenster, gibt ein Ergebnis zurück, und der Parent macht weiter. AgentsRoom Teams ist eine Stufe darüber: jeder Node ist eine Top-Level-Claude-Code-Session mit eigenem Terminal, eigenem State und eigenem Scrollback. Du siehst jeden Agenten live in seinem eigenen Tab laufen, du kannst jederzeit mit jedem reden, du kannst das Team pausieren, den Workflow ändern und fortsetzen. Es ist kein Ersatz für Claude-Subagents, du kannst absolut beide nutzen. Ein Team-Node kann intern Subagents nutzen.

Es funktioniert mit allen 14 Agent-CLIs, die AgentsRoom unterstützt (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor und 10 weitere). Jeder Team-Node wählt seinen eigenen Provider und sein Modell. Die MCP-basierten Team-Koordinationstools funktionieren providerübergreifend identisch, weil sie über das standardisierte Model Context Protocol exponiert werden. Du kannst ein Team mit Codex auf dem schweren Backend-Node und Haiku auf dem QA-Node laufen lassen, wenn das zu deinem Budget und deiner Latenz passt.

Ein strukturiertes Objekt, das von einem Agenten zum nächsten reist. Felder: featureSummary (eine kurze Beschreibung dessen, was gerade geliefert wurde), changedFiles (git diff name-status), touchedAreas (UI, API, DB, Config), risks (alles, worüber sich der nächste Agent Sorgen machen sollte), testHints (Prioritäten für QA), flags (Booleans wie qaPassed, von konditionalen Edges genutzt). Der Agent ruft team_complete_step mit diesem Payload auf, der Runner validiert ihn server-seitig, der nächste Agent erhält ihn als seinen Startkontext.

Ja. Wenn ein Node erneut betreten wird (Cycle größer als 1), spawnt AgentsRoom keinen neuen Agenten. Es verwendet den originalen Agenten von Cycle 1 wieder, schreibt den neuen Handoff-Payload direkt in dessen existierendes Terminal, und der Agent behält seine volle Claude-Session-Erinnerung an die vorherigen Cycles. Das ist kritisch: ein Dev-Agent, der schon weiß, was QA letztes Mal markiert hat, fixt den Bug. Ein frischer Dev-Agent ohne Erinnerung würde einfach denselben Fehler wiederholen.

Die Team-Konfiguration hat einen Max-Cycles-Guard, Standard 3. Wenn die Grenze erreicht ist, pausiert der Run mit Status 'blocked' und wartet auf dich. Du kannst den Run finalisieren, manuell ein weiteres Mal übergeben oder alles abbrechen. Keine unendlichen Loops, keine Ueberraschungsrechnungen über Nacht.

Ja. Das Team läuft in einem einzigen Workspace und einem einzigen Branch (oder Worktree, wenn du das AgentsRoom-Worktrees-Feature nutzt). Jeder Agent sieht die Arbeit des vorherigen über Git. Der Handoff-Payload enthält einen Git-Diff gegen die Run-Baseline, sodass der nächste Agent genau weiß, was neu ist.

Nein. Teams sind Teil von AgentsRoom. Du bringst deine eigenen Provider-Keys mit (Claude, Codex, GitHub Copilot CLI, Cursor und 10 weitere Agent-CLIs) und zahlst nur für die Tokens, die du nutzt, wie bei einem einzelnen Agenten. Ein Dev zu QA Team auf einem kleinen Ticket kostet typischerweise dasselbe wie ein einzelner Fullstack-Agent, weil Haiku/Sonnet im QA-Schritt billig ist.

Projekt-Teams leben mit dem Raum, synchronisiert mit Ihrem Konto und gecacht in {project}/.agentsroom/teams-cache.json (gitignored). Globale Teams sind ebenfalls mit Ihrem Konto synchronisiert: Ihre Team-Bibliothek folgt Ihnen von Maschine zu Maschine, mit ~/.agentsroom/teams/ als Offline-Cache. Mitgelieferte Vorlagen bleiben lokal: Jede Maschine legt sie in ihrer eigenen Sprache an.

Der Run-Zustand wird auf der Platte persistiert in {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), mit atomaren Schreibvorgängen und append-only Notizen. Ein unterbrochener Run setzt nach dem App-Neustart fort: Der Orchestrator steigt am aktiven Schritt wieder ein, öffnet das Terminal neu, und der Agent holt sich seinen Kontext aus den Notizen und den Team-Tools zurück. Ein Run, dessen Team gelöscht wurde, wird automatisch geschlossen statt ewig liegenzubleiben.

Ja. Jeder Team-Run ist unabhängig und über seine runId identifiziert. Drei verschiedene Teams können auf drei Tickets im selben Projekt laufen. Innerhalb eines Runs folgt die Ausführung Ihrem Graphen: sequenziell als Standard, parallel wo Sie parallele Zweige zeichnen (etwa QA und Security, die gleichzeitig prüfen), immer mit einem deterministischen Join.

Ja. Ziehen Sie zwei Kanten ohne Bedingung aus einem Node, laufen beide Ziele als parallele Zweige, jeder im eigenen Agent und Terminal. Zweige sind einen Node tief und müssen auf einem gemeinsamen Join-Node zusammenlaufen, was der Editor vor dem Start validiert. Sobald jeder Zweig fertig ist, erhält der Join ein zusammengeführtes Payload: nach Rolle beschriftete Zusammenfassungen, deduplizierte Risiken und Testhinweise, und Flags mit einer Fail-Safe-Regel (ein boolescher Konflikt löst sich zu false auf).

Sie tippen einen Shell-Befehl auf dem Node ein, zum Beispiel npm test, und optional einen Flag-Namen (Standard: checkPassed). Meldet der Agent seinen Schritt fertig, führt AgentsRoom den Befehl im Workspace aus, mit fünf Minuten Limit. Exit-Code 0 schreibt true in das Flag, alles andere false, und überschreibt damit die Eigenangabe des Agents. Bei einem Fehlschlag wandern die letzten Kilobytes der Ausgabe zum nächsten Agent: Die Rückschleife landet mit dem echten Stacktrace, und das Ergebnis erscheint in der Run-Timeline.

Ja. Jeder Node kann Skills aus Ihrer Skills Library anheften, projektweit oder global. Der Agent wird angewiesen, jede davon vor dem Start des Schritts zu laden: Eine Review-Checkliste, ein Deploy-Runbook oder eine Testprozedur wird bei jedem einzelnen Run angewendet, statt vom Gedächtnis des Agents abzuhängen.

Ja. Der Editor führt eine Reihe von Graph-Prüfungen aus und trennt blockierende Fehler von Warnungen. Fehler stoppen den Lauf: ein fehlender Start- oder End-Knoten, doppelte Verbindungen, zwei Verbindungen mit denselben Bedingungen, eine Verbindung, deren eigene Bedingungen sich widersprechen, ein ungültiges Fan-out. Warnungen nicht: ein Flag-Name mit Leerzeichen davor oder danach, eine Bedingung an einer Verbindung aus Start, ein Knoten, dessen ausgehende Verbindungen alle bedingt sind, sodass der Lauf stecken bleiben kann. Beides wird in einem Prüfungspanel aufgelistet und die schuldigen Verbindungen werden auf dem Canvas umgefärbt, damit Sie den Graphen korrigieren, bevor er Ihnen einen Lauf kostet.

Nein, und das ist Absicht. Solange ein Run lebt, ist die Team-Definition gegen Schreibzugriffe aus den MCP-Tools eingefroren: Nodes, Kanten, Max Cycles, Schritt-Anweisungen, Skills, Prüfbefehl, Rolle, Provider und Modell sind für Agenten schreibgeschützt, ein vom Run geladener Skill lässt sich ebenfalls nicht umschreiben, und das Einfrieren lässt sich nicht dadurch umgehen, dass man das Team löscht und neu anlegt. Ein Agent darf die Regel nicht umschreiben, die ihn steuert. Sie selbst bearbeiten weiterhin jederzeit alles über die Oberfläche.

Ja. Der Mobile Companion kann ein Team auf einem Projekt starten, zeigt ein Run-Banner mit dem Fortschritt jedes Schritts und gibt Zugriff auf das Terminal des Agenten, der gerade arbeitet. Der Run selbst läuft weiterhin auf Ihrem Desktop, über die echten CLIs, genau so, als hätten Sie ihn dort gestartet.

Frag dich, woran der Run scheitern würde. Wenn er daran scheitern würde, den Faden zu verlieren, nimm Relay: Eine Session spielt jede Rolle und erklärt sich eine Entscheidung nie neu. Wenn er daran scheitern würde, sich selbst zuzustimmen, nimm Team: Die Rollen laufen als getrennte Agenten, also ist der, der den Code prüft, nicht der, der ihn geschrieben hat. Relay ist die Voreinstellung, weil es genau das ist, was jedes vor dieser Einstellung gebaute Team ohnehin schon tut, nicht weil es besser wäre.

Nein. Ein Teamkollege startet beim ersten Mal, wenn er gebraucht wird, entweder weil der Graph seinen Schritt erreicht oder weil ihm ein anderer Agent schreibt, und bleibt danach für den Rest des Runs am Leben. Ein Team mit vier Rollen verbrennt also keine vier Sessions, um eine Frage zu beantworten, die nur zwei davon betrifft, und eine Rolle, die in Zyklus drei angeschrieben wird, ist immer noch derselbe Agent, der in Zyklus eins geantwortet hat.

Nur an das, was er lesen kann. Ein Teamkollege, der mitten im Run dazukommt, hat seine eigene Session und keine Erinnerung an die Arbeit, und genau deshalb ist seine Meinung etwas wert. Er holt über die geteilten Notizen, die Timeline des Runs und den Git-Diff seit Beginn des Runs auf, und all das liest er mit seinen eigenen Tools. Dieses Lesen ist der Preis des Modus, und es ist der Grund, warum es den Relay-Modus weiterhin gibt.

Ja, und das ist die Voreinstellung. Bei ausgeschaltetem freiem Gespräch darf ein Teamkollege nur an die Rollen schreiben, auf die sein Knoten im Graphen zeigt, ein Gate lässt sich also nicht umgehen, indem man jemand anderen fragt. Schalte es ein, wenn du ein echtes Team willst: Jeder schreibt an jeden, in jede Richtung und an mehrere gleichzeitig. Der Graph startet den Run in beiden Fällen weiterhin und beendet ihn weiterhin.