Du zerlegst eine große Aufgabe in fünf Kanban-Karten, fünf Agents starten parallel und alle liefern pünktlich. Dann mergst du alles und erkennst das Problem: Zwei Worker haben unabhängig voneinander unterschiedliche Antworten auf dieselbe Design-Frage erfunden, eine Datei wurde gleichzeitig von drei Karten umgeschichtet, und niemand hat auch nur einen Teil davon reviewt – weil „Review“ nie Teil des Loops war. Das ist der schmerzhafteste Teil der Multi-Agent-Zusammenarbeit, und genau das behebt ein Bündel von PRs, das am 10. August 2026 gemergt wurde (#83412, #83423, #83424, #83428): Hermes Kanban hat jetzt einen Review-Lifecycle erster Klasse, plus drei Schutzmechanismen gegen das Chaos. Hier ist der komplette Ablauf – vom Einreichen der Arbeit zur Review bis zum Zurückgeworfenwerden – und die Konventionen, die parallele Agents ehrlich halten.

Der Review-Loop: Implementer → Review-Lane → Urteil

Kanban-Karten haben jetzt eine echte Review-Phase. Wenn ein Implementer fertig ist, reicht er die Arbeit über kanban_request_review ein:

kanban_request_review(
  task_id="T-42",
  summary="Implemented the export feature; verified with 3 sample files",
  reviewer="code-reviewer"    # optional
)

summary ist Pflicht – sie sagt dem Reviewer, was gebaut und wie verifiziert wurde; reviewer ist optional; eingereichte Inhalte werden automatisch redigiert. Die Karte wandert in die Review-Lane, wo ein Reviewer-Profil sie aufnimmt und die sdlc-review-Skill automatisch geladen wird. Der Reviewer fällt eines von drei Urteilen:

Urteil	Aktion	Bedeutung
Approve	kanban_complete	Abnahmekriterien erfüllt, Aufgabe wird abgeschlossen
Änderungen anfordern	kanban_comment + kanban_request_changes(reason=…)	Behebbare Mängel vorhanden; Karte kehrt zum ursprünglichen Implementer zurück
Eskalieren	kanban_block	Eine menschliche Entscheidung oder externe Voraussetzung ist nötig

Die Provenienz bleibt erhalten: Korrigiert der Implementer die Karte und reicht sie erneut zur Review ein, ohne einen Reviewer zu nennen, wird sie wieder dem gleichen Reviewer-Profil zugeführt – keine zufällige Neuzuordnung, durchgehender Review-Kontext.

Rotierende Review-Linsen: Runde 1 kalt lesen, Runde 2 ausführen, Runde 3 Vertrag prüfen

Die sdlc-review-Skill hat ein cleveres Design: Jede Runde betrachtet die Arbeit durch eine andere Linse, statt dieselbe Prüfung zu wiederholen. Die Rundennummer ist die Anzahl früherer changes_requested-Versuche plus eins (Runde 1 = null Zurückweisungen, Runde 2 = eine, und so weiter):

• Runde 1 – Artefakt: Lies den Diff oder das Ergebnis kalt, vor der Zusammenfassung des Implementers; bilde dir ein unabhängiges Urteil, vergleiche es dann mit der Übergabe-Erzählung und untersuche jede Abweichung;
• Runde 2 – Ausführung: Check die Arbeit aus und führe sie tatsächlich über terminal aus – baue, teste und probiere das berichtete Verhalten selbst aus, statt das Artefakt erneut zu lesen;
• Runde 3+ – Vertrag: Lies den ursprünglichen Aufgabentext und die Abnahmekriterien der Karte erneut, prüfe das Ergebnis strikt dagegen und verifiziere, dass jeder Punkt aus jeder früheren request_changes-Runde tatsächlich umgesetzt wurde.

Dasselbe Prinzip gilt, wenn du über delegate_task ad-hoc parallele Reviewer verteilst: Gib jedem Reviewer ein anderes Briefing (einem nur den Diff, einem den vollen Kontext, einem Checkout-und-ausführen), statt identische. Identische Briefings erzeugen korrelierte Urteile und doppelte Befunde; unterschiedliche Linsen decken bei gleichem Review-Aufwand mehr Fehlerklassen ab.

Schutzmechanismus 1: Decision Ownership – ein Eigentümer pro Frage

Der klassische Multi-Agent-Fehlermodus ist „Split-Brain“: Zwei Worker beantworten dieselbe Design-Frage unabhängig voneinander unterschiedlich. Ein neuer Decision-Ownership-Vertrag in KANBAN_GUIDANCE blockiert diesen Weg direkt:

• Design-Entscheidungen gehören dem Orchestrator und werden vor dem Fan-out getroffen;
• Keine zwei Subtree-Karten dürfen dieselbe Frage entscheiden;
• Der Text jeder Child-Karte muss die Entscheidungen enthalten, von denen sie abhängt – denn Worker können den Kontext ihrer Geschwister nicht sehen.

Das Beispiel aus der Doku sagt es perfekt: Eine Exporter-Karte und eine Importer-Karte dürfen das Dateiformat nicht jeweils selbst „erfinden“. Der Orchestrator legt das Format zuerst fest und stempelt es in beide Kartentexte, sodass beide Worker gegen denselben Vertrag schreiben und beim Merge nichts kollidiert.

Schutzmechanismus 2: Kollisions-Hotspots – markieren statt draufhauen

Parallele Änderungen an derselben Datei kollidieren zwangsläufig; die neue Konvention behandelt das proaktiv. Wenn ein Worker merkt, dass die Datei, die er gerade anfassen will, immer wieder Konflikte von Schwesterkarten anzieht, hinterlässt er einen kanban_comment, der mit hotspot: beginnt (z. B. hotspot: src/config.py – drei Karten bearbeiten diese Datei), und hebt ihn in den Abschluss-Metadaten hervor. Ein Orchestrator, der 2+ Markierungen auf einem Pfad sieht, erstellt eine Dekompositions-Karte – er nimmt die heiße Datei aus der Queue heraus, bevor er weitere Arbeit verteilt, die sie berührt. Für Konflikte, die bereits passiert sind, schlichtet der merge-reconciler.

Das Fazit

Zusammen verwandeln diese Änderungen Kanban von „Arbeit verteilen, Ergebnisse einsammeln“ in einen vollständigen Entwicklungs-Loop: Review, rotierende Perspektiven, Decision Ownership und frühzeitige Konflikt-Warnung. Der Sweet Spot ist offensichtlich – Repositories, in denen mehrere Agents parallel arbeiten und Qualität ein Gate braucht; ein einzelner Agent, der kleine Aufgaben erledigt, braucht keinen so schwergewichtigen Workflow. Die komplette Kanban-Befehlsfläche findest du in der hermes-kanban-Befehlsreferenz; mehr Konventionen für Multi-Agent-Setups haben wir außerdem in unserem Artikel über die AGENTS.md-Verzeichniskette beschrieben.