Agent Teams.
Eine echte Tech-Crew, scripted.
AgentsRoom Teams verkettet deine KI-Coding-Agenten wie ein echtes Engineering-Team. Ein Fullstack Dev liefert das Feature, ein QA Engineer validiert es, ein PM signiert es ab. Jede Rolle ist scripted, der Workflow ist visuell, und jeder Handoff transportiert die Feature-Zusammenfassung, den Diff, die Risiken und die Test-Hinweise. Schluss mit dem einzelnen Agenten, der alles schlecht macht.
Bau dein KI-Dev-Traumteam auf einem visuellen Canvas, genau wie einen n8n-Workflow. Konditionale Edges, Feedback-Loops, Retries, Max-Cycles-Guard. Einmal speichern, auf jedem Ticket laufen lassen, und zusehen, wie deine Agenten den Staffelstab uebergeben wie Seniors.
AgentsRoom Teams: visueller Multi-Agent-Workflow-Editor, automatischer Handoff zwischen Claude Code Agenten, Dev zu QA Feedback-Loop, MCP-basierte Inter-Agent-Kommunikation.
Agent Teams ist die AgentsRoom Antwort auf eine brutale Wahrheit ueber KI-Coding-Agenten: ein einzelner Agent, der alles versucht, macht am Ende alles schlecht. Der Fullstack-Agent, der gleichzeitig codet, testet, reviewt, deployt und die Spec schreibt, vergisst auf halber Strecke die Haelfte seiner Anweisungen. Die richtige Antwort, die jedes ernsthafte Software-Team weltweit nutzt, ist die Arbeit in Rollen aufzuteilen. Ein Entwickler codet. Ein QA Engineer validiert. Ein Product Manager signiert ab. Ein Security Reviewer auditiert. Jede Rolle hat ihren eigenen Kontext, ihren eigenen Fokus, ihr eigenes Tooling.
Genau das bringt Agent Teams zu AgentsRoom. Du legst Nodes auf einem unendlichen Canvas ab (basiert auf React Flow, derselben Engine wie n8n, Make, Retool und Pipedream), jeder Node ist ein Claude Code, Codex, OpenCode, Gemini CLI oder Aider Agent, der einer spezifischen Rolle zugewiesen ist, und du verdrahtest sie. Lass das Team auf einem Ticket aus deinem Backlog laufen, oder haenge es an einen neuen Agent-Spawn an. AgentsRoom orchestriert die Kette: ersten Agenten spawnen, auf den Handoff warten, die Arbeit zusammenfassen, naechsten Agenten mit dieser Zusammenfassung als Eingangskontext spawnen, wiederholen bis das Team den Endknoten erreicht.
Andere Tools versuchen das mit einem einzigen Super-Agenten und cleveren Prompts. Wir haben es probiert, es funktioniert nicht ueber drei Schritte hinaus. Rollen driften, Kontext geht verloren, der Agent vergisst, was er verifizieren sollte. Agent Teams behandelt die Agenten als echte Teamkollegen: jeder bekommt eine saubere Session, einen fokussierten System-Prompt, einen strukturierten Handoff-Payload und einen geteilten Scratchpad, um mit den anderen zu reden. Das ist der KI-Engineering-Team-Workflow, den du wirklich willst.
AgentsRoom Teams Editor: Nodes fuer jede Rolle ablegen, verdrahten, Bedingungen hinzufuegen, Team speichern, auf jedem Ticket laufen lassen.
Multi-Agent-Orchestrierung, die wirklich skaliert
Jeder Node auf dem Canvas ist ein Agent. Du waehlst seine Rolle (Fullstack, Frontend, Backend, QA, Security, DevOps, PM, Architect, Mobile, Marketing, Git, SEO, Localization, oder eine beliebige Custom-Rolle, die du erstellt hast), sein Modell (Opus, Sonnet, Haiku, GPT-5, o3, Gemini Pro, etc.), seinen Handoff-Modus (auto via Stop-Hook oder manuell via Button) und ein paar Zeilen schrittspezifischer Anweisungen. Das war's. Keine Prompt-Engineering-Zeremonie, keine YAML-Config-Datei zu schreiben.
Edges verbinden die Nodes. Eine einfache Edge bedeutet: wenn der erste Agent seinen Schritt beendet, uebergib an den naechsten. Eine konditionale Edge traegt einen Flag-Check, zum Beispiel qaPassed equals true. Der QA-Agent setzt das Flag in seinem Handoff-Payload, der Runner waehlt die passende Edge. So baust du Feedback-Loops: QA fertig, qaPassed equals false, Edge sendet zurueck zum Dev mit den Test-Hinweisen und Risiken. Dev fixt, uebergibt erneut. Loop bis QA besteht oder bis der Max-Cycles-Guard greift.
Inter-Agent-Kommunikation ist robust by design. AgentsRoom liefert einen dedizierten MCP-Server (agentsroom-team), der jedem Agenten im Run ein Set von Tools gibt: Team-Kontext lesen, geteilten NOTES.md-Scratchpad lesen, Notiz fuer Teamkollegen posten, Frage an eine andere Rolle senden, Inbox lesen, Timeline lesen, Git-Diff gegen die Run-Baseline lesen, und den Schritt mit einem strukturierten Payload abschliessen. Diese Tools werden bei jedem Turn erneut in die Claude-Session injiziert, damit sie die Kontext-Kompaktierung ueberleben. Selbst nach einem /compact oder /clear sieht der Agent immer noch seine Team-Tools.
Zusaetzlich erinnert ein UserPromptSubmit-Hook den Agenten vor jeder User-Message an neue Notizen von Teamkollegen. Eine NOTES.md-Datei im Workspace ist append-only und ueberlebt Crashes, Restarts und Mac-Reboots. Ein server-seitig validiertes Handoff-Payload-Schema verhindert, dass Agenten leere oder Junk-Payloads uebergeben. Das ist der Teil, den die meisten Multi-Agent-Demos still ueberspringen, und der Grund, warum die meisten bei Cycle 3 zerfallen.
Alles, was du brauchst, um eine KI-Engineering-Crew zu betreiben
Visueller Workflow, echter Handoff, echte Feedback-Loops, echte Inter-Agent-Kommunikation. Gebaut, damit du ein Feature in einem Slack-Ping statt in fuenfzig lieferst.
Visueller Workflow-Canvas
Unendlich zoombarer Canvas mit React Flow als Engine, derselben Engine hinter n8n, Retool, Pipedream und Make. Nodes ablegen, verbinden, Team speichern. Kein Code, kein YAML.
14 eingebaute Agent-Rollen
Fullstack, Frontend, Backend, DevOps, QA, Security, PM, Architect, Mobile, Marketing, Git Expert, SEO, i18n. Plus jede Custom-Rolle, die du bereits in deinem Projekt gespeichert hast.
Modell und Prompt pro Node
Jeder Node waehlt seinen Provider, sein Modell und seine Schritt-Anweisungen. Nutze Opus fuer Architect, Haiku fuer QA, Codex fuer das schwere Backend, Gemini fuer das billige Frontend. Mix and match.
Automatischer Handoff
Wenn ein Agent team_complete_step aufruft, baut AgentsRoom den Handoff-Payload (Feature-Zusammenfassung, geaenderte Dateien, Risiken, Test-Hinweise, Flags) und spawnt den naechsten Node mit diesem Payload als Startkontext.
Manuelle Handoff-Option
Lieber jeden Schritt validieren? Schalte den Node in den manuellen Modus. Der Agent wartet, du klickst 'Hand off', wenn du mit dem Ergebnis zufrieden bist. Das Beste aus beiden Welten.
Konditionale Edges
Jede Edge kann einen Flag-Check tragen (z.B. qaPassed equals true). Bau Branches: wenn QA besteht, geh zum PM, sonst Loop zurueck zum Dev. Echte Workflow-Logik, kein Scripting.
Feedback-Loops
Dev zu QA zu Dev zu QA. Wenn QA das Ticket zurueckschickt, wird der originale Dev-Agent mit voller Erinnerung an den vorherigen Cycle wiederverwendet, sodass er die Regression wirklich fixt, anstatt von vorn anzufangen.
Max-Cycles-Guard
Konfigurierbare Obergrenze (Standard 3). Vermeidet unendliche QA-lehnt-Dev-ab Loops. Wenn die Grenze erreicht ist, pausiert der Run auf awaiting-finalization und du entscheidest, was als Naechstes passiert.
Geteilter NOTES.md-Scratchpad
Jeder Agent im Run liest und schreibt eine Markdown-Datei im Workspace. Ueberlebt Kompaktierung, Crash, Restart. Die einzige Wahrheitsquelle fuer das Reasoning des Teams.
Rolle-zu-Rolle-Inbox
Brauchst du, dass der QA mitten im Run eine Frage an den Architect stellt? team_ask postet eine Nachricht in die Inbox der Rolle. Der naechste Agent dieser Rolle liest sie und antwortet. Echter Chat zwischen Agenten.
MCP-basierte Inter-Agent-Kommunikation
Alle Team-Tools werden ueber einen MCP-Server exponiert. Tools ueberleben Claude-Kontext-Kompaktierung (Anthropic schickt sie bei jedem Turn neu). Resilient gegen /clear, /compact und lange Loops.
Haiku-Powered Handoff-Zusammenfassung
Wenn ein Agent keine eigene Feature-Zusammenfassung schreibt, generiert ein kleiner Haiku-Call eine aus dem Git-Diff. Billig, schnell, und der naechste Agent landet immer mit Kontext.
Browser MCP Propagation
Ein Team-Node mit verifyInBrowser schaltet seinen Agenten automatisch in den Browser-Access-Modus. Der QA-Node landet mit allen Browser-Tools (navigate, click, type, screenshot, get logs).
Ephemere Agenten pro Run
Jeder Team-Run spawnt frische Agenten und zerstoert sie beim Dismiss. Deine Projekt-Agentenliste bleibt sauber. Das Team ist der Workflow, die Agenten sind die Runtime.
Globale und Projekt-Teams
Speichere wiederverwendbare Teams in deiner globalen Bibliothek (~/.agentsroom/teams) oder pinne sie an ein bestimmtes Projekt (mit der Room committed). Gleicher Editor, anderer Scope.
Team-Templates inklusive
Drei Seed-Templates kommen mit der App: Dev zu QA, Dev zu QA mit Feedback-Loop und Dev zu Security zu QA. Duplizieren, editieren, ausfuehren. Start in 30 Sekunden.
Run-Timeline-UI
Jeder Handoff erscheint als Karte in der Run-Timeline: welche Rolle gerade fertig ist, was die Zusammenfassung sagt, welche Dateien sich geaendert haben, welche Flags gesetzt wurden. Auditierbar, abspielbar.
Auf jedem Backlog-Ticket laufen lassen
Lege ein Ticket auf ein Team und die Kette startet auf diesem Ticket. Der erste Agent liest Titel und Body des Tickets, der Rest des Teams uebernimmt von dort.
14 spezialisierte Rollen, bereit zum Verdrahten
Jede Rolle hat ihren eigenen System-Prompt, Fokusbereiche und Beispielaufgaben. Mische und kombiniere sie auf dem Canvas. Fuege jederzeit eigene Custom-Rollen hinzu.
Warum ein echtes Team einen Super-Agenten schlaegt
Multi-Agent-Orchestrierung klingt wie ein Buzzword. Hier ist der praktische Unterschied, an einem Feature, das du wirklich liefern wuerdest.
Szenario: einen Stripe-Checkout-Flow zu einer E-Commerce-Site hinzufuegen
Solo Super-Agent
- • Liest das Ticket. Schreibt 600 Zeilen ueber API, React-Form, Webhook, Migration und Tests verteilt.
- • Vergisst den Idempotency-Key am Webhook. Vergisst, den Failure-Pfad zu testen. Vergisst die Staging-Env-Variable.
- • Sagt 'Done'. Du verbringst zwei Stunden damit, Bugs in Produktion zu jagen.
Agent Team (Dev zu Security zu QA)
- • Fullstack-Agent liefert die Implementierung, committed, uebergibt mit einer Zusammenfassung und einer Risikoliste, die die Auth-Aenderung markiert.
- • Security-Agent liest den Diff, auditiert die Webhook-Signatur-Pruefung, schreibt Test-Hinweise fuer den QA in den Handoff-Payload.
- • QA-Agent fuehrt die Test-Hinweise im eingebetteten Browser aus, stoesst auf einen Idempotency-Bug, setzt qaPassed equals false, schickt das Ticket zurueck zum Dev mit der exakten Reproduktion.
- • Dev fixt, uebergibt erneut. QA besteht. Der PM finalisiert. Run geht auf done.
Gleiches Ticket, gleiche Modelle, gleiches Projekt. Andere Form der Arbeit. Der Team-Ansatz faengt das ab, was der Solo-Agent verpasst, weil jede Rolle einen fokussierten Brief und einen strukturierten Handoff hat.
Wie ein Team-Run funktioniert
Oeffne den Teams-Tab
In deiner Projektansicht listet der Teams-Tab drei Seed-Templates (Dev zu QA, Dev zu QA mit Feedback-Loop, Dev zu Security zu QA) plus jedes Team, das du bereits gespeichert hast. Dupliziere ein Template oder klicke auf 'Neues Team'.
Bau den Workflow auf dem Canvas
Lege Agent-Nodes auf dem React Flow Canvas ab. Fuer jeden Node waehle die Rolle (Fullstack, QA, Security, PM, etc.), den Provider, das Modell und ein paar Zeilen Schritt-Anweisungen. Verdrahte sie mit Edges. Fuege Bedingungen an Edges hinzu, wenn du Branching brauchst.
Dev → QA → PMSetze den Handoff-Modus pro Node
Auto-Handoff: der Agent ruft team_complete_step auf, wenn seine Arbeit fertig ist, der Runner uebernimmt. Manueller Handoff: der Agent wartet, bis du auf 'Hand off' klickst. Mische beide nach Bedarf.
Lass das Team laufen
Aus einem Backlog-Ticket klicke 'Run with team'. Aus einem leeren Agent-Slot klicke 'Create as team'. Der erste Node spawnt als ephemerer Agent im Projekt-Workspace.
Beobachte den Handoff
Wenn Agent N fertig ist, baut AgentsRoom den Handoff-Payload (Feature-Zusammenfassung via Agent oder via Haiku, Git-Diff, Risiken, Test-Hinweise, Flags), haengt eine Notiz an NOTES.md an, waehlt die richtige ausgehende Edge basierend auf den Flags und spawnt Agent N+1 mit diesem Payload als Eingangskontext.
Loop, Ende, Finalisierung
Feedback-Loops gehen erneut in den originalen Agenten (volle Erinnerung erhalten). End-Node triggert awaiting-finalization. Du klickst 'Finish run'. Banner verwerfen, um die Agenten zu zerstoeren und die PTYs freizugeben.
Inter-Agent-Kommunikation, die alles ueberlebt
Das Detail, das die meisten Multi-Agent-Demos ueberspringen. Hier ist, was Agent Teams ueber lange Runs und viele Cycles haelt.
Claude Code Agenten haben ein Kontextfenster und sie kompaktieren es. Der klassische Fehler von Multi-Agent-Systemen ist, die Team-Koordination nur in den System-Prompt zu legen. Nach zwei /compact-Cycles hat der Agent keine Ahnung mehr, dass er in einem Team ist. AgentsRoom macht das nicht.
Die gesamte Team-Koordination lebt an drei Orten, die Kompaktierung ueberleben. Erstens, ein MCP-Server (agentsroom-team) exponiert Tools (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_ask, team_read_timeline, team_read_diff, team_complete_step). MCP-Tools werden von der CLI bei jedem Turn neu an Claude geschickt, sodass sie immun gegen Kontext-Kompression sind.
Zweitens, ein UserPromptSubmit-Hook laeuft vor jeder User-Message und prependet eine kleine Erinnerung, wenn neue Notizen oder neue Inbox-Nachrichten fuer diese Rolle vorhanden sind. Billig, wenn nichts passiert, entscheidend, wenn doch.
Drittens, NOTES.md und state.json leben auf der Platte im Workspace. Der Agent kann sie jederzeit mit einem einfachen Read oder mit team_read_notes erneut lesen. Sie ueberleben Crashes, Restarts, /clear, /compact und Mac-Reboots. Der System-Prompt ist niemals die Wahrheitsquelle, die Platte und die MCP-Tools sind es.
Was Leute mit Agent Teams bauen
Dev zu QA Pipeline
Der Klassiker. Fullstack liefert das Feature. QA validiert es im eingebetteten Browser, fuehrt die Test-Hinweise aus, signiert ab. Zwei-Node-Team, laeuft auf jedem Ticket aus dem Backlog.
Dev zu QA mit Feedback-Loop
Wie oben, aber mit einer konditionalen Edge: qaPassed equals false schickt das Ticket zurueck zum Dev mit den Test-Hinweisen. Max 3 Cycles. Faengt Regressionen, bevor sie einen menschlichen Reviewer erreichen.
Dev zu Security zu QA
Fuer Features, die Auth, Zahlungen oder PII beruehren. Security-Agent reviewt den Diff, markiert Risiken, schreibt Test-Hinweise fuer QA. Genutzt von Teams, die Fintech, Healthtech und B2B-SaaS liefern.
PM zu Architect zu Dev
Spec-First-Workflow. PM-Agent verwandelt das Ticket in eine strukturierte Spec. Architect waehlt den Ansatz. Dev implementiert. Drei Rollen, saubere Trennung, nachverfolgbare Entscheidungen.
Frontend, Backend, DevOps Fan-out
Sequenzielle Aufteilung fuer Full-Stack-Features. Frontend liefert die UI. Backend liefert die API. DevOps fuegt die Infra-Config hinzu. Jede Rolle arbeitet in ihrem Bereich, uebergibt mit einem sauberen Diff.
Marketing zu SEO zu i18n
Ja, AgentsRoom Teams ist nicht nur fuer Code. Marketing schreibt das Landing-Copy. SEO injiziert die Keywords. Localization uebersetzt in 14 Sprachen. Ein Team, ein Ticket, ein Ship.
Wie es sich gegen andere Multi-Agent-Ansaetze schlaegt
Multi-Agent-Orchestrierung ist ein ueberlaufenes Buzzword. Hier ist, was wirklich liefert, und wo AgentsRoom Teams hinpasst.
Anthropic Subagents (Task-Tool, .claude/agents) lassen eine einzelne Claude-Session an spezialisierte Helfer-Agenten delegieren. Grossartig fuer Inline-Delegation, aber die Parent-Session bleibt der Koordinator und ein einzelner Kontext. AgentsRoom Teams ist eine Stufe darueber: jeder Team-Node ist eine separate Top-Level-Claude-Session mit eigenem Fenster, eigenem State, eigenem Scrollback. CrewAI, AutoGen und LangGraph sind exzellente Python-Frameworks fuer Multi-Agent-Flows, aber sie leben ausserhalb deiner IDE und fuehren keine echten Claude Code, Codex oder Gemini CLIs end-to-end auf deinem lokalen Repo aus. n8n, Make, Pipedream und Retool liefern dieselbe Art Canvas-Editor, den wir nutzen, aber sie sind universelle Automatisierungsplattformen, nicht fuer KI-Coding-Agenten gebaut. AgentsRoom Teams ist der Canvas-Style Multi-Agent-Workflow-Editor, aber spezifisch verdrahtet zu deinen CLI-Agenten, deinem Projekt, deinem Git, deinen Terminals und deinem Browser.
Wenn du agentische Systeme in Python baust, bleib bei CrewAI oder LangGraph fuer Production-Pipelines. Wenn du Code mit Claude Code, Codex CLI, OpenCode, Gemini CLI oder Aider lieferst, ist Agent Teams der Team-Workflow, der dort laeuft, wo du wirklich codest.
FAQ
Wie unterscheidet sich das von Claude Code Subagents (Task-Tool, .claude/agents)?
Claude-Subagents sind Inline-Delegationen von einer einzelnen Parent-Claude-Session. Der Parent entscheidet, wann ein Subagent aufgerufen wird, der Subagent laeuft in einem isolierten Kontextfenster, gibt ein Ergebnis zurueck, und der Parent macht weiter. AgentsRoom Teams ist eine Stufe darueber: 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 aendern und fortsetzen. Es ist kein Ersatz fuer Claude-Subagents, du kannst absolut beide nutzen. Ein Team-Node kann intern Subagents nutzen.
Funktioniert das nur mit Claude Code?
Es funktioniert mit jedem von AgentsRoom unterstuetzten Provider (Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider). Jeder Team-Node waehlt seinen eigenen Provider und sein Modell. Die MCP-basierten Team-Koordinationstools funktionieren providerueberreifend identisch, weil sie ueber 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.
Was ist ein Handoff-Payload?
Ein strukturiertes Objekt, das von einem Agenten zum naechsten reist. Felder: featureSummary (eine kurze Beschreibung dessen, was gerade geliefert wurde), changedFiles (git diff name-status), touchedAreas (UI, API, DB, Config), risks (alles, worueber sich der naechste Agent Sorgen machen sollte), testHints (Prioritaeten fuer 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 naechste Agent erhaelt ihn als seinen Startkontext.
Koennen Agenten wirklich hin- und hergehen (Dev zu QA zu Dev)?
Ja. Wenn ein Node erneut betreten wird (Cycle groesser 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 behaelt seine volle Claude-Session-Erinnerung an die vorherigen Cycles. Das ist kritisch: ein Dev-Agent, der schon weiss, was QA letztes Mal markiert hat, fixt den Bug. Ein frischer Dev-Agent ohne Erinnerung wuerde einfach denselben Fehler wiederholen.
Was passiert, wenn QA Dev fuer immer ablehnt?
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 uebergeben oder alles abbrechen. Keine unendlichen Loops, keine Ueberraschungsrechnungen ueber Nacht.
Teilen sich alle Team-Agenten denselben Git-Workspace?
Ja. Das Team laeuft in einem einzigen Workspace und einem einzigen Branch (oder Worktree, wenn du das AgentsRoom-Worktrees-Feature nutzt). Jeder Agent sieht die Arbeit des vorherigen ueber Git. Der Handoff-Payload enthaelt einen Git-Diff gegen die Run-Baseline, sodass der naechste Agent genau weiss, was neu ist.
Braucht das ein extra Abo?
Nein. Teams sind Teil von AgentsRoom. Du bringst deine eigenen Provider-Keys mit (Claude, Codex, OpenCode, Gemini, Aider) und zahlst nur fuer 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.
Wo werden Teams gespeichert? Werden sie in Git committed?
Projekt-skopierte Teams leben mit der Room, in die Cloud synchronisiert und in {project}/.agentsroom/teams-cache.json (gitignored) gecached. Globale Teams leben in ~/.agentsroom/teams/{teamId}.json auf deiner Maschine, eine Datei pro Team. Du entscheidest, welcher Scope zu welchem Workflow passt.
Was, wenn ein Agent crasht oder die App mitten im Run neu startet?
Der Run-State wird auf der Platte in {workspace}/.agentsroom/team-runs/{runId}/ persistiert (state.json, NOTES.md, inbox/, timeline.jsonl). NOTES.md ist append-only, jeder State-Write ist atomar. Agenten koennen jederzeit alles erneut lesen mit team_read_notes oder team_get_context. Die Orchestrierungsschicht wird gerade gehaertet, um einen unterbrochenen Run beim App-Restart vollstaendig abzuspielen, aber die On-Disk-Story ist bereits crash-safe.
Kann ich mehrere Teams parallel auf verschiedenen Tickets laufen lassen?
Ja. Jeder Team-Run ist unabhaengig und durch seine runId identifiziert. Du kannst ein Dev zu QA Team auf Ticket A laufen haben, ein Dev zu Security zu QA Team auf Ticket B und ein PM zu Architect zu Dev Team auf Ticket C, alle live im gleichen Projekt. Innerhalb eines einzelnen Runs ist die Ausfuehrung sequenziell (ein Node aktiv zur Zeit) fuer Vorhersagbarkeit.
Bau dein KI-Dev-Traumteam
Drei Templates kommen mit der App. Oeffne AgentsRoom, lege Nodes ab, zeichne Edges, lass auf jedem Ticket laufen. Deine KI-Engineering-Crew ist einen Klick entfernt.
Companion-App: Agenten auch unterwegs im Blick behalten
Funktioniert mit Claude, Codex, OpenCode, Gemini CLI und Aider
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.