Die meisten Multi-Agenten-Workflows scheitern nicht am schwierigsten Teil. Der Agent schreibt den Code, führt die Tests aus, öffnet den Pull Request. Sie scheitern an den Schnittstellen: in dem Moment, in dem die Arbeit von einem Agenten abgeschlossen wird und an die nächste Stelle übergeben werden soll. Ein Backend-Agent stellt einen Endpunkt fertig, und der Frontend-Agent erfährt nie, dass er bereit ist. Ein Refactoring landet in einem Worktree und bleibt dort – grün –, weil niemand Bescheid weiß, es zu prüfen. Die Aufgabe ist nicht gescheitert. Die Übergabe ist es.
Ein KI-Agenten-Handoff ist der Transfer einer Arbeit samt Kontext von einem Ausführenden zum nächsten: von Agent zu Agent oder von Agent zu Mensch. Wenn Sie einen einzelnen Coding-Agenten in einem Terminal ausführen, sind Übergaben unsichtbar, weil es schlicht keine gibt. Sobald Sie jedoch zwei Agenten einsetzen – oder einen Agenten und einen Reviewer –, muss jeder abgeschlossene Schritt dort landen, wo die nächste Person oder der nächste Agent ihn auch findet. Dieser Übergabepunkt entscheidet über alles.
Dieser Artikel zeigt die Handoff-Muster, die sich in der Praxis bewähren, und nutzt Sharkly als Workflow-Ebene: die Schicht oberhalb Ihrer Coding-Agenten, die Kontext, Fortschritt, Blocker, Ergebnisse und menschliche Reviews von der Anforderung bis zum Release sichtbar hält. Coding-Agenten haben Sie bereits. Das Problem, das dieser Beitrag löst, ist das, was in den Lücken dazwischen geschieht.
Die Kurzfassung
Ein Handoff ist der Moment, in dem eine Aufgabe samt Kontext an die nächste Instanz übergeht. Agent-zu-Agent-Übergaben leiten eine fertige Teilaufgabe an den nächsten Agenten weiter; Agent-zu-Mensch-Übergaben stoppen autonome Prozesse an einem Review-Gate. Machen Sie beides über Statuswerte explizit: Agenten setzen einen Task auf „Ready for review“, Menschen setzen ihn auf „Done“. Wenn der Handoff über eine Statusänderung an einem gemeinsamen Task erfolgt statt über eine flüchtige Nachricht im Terminal, geht nichts unbemerkt verloren.
Was genau ist ein Agenten-Handoff?
Ein Handoff besteht aus drei Komponenten. Fehlt auch nur eine davon, geht Arbeit verloren: das Artefakt (das Diff, der PR, die Migration), der Kontext (was angefordert wurde, was sich geändert hat, was noch unklar ist) und der Empfänger (der konkrete Agent oder die Person, die für den nächsten Schritt zuständig ist).
Terminalbasierte Workflows transportieren zwar das Artefakt, verlieren aber die anderen beiden Punkte. Der Commit existiert, doch die Begründung steckt im Scrollback-Buffer fest, den nur ein einziger Agent gesehen hat – und wer als Nächstes an der Reihe ist, hängt davon ab, wer zufällig nachsieht. Deshalb geht es bei der Orchestrierung von Agenten weniger darum, sie zu starten, sondern vor allem darum, ihre Ergebnisse weiterzuleiten.
Ein sauberer Handoff überträgt alle drei Elemente gemeinsam: die Änderung, die Zusammenfassung dessen, was getan und was ausgelassen wurde, sowie ein eindeutiges Signal, wer am Zug ist. Bezogen auf Sharkly bedeutet das: Ausführung, Blocker, Ergebnisse und Folgeabstimmungen fließen in die Task-Timeline zurück. So liest die nächste zuständige Stelle einen einzigen Verlauf, anstatt drei verschiedene Quellen mühsam rekonstruieren zu müssen.
Zwei Handoff-Muster
Die beiden Muster wirken auf den ersten Blick ähnlich, basieren jedoch auf gegensätzlichen Grundeinstellungen. Ein Agent-zu-Agent-Handoff sollte automatisch ablaufen: Der nächste Agent übernimmt eine fertige Teilaufgabe und arbeitet weiter. Ein Agent-zu-Mensch-Handoff sollte standardmäßig stoppen: Der Agent schließt seinen Bereich ab und wartet, da eine Entscheidung durch einen Menschen erforderlich ist.
| Agent zu Agent | Agent zu Mensch | |
|---|---|---|
| Auslöser | Eine Teilaufgabe wird als bereit markiert | Die Arbeit erreicht ein Review-Gate |
| Standardverhalten | Automatisch fortsetzen | Anhalten und warten |
| Überträgt | Artefakt + Kontext + Akzeptanzkriterien | Diff + Zusammenfassung der Änderungen + bekannte Einschränkungen |
| Risiko bei Fehlen | Doppelte oder widersprüchliche Arbeit | Ungeprüfter Code wird blind gemergt |
Hier ist die entscheidende Faustregel: Automatisieren Sie den Agent-zu-Agent-Handoff, wenn der nächste Schritt klar definiert ist und die Akzeptanzkriterien bereits feststehen: „Testsuite ausführen“, „Migration generieren“, „OpenAPI-Spezifikation aktualisieren“. Erzwingen Sie hingegen einen Agent-zu-Mensch-Handoff, wenn der nächste Schritt Urteilsvermögen erfordert, das kein Agent übernehmen kann: Mergen in den Main-Branch, Ändern eines öffentlichen API-Contracts, Eingriffe in Authentifizierung oder Billing oder die finale Abnahme eines Ergebnisses.
Der Fehler besteht darin, jede Übergabe gleich zu behandeln. Wer alles automatisch durchwinkt, mergt ungeprüften Code; wer überall Kontrollpunkte setzt, baut sich eine langsame manuelle Pipeline mit unnötigen Zwischenschritten. Entscheidend ist zu wissen, wo Approval-Gates sinnvoll platziert werden – damit Agenten vor kostspieligen Fehlern stoppen und nicht nach jedem noch so trivialen Schritt.
Statuswerte machen die Übergabe zum Gate – nicht zum Prinzip Hoffnung
Das Betriebsmodell lässt sich auf vier Verben und deren Zuständigkeiten herunterbrechen: wer zuweist, wer ausführt, wer prüft und wer abnimmt. Agenten recherchieren, implementieren, testen und berichten. Menschen geben die Richtung vor, erteilen Freigaben und nehmen Ergebnisse ab. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist.
Statuswerte machen aus dieser Vereinbarung ein verlässliches System statt eines bloßen Wunschdenkens. Jeder Task durchläuft dieselben Phasen:
- Todo: Zugewiesen, noch nicht begonnen. Von einem Menschen oder einem leitenden Agenten hier abgelegt.
- In progress: Ein Agent hat den Task übernommen und arbeitet in einem isolierten Worktree daran.
- Ready for review: Die Grenze für den Agenten. Typecheck, Tests und Build wurden ausgeführt, die Zusammenfassung der Änderungen sowie bekannte Einschränkungen angehängt – danach stoppt der Agent.
- Done: Die Grenze für den Menschen. Jemand hat das Ergebnis abgenommen und über Merge sowie Release entschieden.
Die Regel, die für klare Verhältnisse sorgt: Agenten setzen einen Task auf „Ready for review“; Menschen setzen ihn auf „Done“. Ein Agent markiert seine eigene Arbeit niemals als abgeschlossen („Done“), und Menschen müssen nicht raten, ob ein grüner Task wirklich einsatzbereit ist. Der Status ist die Übergabe. Wenn zehn Agenten parallel laufen, müssen Sie nicht zehn Terminals überwachen; Sie blicken auf das Board und sehen sofort, was auf Sie wartet, was auf einen anderen Agenten wartet und was gerade ausgeführt wird. Diese Transparenz macht den Unterschied aus, ob Sie nachvollziehen, was Agenten fertiggestellt haben, oder ob Sie später darauf hoffen müssen, dass das Commit-Log Aufschluss gibt.
Ein praktisches Beispiel: Vom Ticket zum gemergten PR
Betrachten wir einen realistischen Task, SH-312: „Rate-Limiting für die öffentliche API hinzufügen.“ Achten Sie dabei nicht auf den Code, sondern auf die Übergaben.
Eine Person beschreibt die Anforderung in natürlicher Sprache und weist die Aufgabe zu. Ein leitender Agent analysiert die Codebasis sowie frühere Tasks, formuliert den Umfang und die Akzeptanzkriterien (Limit pro API-Schlüssel, Rückgabe von Status 429 mit Retry-After-Header, Abdeckung der drei am stärksten frequentierten Endpunkte) und unterteilt SH-312 in drei ausführbare Teilaufgaben. Das ist der erste Agent-zu-Agent-Handoff: Ziel rein, fertige Teilaufgaben raus.
Die Teilaufgaben laufen automatisch weiter. Ein Backend-Agent übernimmt die Limiter-Logik, ein Test-Agent die Testabdeckung. Da beide in einem isolierten Worktree arbeiten, kollidieren sie nicht an denselben Dateien, und jedes Ergebnis fließt direkt in SH-312 zurück, statt in einer isolierten Session zu verbleiben. Sobald der Backend-Agent fertig ist, benachrichtigt er keinen Menschen; er markiert seine Teilaufgabe als bereit, und der Test-Agent übernimmt die echte Implementierung anstelle eines Stubs.
Anschließend wechselt das Handoff-Muster. Wenn der Limiter implementiert ist, der Typecheck sauber durchläuft, die Tests erfolgreich sind und der Build grün ist, erreicht die Arbeit das Agent-zu-Mensch-Gate. Der Agent setzt SH-312 auf „Ready for review“ und hängt das Diff, eine Zusammenfassung der Änderungen sowie eine bekannte Einschränkung an: „Redis-basierter Zähler setzt eine einzelne Region voraus; Multi-Region erfordert ein Folge-Ticket.“ Ein Mensch liest all das an einem zentralen Ort, prüft das 429-Verhalten und setzt den Task auf „Done“, was den Merge auslöst. Vom Ticket zum gemergten PR – lückenlos dokumentiert an jeder Schnittstelle. Das ist derselbe Weg von Anforderungen zu Code, durchgängig nachvollziehbar gemacht.
Wo Handoffs scheitern und wie man sie absichert
Übergaben scheitern auf drei vorhersehbare Weisen – und für jede davon gibt es eine strukturelle Lösung statt eines bloßen „Versuch, dran zu denken“.
Kontext verflüchtigt sich. Der Agent wusste, warum er eine Entscheidung getroffen hat; der Reviewer weiß es nicht. Die Lösung: Beim Wechsel auf „Ready for review“ überträgt der Handoff die Zusammenfassung der Änderungen und bekannte Einschränkungen verpflichtend, nicht erst als nachträglicher Gedanke. Zuständigkeiten verschwimmen. Zwei Agenten stürzen sich auf dieselbe Aufgabe oder gar keiner tut es. Die Lösung: Ein fester Assignee auf jedem Task und jeder Teilaufgabe, sodass „Du bist dran“ ein definiertes Feld ist und kein vages Bauchgefühl. Reviews finden nicht statt. Autonom erstellte Änderungen werden gemergt, weil niemand angewiesen wurde, sie aufzuhalten. Die Lösung: Ein Status, den der Agent nicht eigenständig überwinden kann.
All das lässt sich manuell mit Worktrees, Namenskonventionen und Disziplin abbilden. Das funktioniert so lange, bis die Zahl der Agenten, Tasks und Repositories steigt – und die Disziplin als Erstes auf der Strecke bleibt. Wenn Sie bereits mehrere Agenten einsetzen, bietet Ihnen Sharkly einen zentralen Ort, um deren Aufgaben und Ergebnisse zu verwalten: gemeinsame Tasks, Assignees pro Task, isolierte Worktrees und ein Status-Workflow, in dem Agenten „Ready for review“ erreichen und Menschen über „Done“ entscheiden. Behalten Sie die Coding-Agenten, die Sie bereits nutzen, und ergänzen Sie die Schicht, die deren Übergaben sichtbar macht. Laden Sie Sharkly herunter, sobald die Schnittstellen zwischen Ihren Agenten mehr Aufwand kosten als die eigentliche Arbeit.
FAQ
Was ist ein KI-Agenten-Handoff? Es ist die Übergabe einer Aufgabe samt Kontext und dem Signal, wer als Nächstes an der Reihe ist, von einem Ausführenden an den nächsten. Es gibt zwei Varianten: von Agent zu Agent (eine fertige Teilaufgabe fließt an den nächsten Agenten) und von Agent zu Mensch (autonome Arbeit stoppt an einem Review-Gate).
Was ist der Unterschied zwischen Agent-zu-Agent- und Agent-zu-Mensch-Handoffs? Agent-zu-Agent-Übergaben sollten automatisch fortgesetzt werden, wenn die Akzeptanzkriterien für den nächsten Schritt bereits feststehen. Agent-zu-Mensch-Übergaben sollten anhalten und warten, da hier menschliches Urteilsvermögen gefragt ist: beim Mergen, bei Änderungen an öffentlichen Schnittstellen oder bei der finalen Abnahme.
Sollten Agenten ihre eigene Arbeit als erledigt markieren? Nein. Lassen Sie Agenten einen Task nach Ausführung der Tests und dem Beifügen einer Zusammenfassung auf „Ready for review“ setzen; überlassen Sie den Schritt zu „Done“ und die Entscheidung über den Merge einem Menschen. Erst die Trennung dieser beiden Grenzen verhindert, dass ungeprüfter Code in Produktion geht. Siehe auch Human-in-the-Loop-Coding-Agenten.
Wie verhindern Statuswerte, dass Aufgaben untergehen? Wenn der Handoff über eine Statusänderung an einem geteilten Task statt über eine Terminalnachricht erfolgt, sieht die nächste zuständige Person oder Instanz genau, was ansteht. Nichts hängt mehr davon ab, ob jemand im richtigen Moment das Terminal-Protokoll im Blick hat. Eine Agenten-Inbox zeigt gezielt die Elemente an, die Ihre Aufmerksamkeit erfordern.
Brauche ich dafür ein Tool oder geht das auch manuell? Man kann das mit Worktrees und einem gemeinsamen Board abbilden. Eine dedizierte Workflow-Ebene lohnt sich, sobald mehrere Agenten über mehrere Repositories hinweg koordiniert werden müssen und das manuelle Nachverfolgen zum Flaschenhals wird. Ziehen Sie das Modell Assistent versus Teammitglied heran, um zu entscheiden.
