Sharkly Crews: KI-Agenten-Teams mit einem Leiter, der delegiert

Der erste KI-Agent in einem Team erhöht den Durchsatz. Der zweite schafft ein Koordinationsproblem. Jemand muss entscheiden, welcher Agent die API-Änderung übernimmt, wer die Tests schreibt, ob das Refactoring auf die Schema-Migration wartet und wer das kombinierte Ergebnis prüft, bevor ein Mensch es abnimmt. In den meisten Teams ist dieser Jemand ein Senior Engineer mit je einem Terminal in jeder Hand – und diese Rolle skaliert nicht.

Sharkly Crews gibt es genau für diesen Moment. Eine Crew ist eine wiederverwendbare Gruppe aus Personen und Agents, die von einem Leader-Agent koordiniert wird, und sie lebt in Sharkly, der Plattform, die Agent-Arbeit in einem gemeinsamen Task-System hält. Statt dass eine Person jeden Teil-Task per Hand weiterleitet, weist du den Task der Crew zu. Der Leader-Agent liest das Ziel, entscheidet, welche Mitglieder beitragen sollen, und bringt ihre Ergebnisse an einer Stelle zusammen, die dein Team prüfen kann.

Diese Anleitung erklärt, was eine Crew ist, wann ein einzelner Agent die bessere Wahl ist, wie sich die Leader-First-Ausführung von Run zu Run verhält und wie du eine Crew aufsetzt, die dein Team auch in drei Monaten noch nutzt.

TL;DR

Eine Crew in Sharkly ist eine wiederverwendbare Gruppe aus Personen und Agents, die von einem Leader-Agent koordiniert wird. Du weist der Crew einen Task zu, der Leader startet zuerst, interpretiert das Ziel, delegiert Teilaufgaben per Mention an Agent-Mitglieder und führt ihre Ergebnisse auf dem Task zusammen. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.

Was ist eine Crew in Sharkly?

Eine Crew ist ein benanntes, wiederverwendbares Team: Personen und Agents, die sich um eine gleichbleibende Art von Arbeit gruppieren, mit einem Leader-Agent, der die Ausführung koordiniert. Während ein einzelner Agent eine gespeicherte Arbeitskonfiguration für eine Rolle ist, hält eine Crew fest, wie mehrere Rollen zusammenarbeiten – so kann ein komplexer Task dem Team statt einem einzelnen Ausführenden zugewiesen werden.

Jede Crew umfasst:

• einen Namen, eine Beschreibung und optionale Crew-Anweisungen
• einen Owner, also eine Person in der Organisation, die die Crew verwaltet
• einen Leader, der ein Agent im Space der Crew sein muss
• Agent- und Personen-Mitglieder, die an diesem Space teilnehmen können
• einen Space, dem die Crew gehört
• Sichtbarkeit auf Personal- oder Space-Ebene
• eine optionale Einstellung für ein gemeinsames Task-Verzeichnis

Zwei Grenzen sind vor allem anderen wichtig.

Der Owner ist nicht der Leader. Der Owner ist eine Person, die die Crew verwaltet: ihre Mitglieder, ihre Einstellungen, ihre Sichtbarkeit. Der Leader ist ein Agent und koordiniert weiterhin die Ausführung. Wer den Owner als Ersatz für den Leader-Agent begreift, verwechselt beide Rollen.

Mitgliedschaft ist keine Ausführung. Die Mitgliedschaft von Personen hält fest, wer an der Crew teilnimmt, aber nur Agent-Mitglieder können Agent-Runs starten. Eine Person in einer Crew arbeitet weiter wie bisher: über Task-Kommentare, Review und Chat. Der Beitritt zu einer Crew macht einen Menschen nicht zum Ziel eines Runs.

Der Leader wird automatisch als Mitglied hinzugefügt, trägt die Leader-Rolle und kann nicht entfernt werden, solange er die Crew leitet. Andere Mitglieder können Rollen-Labels tragen, die ihren Beitrag beschreiben – etwa Backend, Tests oder Docs –, was dem Leader beim Delegieren konkrete Anhaltspunkte gibt.

Wann solltest du eine Crew statt eines einzelnen Agents verwenden?

Dieses Entscheidungspaar stammt direkt aus der Sharkly-Dokumentation und sollte wörtlich genommen werden. Bei kleinen, klar umrissenen Arbeiten weist du den Task direkt einem Agent zu. Eine Crew nutzt du, wenn der Leader das Ziel interpretieren, weitere Agent-Mitglieder einbeziehen und ihre Ergebnisse in einem Task oder Gespräch zusammenführen muss.

Ein einzelner Agent ist die richtige Wahl, wenn:

1. die Arbeit zu einer Rolle passt, etwa ein Bugfix in einem Service.
2. der Umfang bereits klar ist und keine Zerlegung nötig ist.
3. du möglichst wenige bewegliche Teile zwischen Zuweisung und Review willst.
4. du noch an den Anweisungen eines einzelnen Agents feilst und ein klares Signal willst.

Eine Crew verdient ihren Platz, wenn:

1. das Ziel mehrere Rollen umfasst, etwa ein Feature, das Änderungen an Backend, Frontend und Tests erfordert.
2. jemand die Reihenfolge der Beiträge festlegen muss und dieser Jemand ein Agent sein soll statt eine Person mit zwei offenen Terminals.
3. sich dieselbe Kombination von Spezialisten für jede neue Anfrage neu formiert.
4. Ergebnisse mehrerer Agents auf einem Task landen müssen, statt sich über private Sessions zu verteilen.

Wenn dein Team noch abwägt, ob Multi-Agent-Arbeit überhaupt strukturiert werden sollte, behandelt die Einführung in die KI-Agent-Orchestrierung die Abwägungen von Grund auf. Die Kurzfassung: Ein zweiter Agent ist billig, ungesteuerte Koordination zwischen Agents ist es nicht.

Wie die Leader-First-Ausführung funktioniert

Wenn du einer Crew einen Task zuweist, folgt die Ausführung einer Leader-First-Sequenz:

1. Der Task wird über das Assignee-Feld der Crew zugewiesen, wie jedem anderen Assignee.
2. Befindet sich der Task in einem ausführbaren Status und ist der Leader bereit, startet der Leader-Agent zuerst.
3. Der Leader liest den Task-Kontext und die Crew-Anweisungen.
4. Der Leader erledigt die Arbeit entweder selbst oder spricht geeignete Agent-Mitglieder für bestimmte Beiträge per Mention an.
5. Erwähnte Agent-Mitglieder laufen gegen denselben Task und fügen ihre Ergebnisse dem Chat hinzu.
6. Der Leader koordiniert weiter und führt die Ergebnisse zusammen.

Das Designziel hinter dieser Sequenz ist Zurückhaltung. Die Leader-First-Ausführung verhindert, dass alle Agent-Mitglieder gleichzeitig starten. Sie gibt dem Leader außerdem die Chance, fehlenden Kontext zu erkennen, die richtigen Teilnehmer auszuwählen und die Reihenfolge der Arbeit zu steuern. Eine Crew ohne Leader wäre ein Fan-out-Knopf; mit Leader ist sie ein Team, das nachdenkt, bevor es die Arbeit aufteilt.

Backlog verhält sich genauso wie bei einzelnen Agents: Ein Task im Backlog startet den Leader nicht. Das Backlog ist ein Abstellbereich, in dem Arbeit vorbereitet wird, und erst der Wechsel des Tasks in einen ausführbaren Status startet die Crew. Eine Zuweisung löst nie überraschend Arbeit aus.

Alles, was die Mitglieder produzieren, landet wieder auf dem Task: Run-Status, Ergebnisse und die Diskussion darüber. Genau darum geht es, ein Team in Sharkly zu betreiben statt über fünf Terminals verteilt. Kontext, Fortschritt, Blocker, Ergebnisse und menschliches Review bleiben von der Anfrage bis zum Release sichtbar – egal, ob ein Agent die Arbeit erledigt hat oder vier.

Ein technischer Hinweis für Teams, die Mitglieder parallel laufen lassen: Jeder Agent-Run bekommt standardmäßig weiterhin sein eigenes isoliertes Arbeitsverzeichnis, damit sich die Mitglieder nicht gegenseitig über die Dateien stolpern. Das Isolationsmodell ist Thema in wie Sharkly Agents parallel ohne Merge-Konflikte ausführt.

Ownership, Sichtbarkeit und wer eine Crew nutzen darf

Personen mit der Berechtigung, gemeinsame Ressourcen in einem Space zu erstellen, können dort eine Crew anlegen. Jede Crew gehört zu einem Space, und ihre Sichtbarkeit steuert, wer sie finden und nutzen kann:

Die Sichtbarkeit gilt für die Crew selbst, für den Crew-Chat und für die Auswahl als Task-Assignee. Eine Personal-Crew wird von ihrem Owner verwaltet, und wenn der Owner einer privaten Crew wechselt, verliert der vorherige Owner den Verwaltungszugriff. Diese Übergaberegel ist wichtig, wenn die Person, die eine Crew aufgebaut hat, das Team wechselt: Übertrage das Ownership bewusst, statt die Lücke später zu entdecken.

Wenn eine Crew ihren Zweck erfüllt hat, archiviere sie, statt den Verlauf zu löschen. Eine archivierte Crew erhält keine neuen Zuweisungen mehr, während ihr bestehender Verlauf verfügbar bleibt. Prüfe vor dem Archivieren, ob aktuelle Tasks oder Automations die Crew noch nutzen, und verschiebe diese Arbeit zuerst zu einem anderen Assignee. Dieselbe Abhängigkeitsprüfung gilt, bevor du einen Agent archivierst, der zu einer Crew gehört.

Crew-Chat: Koordination, bevor es einen Task gibt

Nicht jede Diskussion verdient am ersten Tag einen Task. Den Crew-Chat gibt es für das Gespräch, das vor dem Work Item kommt: ein Problem erkunden, die richtigen Teilnehmer finden, einen Plan formen.

Jede Person erhält eine dauerhafte Chat-Session mit der Crew, und der Leader-Agent ist der erste Chat-Partner. Der Leader kann Agent-Mitglieder erwähnen, sodass ihre Antworten im selben Chat erscheinen – so kannst du dem Team beim gemeinsamen Denken zusehen, bevor du dich auf etwas festlegst.

Die Grenze ist hart und sollte man sich merken: Der Crew-Chat erstellt keinen Task. Wenn aus der Diskussion konkrete Arbeit wird, erstelle einen Task und weise die Crew zu, damit Status, Kommentare, Runs und Abnahme am Work Item hängen bleiben. Ein Schluss, der nur in einer Chat-Session lebt, ist ein Schluss, den dein Team verlieren wird. Der gemeinsame Datensatz ist der Task, und Ergebnisse müssen dorthin zurück.

Die Task-Detailansicht hat außerdem Quick Chats in der Kopfzeilen-Toolbar. Ein Quick Chat führt einen ausgewählten Agent oder eine Crew mit dem aktuellen Task als Kontext in einer geteilten Ansicht neben dem Task aus. Das ist eine praktische Möglichkeit, eine Crew zu fragen: „Was würdest du damit machen?“, bevor du sie formell zuweist.

Fortgeschrittene Crew-Techniken

Crew-exklusive Agents: Spezialisten, die nirgendwo sonst arbeiten

Manche Agents ergeben nur im Team Sinn. Ein Merge-Koordinator, der davon ausgeht, dass drei weitere Mitglieder existieren, oder ein Reviewer, der auf die Konventionen einer bestimmten Crew abgestimmt ist, sollte nicht in der allgemeinen Agent-Auswahl der Organisation auftauchen, wo ihm jemand Solo-Arbeit zuweisen könnte, für die er nie gedacht war.

Wenn du einen Agent als Crew-exklusiv markierst, beschränkst du ihn auf die Crew. Nachdem die Einstellung aktiv ist:

• kann der Agent nur innerhalb der aktuellen Crew aufgerufen werden
• kann er nicht für einen privaten Chat genutzt oder ihm eigenständig ein Task zugewiesen werden
• verschwindet er aus „Meine Agents“, dem Verzeichnis, der Agent-Liste der Organisation und der Assignee-Auswahl

Exklusivität ist eine Geltungsgrenze des Agents, keine Crew-Rolle. Das Rollen-Label beschreibt, was das Mitglied tut; die Exklusivität beschreibt, wo der Agent aufgerufen werden kann. Ein Crew-exklusiver Agent gehört höchstens einer Crew gleichzeitig an – sitzt er also bereits in einer anderen Crew, entferne ihn dort zuerst. Das Aufheben der Exklusivität stellt die normale Sichtbarkeit und Zuweisbarkeit wieder her, und historische Tasks und Chats bleiben in beiden Fällen erhalten. Blockiert werden nur neue private Chats und neue Solo-Zuweisungen.

Gemeinsames Task-Verzeichnis: wenn Mitglieder auf denselben Dateien aufbauen müssen

Standardmäßig gilt Isolation: Getrennte Runs bekommen getrennte Verzeichnisse. Eine Crew kann das bewusst lockern. Ist die Einstellung für das gemeinsame Task-Verzeichnis aktiv, kann ein späterer Crew-Agent-Run für denselben Task das zuletzt geeignete Verzeichnis auf diesem Computer wiederverwenden und die lokalen Änderungen erhalten, die ein früheres Mitglied hinterlassen hat.

Zwei Einschränkungen halten das sicher. Geteilt wird nur der Dateisystem-Zustand, nicht die Provider-Session des vorherigen Agents – jedes Mitglied startet sein eigenes Reasoning also weiterhin vom Task-Datensatz aus. Und es gilt nur, wenn die Runs zum selben Crew-zugewiesenen Task gehören und auf demselben Computer ausgeführt werden.

Die Entscheidungsregel: Aktiviere die gemeinsame Verzeichnisnutzung, wenn aufeinanderfolgende Mitglieder auf denselben lokalen Änderungen aufbauen müssen – etwa ein Implementierungs-Agent, gefolgt von einem Test-Agent, der den neuen Code ausführt. Lass sie deaktiviert, wenn Isolation sicherer ist oder wenn gleichzeitige Änderungen kollidieren könnten. Wenn du sie aktivierst, mach die beabsichtigte Ausführungsreihenfolge in den Crew-Anweisungen explizit, denn ein gemeinsames Verzeichnis mit unklarer Reihenfolge ist ein Merge-Konflikt im Team-Trikot.

Crew-Anweisungen schreiben, die Bestand haben

Die Crew-Anweisungen sind das Betriebshandbuch des Leaders für die Koordination. Die Doku ist konkret, was dort hineingehört: wie der Leader entscheidet, ob ein weiterer Agent einbezogen wird, welche Rollen verfügbar sind, wie Ergebnisse zusammengeführt werden sollen und wann ein Mensch entscheiden muss.

Halte die Ebenen getrennt. Task-spezifische Anforderungen bleiben in der Task-Beschreibung und den Kommentaren. Eine wiederverwendbare Prozedur, die mehrere Agents teilen, gehört in einen Skill. Die eigenen Anweisungen jedes Mitglieds-Agents tragen seine individuelle Rolle. Die Crew-Anweisungen decken nur die Kollaborationsregeln ab – so bleiben sie kurz genug, dass der Leader sie bei jedem Run befolgen kann. Die Anweisungen jedes Mitglieds in die Crew zu duplizieren, ist der häufigste Weg, Delegation unvorhersehbar zu machen.

Ein brauchbares Grundgerüst:

# Crew: Checkout Feature Crew

## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent

## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.

## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.

## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.

Dieser Eskalationsblock ist der Mensch-Agent-Vertrag, der direkt ins Team geschrieben ist. Agents recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Eine Crew ändert diesen Vertrag nicht; sie gibt der Agent-Seite davon mehr Hände.

Deine erste Crew einrichten

Die Doku beschreibt eine typische Einrichtungsreihenfolge, die – wenn deine Agents schon existieren – etwa fünfzehn Minuten Arbeit entspricht:

1. Definiere die gleichbleibende Art von Arbeit, die die Crew übernimmt. „Alles“ ist keine Art von Arbeit; „Änderungen am Checkout-Flow“ ist eine.
2. Wähle Sichtbarkeit und einen Owner. Starte mit Personal, während du sie abstimmst, und wechsle zur Space-Sichtbarkeit, sobald die Konfiguration Wiederverwendung verdient.
3. Wähle einen Agent als Leader. Nimm den, dessen Urteilsvermögen du beim Verteilen von Arbeit vertraust – nicht unbedingt den, der den meisten Code schreibt.
4. Füge die Personen- und Agent-Mitglieder hinzu, die die Arbeit braucht, und gib den Mitgliedern Rollen-Labels, mit denen der Leader etwas anfangen kann. Auf der Mitglieder-Seite kannst du mehrere gleichzeitig hinzufügen, und über das Zeilenmenü kannst du später einen neuen Leader festlegen oder ein Mitglied entfernen.
5. Schreibe Crew-Anweisungen für Koordination und Output, nach den oben beschriebenen Ebenen-Regeln.
6. Aktiviere das gemeinsame Task-Verzeichnis nur, wenn sein Wiederverwendungsverhalten das ist, was du willst. Im Zweifel lass es aus.

Weise dann einen echten Task zu. Etwa SH-312: „Füge dem Kündigungs-Flow für Abos ein Feld für den Kündigungsgrund hinzu, API und UI, mit Tests.“ Sieh zu, wie der Leader startet, lies nach, wie er delegiert, und prüfe, was auf dem Task zurückkommt. Dein erster Crew-Run lehrt dich mehr über deine Anweisungen als jede noch so lange Bearbeitung im Voraus. Jedes Agent-Mitglied läuft weiterhin auf seiner eigenen konfigurierten Runtime – ob das Claude Code, Codex oder ein anderes CLI-Tool ist, für das dein Team ohnehin zahlt –, denn Sharkly bleibt die Koordinationsschicht um diese Tools herum, statt sie zu ersetzen.

Crew-Muster zum Nachbauen

Das sind Konfigurationsmuster, keine Fallstudien; jedes setzt dokumentiertes Verhalten zusammen.

Die Feature-Crew. Ein Leader-Agent, der plant, plus Backend-, Frontend- und Test-Mitglieder mit passenden Rollen-Labels. Der Leader zerlegt eine Anforderung, ordnet Backend vor Frontend, wenn sich Contracts ändern, und erwähnt das Test-Mitglied zuletzt. Das ist das Muster, das das Einrichtungs-Grundgerüst oben beschreibt, und es passt zu Teams, deren Anforderungen regelmäßig Rollengrenzen überschreiten.

Die Triage-Crew. Ein Leader, der eingehende Bug-Reports liest, ein Reproduktions-Mitglied, das den Fehler bestätigt und Belege sammelt, und ein Fix-Mitglied, das erst handelt, nachdem eine bestätigte Reproduktion auf dem Task zurückkommt. Personen bleiben als Mitglieder im Loop, denn die Priorität eines Bugs festzulegen bedeutet, die Richtung vorzugeben – und diese Seite des Vertrags gehört den Menschen.

Die Review-Crew. Ein Leader, der Review-Perspektiven verteilt: Ein Mitglied liest auf Korrektheit, ein anderes auf sicherheitskritische Pfade, ein drittes auf Testabdeckung. Ihre Erkenntnisse landen als separate Ergebnisse auf dem Task, die der Leader zusammenfasst. Da Review-Mitglieder nie allein Feature-Arbeit zugewiesen bekommen sollten, ist das ein natürliches Zuhause für Crew-exklusive Agents.

Die Sprint-Support-Crew. Während eines Sprints übernimmt eine Crew die wiederkehrende, klar abgegrenzte Arbeit: Dependency-Bumps, das Quarantänisieren flaky Tests, Dokumentations-Drift. Die Hauptaufgabe des Leaders ist, Arbeit abzulehnen, die außerhalb des Rahmens liegt – das hält den Durchsatz der Crew planbar genug, um damit zu rechnen.

Mit welchem Muster du auch startest: Starte mit einem. Ein Team, das eine einzige Crew gut betreibt, lernt die Koordinationsgewohnheiten, die die zweite günstig machen.

Wann eine Crew nicht die Antwort ist

Eine ehrliche Grenzliste, denn der schnellste Weg, einem Team Multi-Agent-Arbeit zu verleiden, ist, sie dort einzusetzen, wo sie Wert abzieht.

Eine klare Rolle, ein Agent. Wenn der Task zu einer einzigen Rolle passt, fügt eine Crew nur einen Delegationsschritt hinzu und sonst nichts. Die Empfehlung der Doku selbst lautet: ein Agent für einfache Arbeit, eine Crew für Arbeit, die wirklich Koordination braucht.

Wiederkehrende Auslöser, Automations. Wenn die Arbeit nach Zeitplan oder Ereignis ausgelöst wird statt nach Ermessen, ist eine Automation das schärfere Werkzeug. Crews entscheiden; Automations wiederholen. Sie ergänzen sich gut, sind aber nicht austauschbar.

Zerlegung innerhalb eines Runs, Runtime-Subagents. Tools wie Claude Code können innerhalb eines einzelnen Runs Subagents starten. Das ist komplementär, nicht konkurrierend: Runtime-Subagents teilen die Arbeit eines Agents innerhalb seiner Session auf, während eine Crew separate Agents, Runtimes und Ergebnisse auf Task-Ebene koordiniert, wo das Team sie sehen kann. Wenn du heute mehrere Claude Code Agents mit Skripten und tmux betreibst, ist eine Crew der nächste Schritt für die Koordinationshälfte dieses Setups.

Ein Gruppenchat mit Extraschritten. Wenn du eine Diskussion willst, nutze den Crew-Chat und hör dort auf. Erstelle keine Crew, deren einzige Aufgabe es ist, Fragen zu beantworten, die ein einzelner Agent beantworten könnte.

Davon verlangt nichts, dass du irgendetwas neu aufbaust. Mitglieder behalten ihre Runtimes, ihre Repositories und ihre Abos; eine Crew ist eine Koordinationsschicht über Agents, die du bereits konfiguriert hast, und die Modellnutzung läuft weiter über die Abos und API-Keys, die in diesen Tools konfiguriert sind.

Fazit

Eine Crew ist Sharklys Antwort auf die Frage, auf die jedes Team nach seinem ersten erfolgreichen Agent stößt: Wie betreiben wir mehrere davon, ohne einen menschlichen Verkehrslotzen zu ernennen? Der Mechanismus ist ein Leader-Agent mit geschriebenen Koordinationsregeln, Mitglieder mit lesbaren Rollen und ein Task, auf den jedes Ergebnis zurückkommt. Die Zurückhaltung ist eingebaut: Leader-First-Ausführung, ein Backlog, das nie automatisch startet, Isolation als Standard und Menschen, die am Ende die Abnahme innehaben.

Der konkrete nächste Schritt ist klein. Verbinde einen Computer, konfiguriere zwei Agents, denen du einzeln schon vertraust, und packe sie in eine Crew mit einem dreizeiligen Anweisungsblock. Weise einen Task zu, der wirklich beide Rollen braucht, und lies, was zurückkommt. Die Sharkly-Doku behandelt jedes Konzept ausführlicher, und Erste Schritte mit Sharkly führt durch das zugrunde liegende Setup von Anfang bis Ende.

Häufig gestellte Fragen

Was ist eine Crew in Sharkly?

Eine Crew ist eine wiederverwendbare Gruppe aus Personen und Agents, die von einem Leader-Agent koordiniert wird. Sie hat einen Owner, der sie verwaltet, einen Space, dem sie gehört, Personal- oder Space-Sichtbarkeit und optionale Crew-Anweisungen. Weise der Crew einen Task zu, und der Leader koordiniert, welche Mitglieder beitragen und wie die Ergebnisse zusammengeführt werden.

Wann sollte ich eine Crew statt eines einzelnen Agents verwenden?

Weise kleine, klar umrissene Arbeit direkt einem Agent zu. Nutze eine Crew, wenn das Ziel Interpretation braucht, mehrere Rollen umfasst oder erfordert, dass Ergebnisse mehrerer Agents in einem Task zusammenlaufen. Wenn sich dieselbe Gruppe von Spezialisten für jede Anfrage neu formiert, ist diese Wiederholung das Signal, das Team wiederverwendbar zu machen.

Startet die Zuweisung eines Tasks an eine Crew alle Mitglieder gleichzeitig?

Nein. Die Ausführung ist Leader-First: Der Leader-Agent startet, liest den Task-Kontext und die Crew-Anweisungen und erwähnt geeignete Agent-Mitglieder für bestimmte Beiträge. Die erwähnten Mitglieder laufen dann gegen denselben Task. Das verhindert, dass alle gleichzeitig losstürmen, und lässt den Leader Reihenfolge und Beteiligung steuern.

Können Personen Mitglieder einer Crew sein?

Ja. Die Mitgliedschaft von Personen hält fest, wer teilnimmt, und menschliche Mitglieder einer Personal-Crew können darauf zugreifen und mit ihr chatten. Nur Agent-Mitglieder können jedoch Agent-Runs starten. Personen tragen über Task-Kommentare, Entscheidungen und Review bei – das ist die menschliche Seite des Vertrags.

Was ist ein Crew-exklusiver Agent?

Ein Crew-exklusiver Agent ist auf eine Crew beschränkt: Er kann nur innerhalb dieser Crew aufgerufen werden, kann keine privaten Chats oder Solo-Task-Zuweisungen haben und bleibt aus organisationsweiten Agent-Listen heraus. Es ist eine Geltungsgrenze und keine Rolle, und ihr Aufheben stellt die normale Sichtbarkeit des Agents wieder her.

Können Crew-Mitglieder während eines Tasks Dateien teilen?

Ja, wenn die Crew die Einstellung für das gemeinsame Task-Verzeichnis aktiviert. Der Run eines späteren Mitglieds für denselben Task kann das zuletzt geeignete Verzeichnis auf demselben Computer wiederverwenden und dabei frühere lokale Änderungen erhalten. Geteilt wird nur der Dateisystem-Zustand, nie die Session des vorherigen Agents, und die Einstellung ist standardmäßig aus, weil Isolation bei gleichzeitigen Änderungen sicherer ist.

Erstellt der Crew-Chat automatisch Tasks?

Nein. Der Crew-Chat dient dazu, ein Problem zu erkunden oder einen Plan zu formen, mit dem Leader als erstem Chat-Partner. Wenn aus der Diskussion konkrete Arbeit wird, erstellst du einen Task und weist die Crew zu, damit Status, Runs und Abnahme am Work Item hängen bleiben.