Agentic Teams: Wem gehört die Arbeit, wenn KI-Agenten sie erledigen?

Der erste Agent in einem Team ist eine Geschichte persönlicher Produktivität. Der fünfte ist eine organisatorische. Irgendwo dazwischen hört eine Gruppe auf, ein Team zu sein, das KI nutzt, und wird ein agentisches Team: Menschen und Agenten arbeiten am selben Board, an denselben Aufgaben, nach Regeln, die jemand aufschreiben musste.

Genau in diesem Übergang stecken die meisten interessanten Fragen. Wem gehört die Arbeit, die ein Agent ausgeführt hat? Was steht in einem Standup, wenn sich das Board von selbst aktualisiert? Wie viele Agenten verkraftet eine reviewende Person? Dieser Leitfaden behandelt die Zusammensetzung eines agentischen Teams, die Arbeitsteilung, die den Kontakt mit echter Arbeit übersteht, und die Arbeitsvereinbarungen, die man guten Gewissens übernehmen kann. Sharkly ist die Plattform, die wir für genau diese Form von Team bauen, und die folgenden Fehlerbilder stammen daher, dass wir diese Form schiefgehen sehen haben.

TL;DR

Ein agentisches Team ist eine Gruppe, in der Menschen und KI-Agenten beide zugewiesene Arbeit in einem gemeinsamen System halten, während Menschen die Richtung, die Entscheidungsbefugnis und die Abnahme behalten. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab. Die praktischen Voraussetzungen sind ein Aufgabendatensatz, den beide lesen können, eine Ausführungszuweisung, die getrennt von der verantwortlichen Person ist, ein Review-Status, der bei jemandem ankommt, und ein ausreichend schriftlich festgehaltener Umfang, damit ein Agent nicht raten muss.

Woraus ein agentisches Team besteht

Es gibt drei Arten von Beteiligten, und es hilft, sie genau zu benennen.

Menschen erstellen und aktualisieren Aufgaben, kommentieren, erhalten Queue-Einträge, bekommen Arbeit zugewiesen, prüfen Agentenergebnisse und verwalten die Einstellungen, die ihre Rolle zulässt. Sie sind die einzigen Beteiligten, die rechenschaftspflichtig sein können.

Agenten sind gespeicherte Arbeitskonfigurationen und keine einmaligen Prompts: Anweisungen, eine Runtime wie Claude Code oder Codex, Repositories, Umgebung, Run-Einstellungen und gebundene Skills. Ein Agent ist eher eine dokumentierte Rolle als eine Person. Was alles dazugehört, beschreibt unsere Einführung zu Sharkly Agents.

Crews bündeln Agenten unter einem leitenden Agenten für Arbeit, die Koordination erfordert. Die Ausführung läuft Leader-first ab: Der Leader liest die Aufgabe und die Crew-Anweisungen und erledigt dann entweder die Arbeit selbst oder zieht gezielt einzelne Mitglieder hinzu. Diese Reihenfolge verhindert, dass alle Mitglieder gleichzeitig loslegen. Die Details stehen in unserem Leitfaden zu Sharkly Crews.

Darüber liegt der Zugriff: Eine Organisationsrolle bestimmt die allgemeinen administrativen Möglichkeiten, und die Space-Mitgliedschaft bestimmt, welche Arbeitsbereiche jemand erreichen kann. Für Agenten gilt dieselbe Einschränkung, auf bestimmte Repositories und bestimmte Maschinen.

Die Arbeitsteilung, die funktioniert

Sharklys eigener Kontrakt ist ein guter Standard, weil er eng genug ist, um durchsetzbar zu sein: Agenten recherchieren, führen aus, testen und berichten; Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.

Vier Verantwortlichkeiten bleiben bei Menschen, egal wie leistungsfähig die Agenten werden.

• Richtung. Entscheiden, was sich lohnt und in welcher Reihenfolge.
• Kontext. Einen Umfang schreiben, mit dem ein Agent arbeiten kann: warum die Arbeit wichtig ist, was außerhalb des Umfangs liegt, relevante Dateien und Einschränkungen und wie die Fertigstellung geprüft wird.
• Abnahme. Die Belege lesen und entscheiden, dass die Arbeit erledigt ist. Ein abgeschlossener Run ist noch kein abgenommenes Ergebnis.
• Eskalation. Entscheiden, was passiert, wenn ein Agent blockiert ist, falsch liegt oder auf eine Frage gestoßen ist, die Urteilsvermögen erfordert.

Alles andere ist verhandelbar und hängt davon ab, wie sehr dein Team der Erfolgsbilanz eines bestimmten Agenten bei einer bestimmten Art von Arbeit vertraut.

Wie Arbeit durch das Team fließt

Der Kreislauf ist kurz und sollte ausdrücklich festgehalten werden, denn Teams, die einen Schritt überspringen, spüren das innerhalb einer Woche.

1. Eine Person schreibt eine Aufgabe mit einem festgelegten Ergebnis und Abnahmekriterien.
2. Die Aufgabe bekommt eine menschliche zugewiesene Person für die Verantwortung und einen Agenten oder eine Crew als Ausführungszuweisung. Das sind getrennte Felder, und das Ändern des einen ändert nicht das andere.
3. Wird die Aufgabe aus einem geparkten Backlog-Status herausgezogen, startet der Run, sobald der zugewiesene Agent bereit ist.
4. Der Run läuft auf einer verbundenen Maschine in einem isolierten Verzeichnis; Fortschritt und Blocker fließen zurück in die Aufgabe.
5. Der Agent hinterlässt die Arbeit im Status „wartet auf menschliche Antwort“ oder „wartet auf menschliches Review“, und das landet im Agenten-Posteingang der verantwortlichen Person.
6. Eine Person liest den Trace und den Diff und nimmt dann ab, kommentiert, um fortzufahren, oder weist neu zu.

Kommentare sind die dauerhafte Konversation. Ein Kommentar zu einer Aufgabe mit einem bereiten Agenten kann den nächsten Run in die Queue stellen, wodurch Review-Feedback und Ausführung derselbe Vorgang sind statt zwei getrennter Systeme.

Drei Formen, die funktionieren

Das Entwickler-Agent-Duo. Jeder Entwickler hält ein oder zwei Agenten für seine eigene wiederkehrende Arbeit vor: Testabdeckung, Dependency-Bumps, Refactorings, die er schon zwanzig Mal gemacht hat. Der Nutzen fürs Team liegt darin, dass diese Agentendefinitionen geteilt werden: Eine neue Kollegin erbt am ersten Tag fünf funktionierende Setups, statt eigene zu bauen.

Das Squad mit einer gemeinsamen Crew. Eine Crew übernimmt eine Kategorie von Arbeit, von der das ganze Squad abhängt, etwa Release-Vorbereitung oder Incident-Triage. Ein leitender Agent entscheidet, welches Mitglied beiträgt, und ein Mensch verantwortet die Kategorie. Das ist die Form, die am weitesten skaliert, bevor die Review-Kapazität zum Engpass wird.

Das standardisierende Plattformteam. Ein Plattform- oder Developer-Experience-Team verantwortet die Agentendefinitionen, Skills und Maschinenkonfiguration für mehrere Produktteams. Produktteams weisen Arbeit zu; das Plattformteam hält Runtimes, Berechtigungen und Anweisungen aktuell. Diese Form tauscht etwas Autonomie gegen Konsistenz, und ab etwa dreißig Entwicklern ist das meist der richtige Deal.

Keine der drei erfordert eine Reorganisation. Es sind Muster dafür, wer die Agentenkonfiguration verantwortet – und genau diese Frage entscheidet, ob sich Agentenfähigkeiten im Team aufsummieren oder privat bleiben.

Arbeitsvereinbarungen, die sich lohnen

Eine verantwortliche Person pro Aufgabe. Auch wenn eine Crew aus vier Agenten die Arbeit macht. Dann erst recht.

Der Umfang wird vor der Zuweisung geschrieben. Wenn niemand sagen kann, wie das Ergebnis geprüft wird, ist die Aufgabe nicht bereit für einen Agenten. Allein diese Regel verhindert die meisten schlechten Runs.

Review ist eingeplante Kapazität, keine Restzeit. Legt fest, wie viel Agentenarbeit jede reviewende Person pro Tag aufnehmen kann, und haltet diese Zahl ein. Ein wachsender Stapel ungeprüfter Agentenergebnisse ist dieselbe Schuld wie nicht gemergte Pull Requests – nur wächst sie schneller.

Fehlgeschlagene Runs werden diagnostiziert, nicht wiederholt. Öffnet das Ausführungsprotokoll und lest zuerst Titel und technische Details. Vendor-Fehler, die gleich aussehen, brauchen oft entgegengesetzte Korrekturen – ein reflexhaftes Wiederholen verdeckt die eigentliche Ursache.

Agentendefinitionen bekommen einen Verantwortlichen und ein Review-Datum. Anweisungen verrotten. Der Entwickler, der den Migrationsagenten geschrieben hat, geht, die Konventionen ändern sich, und der Agent wendet weiterhin selbstbewusst die Regeln vom letzten Quartal an.

Was zuerst bricht, wenn das Team wächst

Die Review-Kapazität ist immer zuerst dran. Die zweite Einschränkung ist die Maschinenkapazität: Runs stehen in der Queue, während sie auf Nebenläufigkeit oder ein freies Arbeitsverzeichnis warten, und ein Team, das Agenten hinzugefügt hat, ohne Computer hinzuzufügen, entdeckt eine Warteschlange, die vom Board aus nicht sichtbar ist.

Die dritte ist Ownership-Drift. Wenn mehrere Agenten zu verwandten Aufgaben beitragen und nach einer Übergabe niemand den Owner umbenennt, bleibt Arbeit übrig, die formal zugewiesen und praktisch herrenlos ist. Ein wöchentlicher Durchgang über Aufgaben mit Agentenzuweisung und veralteten menschlichen Ownern dauert zehn Minuten und verhindert die unschöne Variante davon. Wenn du lieber mit einem System starten möchtest, das diese Felder bereits trennt, lade Sharkly herunter und lass eine Woche lang eine wiederkehrende Art von Arbeit darüber laufen.

FAQ

Wie viele Agenten pro Entwickler sind sinnvoll? Fangt mit ein oder zwei an und lasst den Review-Durchsatz die Obergrenze bestimmen. Die richtige Zahl ist die, bei der Ergebnisse nicht länger als einen Arbeitstag auf eine menschliche Entscheidung warten.

Nehmen Agenten am Standup teil? Ihre Arbeit schon. Das Board trägt den Status, also wird das Standup zur Ausnahmeliste: Fehler, blockierte Runs und Ergebnisse, die auf Menschen warten.

Sollte ein Agent jemals der einzige Zugewiesene sein? Nein. Eine Person bleibt für das Ergebnis verantwortlich, der Agent sitzt im Ausführungs-Slot. Unser Leitfaden zu AI Agent Project Management erklärt, warum diese Trennung mit steigendem Volumen wichtiger wird.

Wie integrieren wir einen neuen Agenten ins Team? Genauso wie du eine Person einarbeitest: ein enges erstes Assignment, engmaschiges Review, dann den Umfang erweitern. Speichert, was funktioniert hat, als Anweisungen und Skills des Agenten, damit das nächste Team es nicht neu entdecken muss.