Hermes Kanban: 7 Funktionen – stark und sicher für Bot-Teams

Hermes Kanban ist ein dauerhaftes, geteiltes Kanban-Board für mehrere Hermes-Profile: Jede Aufgabe liegt als eigene Zeile in einer SQLite-Datenbank, jeder Bot liest und schreibt sie über ein festes Set von Werkzeugen, und nichts verschwindet, wenn eine Sitzung endet. Damit lässt sich eine nüchterne Frage beantworten: Was unterscheidet ein Kanban-Board für KI-Agenten von einer hübsch verpackten To-Do-Liste? Zustandsverwaltung, Wiederaufnahme nach Abstürzen und ein Protokoll, das mehrere Bots ohne Chaos an derselben Aufgabe arbeiten lässt. Wer Hermes Kanban nur als weiteres Feature-Häkchen abtut, hat den eigentlichen Bruch verpasst: weg vom Einzelgespräch, hin zu einem System, in dem Aufgaben Wochen überleben, statt mit dem Chatfenster zu sterben.

Hermes Kanban: Was sich hinter dem Namen verbirgt

Der Name klingt nach Marketing-Folie, ist aber wörtlich zu nehmen. Wie die Referenzseite zum Kanban-System beschreibt, ist jede Aufgabe eine Zeile mit Titel, optionalem Text, genau einem zuständigen Profil, einem Status zwischen triage und done sowie einem optionalen Namensraum für Mandanten. Zwei Zugänge teilen sich dieselbe Datenbank: Agenten rufen ein dediziertes kanban_*-Werkzeugset auf, Menschen bedienen dieselbe Datei über die Kommandozeile, den Slash-Befehl /kanban oder das Dashboard. Manche nennen das Ganze schlicht Aufgabenboard — gemeint ist dasselbe Kanban-Board.

Diese Trennung ist Absicht. Kanban-Worker greifen über ihre dedizierten Werkzeuge auf die Karte zu; Menschen nutzen CLI, Slash-Befehl oder Dashboard. Hermes Kanban hält damit beide Zugänge auf derselben Datenbasis, ohne ihre Bedienwege zu vermischen. Version 0.13 hat diese Grenze sogar noch verschärft und die Worker-Identität aus der allgemeinen Anleitung entfernt, die jedem Modell mitgegeben wird — ein Detail, das nach Kleinkram aussieht, aber verhindert, dass sich ein Worker versehentlich als jemand anderes ausgibt, wenn eine Karte weitergereicht wird.

Warum ein Chat-Fenster für mehrstufige Arbeit nicht reicht

Für kurze, klar umrissene Teilfragen gibt es delegate_task: Ein Unteragent startet mit frischem Kontext, arbeitet in einer eigenen Sitzung und liefert seine Zusammenfassung zurück. Diese Delegation bleibt jedoch prozessgebunden. Sie ist richtig, wenn der übergeordnete Agent das Ergebnis zeitnah weiterverarbeitet. Sie ist falsch, wenn eine Recherche heute beginnt, ein anderes Profil sie morgen auswertet und ein Mensch übermorgen den Freigabeschritt übernimmt. Genau dafür gibt es das Kanban-Board: eine dauerhafte Warteschlange statt eines flüchtigen Unterauftrags. Drei Profile können nacheinander dieselbe Karte übernehmen, ohne dass der Zwischenstand in einem alten Chat gesucht werden muss.

Ein beliebter Mythos lautet: Ein Agent mit genug Kontextfenster erledigt jede mehrstufige Aufgabe allein, man müsse nur das Modell groß genug wählen. Die Realität ist nüchterner. Sitzungen werden komprimiert, Kontext geht verloren, und ein Prozess, der abstürzt, nimmt seinen Fortschritt mit ins Nichts — es sei denn, der Fortschritt steckt nicht im Gesprächsverlauf, sondern in einer Zeile einer Datenbank, die ein anderer Prozess jederzeit lesen kann. Named Profile statt anonymer Unteragent, Wiederaufnahme statt Alles-oder-nichts: Das ist der eigentliche Unterschied, kein kosmetisches Feature-Detail.

Der Workflow in der Praxis: Board, Karten, Übergaben

Der Arbeitsfluss kennt sieben klar getrennte Zustände: Triage, Todo, Ready, In Progress, Blocked, Review und Done. Eine neue Aufgabe landet in Triage, wo ein Decomposer sie bei Bedarf in Teilaufgaben zerlegt; sobald alle Abhängigkeiten erfüllt sind, rutscht sie nach Ready, und der Dispatcher übernimmt beim nächsten Tick. Genau diese Choreografie erklärt im Kanban-Tutorial anhand von vier konkreten Fällen: Solo-Entwicklung mit Schema-API-Test-Kette, Fleet-Arbeit mit mehreren parallelen Spezialisten, eine Pipeline mit Reviewer-Rückweisung und ein Circuit-Breaker gegen außer Kontrolle laufende Läufe. Jede dieser vier Geschichten zeigt dasselbe Grundmuster in einer anderen Besetzung: eine Karte, ein Status, ein Verantwortlicher, eine sichtbare Historie.

Beim Worker selbst ist der Ablauf denkbar knapp: kanban_show() liefert Titel, Auftragstext, bisherige Versuche und die Ergebnisse aller Elternaufgaben zurück, ohne dass der Worker seine eigene ID kennen muss. Läuft die Arbeit länger, meldet kanban_heartbeat() Lebenszeichen. Am Ende schließt kanban_complete() den Lauf, schreibt Zusammenfassung und Metadaten auf die Aufgabe und kippt den Status atomar auf done — alles in einem einzigen Schritt durch die Datenschicht.

Drei Übersetzer, fünf Transkriptionen und vier Produktbeschreibungen laufen so parallel ab, ohne dass ein Mensch jede einzelne Karte anstoßen muss; das Kanban-Board verteilt sie automatisch an die passenden Profile. Bricht ein Worker mitten in der Ausführung ab, weil der Prozess abstürzt oder die Maschine neu startet, markiert der Dispatcher die Karte nicht als erledigt, sondern öffnet beim nächsten Tick einen neuen Versuch — der Fortschritt bleibt in der Zeile stehen, nicht im flüchtigen Prozessspeicher.

Welche Sicherungen Hermes Kanban belastbar machen

Schnell gezeichnet ist jedes Kanban-Board. Belastbar wird es erst, wenn ein toter Worker nicht als erledigter Worker durchrutscht. Hermes beschreibt dafür Heartbeats, das Zurückholen veralteter Claims und einen Circuit-Breaker: Bleibt ein Lebenszeichen aus, kann die Aufgabe erneut freigegeben werden; wiederholte Startfehler blockieren die Karte nach einem festen Budget, statt eine Endlosschleife zu finanzieren. Maximaldauer und Wiederholungsgrenze lassen sich pro Aufgabe setzen. Das klingt unspektakulär. Genau deshalb ist es wichtig. Der Unterschied zwischen Demo und Betrieb steckt selten im bunten Board, sondern in der Frage, was nach einem Timeout passiert.

Auch Review und Blocked sind keine Dekoration. Eine fertige Implementierung kann zunächst in Review landen und bei Änderungsbedarf kontrolliert an den Bearbeiter zurückgehen. Fehlt dagegen eine echte menschliche Entscheidung, stoppt Blocked die Ausführung, ohne den Auftrag als gescheitert zu verbuchen. Das Kanban-Tutorial zeigt diese Übergänge anhand einer Rollenpipeline und eines Circuit-Breakers. Hermes Kanban ist damit kein Versprechen autonomer Magie, sondern ein Zustandsautomat mit sichtbaren Abbruchkanten. Das ist weniger glamourös — und deutlich nützlicher.

Skills und Gedächtnis: der Unterbau, auf dem Hermes Kanban aufsetzt

Ein Board allein macht aus einem Sprachmodell noch keinen zuverlässigen Mitarbeiter. Zwei weitere Bausteine sorgen dafür, dass ein Worker, der heute eine Karte übernimmt, nicht bei null anfängt. Skills sind bei Bedarf ladbare Wissensdokumente nach dem Prinzip der schrittweisen Offenlegung: eine schlanke Liste mit Namen und Beschreibung kostet kaum Kontext, der volle Inhalt wird erst geladen, wenn eine Aufgabe ihn tatsächlich braucht. Das Format folgt bewusst dem offenen agentskills.io-Standard, statt eine proprietäre Ablage zu erfinden. So bleibt eine Aufgabe wie Rechnungsprüfung oder Quellenrecherche einmal beschrieben und danach für jedes Profil abrufbar, ohne dass jede Sitzung erneut erklärt, wie ein bestimmter Ablauf funktioniert.

Persönliches Gedächtnis ist absichtlich klein gehalten, nicht aus Sparsamkeit, sondern als Designentscheidung: zwei Dateien, eine für Umgebungsfakten und Konventionen des Agenten, eine für Vorlieben der Nutzerin oder des Nutzers, beide mit festen Zeichenobergrenzen im niedrigen vierstelligen Bereich, wie die Seite zum dauerhaften Gedächtnis festhält. Wer unbegrenztes Erinnerungsvermögen erwartet, missversteht das Konzept: Ein Worker auf Hermes Kanban soll nicht alles wissen, sondern das Wenige zuverlässig behalten, das über eine einzelne Sitzung hinaus zählt, während der eigentliche Auftragskontext ohnehin aus der Kartenzeile selbst kommt. Für Sie heißt das: Sie erklären Vorlieben einmal, nicht bei jedem neuen Gespräch erneut.

Automatisierung ohne Kontrollverlust: Cron, Bots und Governance

Nicht jede wiederkehrende Aufgabe braucht ein Sprachmodell. Der no_agent-Modus für geplante Aufgaben lässt ein Skript nach Zeitplan laufen und liefert die Ausgabe unverändert aus: leerer Standard-Output bleibt lautlos, ein gefüllter wird wortwörtlich zugestellt, wie die Seite zu geplanten Aufgaben beschreibt. Für einen simplen Uptime-Check oder eine Preisabfrage ist das die günstigere und vorhersehbarere Variante gegenüber einem vollen Modellaufruf.

Komplexere Routinen bündelt Bot Mode dieselben Profile zu benannten Bots mit eigenem Modell, eigenem Gedächtnis und eigenen Skills — Bot Mode zeigt, wie Routinen als gewöhnliche Cron-Jobs im Namensraum [bot:<name>] laufen und ihre Ergebnisse direkt in der Chatgeschichte des jeweiligen Bots landen. Dass Unternehmen genau diese Art von nachvollziehbarer Steuerung für automatisierte Agenten inzwischen verlangen, zeigt sich auch dort, wo GitHub selbst seine Governance-Steuerung für Agenten-Automation in eine Public Preview überführt hat: Sichtbare Zustände, nachvollziehbare Übergaben und ein Nein-Knopf sind kein Luxus, sondern die Mindestanforderung, sobald Agenten tatsächlich etwas verändern dürfen. Ein Board, das jede Übergabe protokolliert, liefert genau diese Nachvollziehbarkeit von Haus aus, ohne dass eine Firma eine eigene Prüfschicht drum herum bauen muss.

Grenzen von Hermes Kanban: Wo Delegation aufhört

Blocked ist kein Fehlerzustand, sondern eine eingebaute Notbremse. Ein Worker, der auf eine echte menschliche Entscheidung wartet — fehlende Zugangsdaten, eine Geschmacksfrage, ein Ergebnis, das erst ein anderer Mensch liefern muss — meldet das explizit, statt zu raten. Der Mythos vom vollautonomen Agenten, der keine Aufsicht mehr braucht, übersieht, dass genau die Fälle, in denen Hermes Kanban nachträglich Sicherungen bekam, aus fehlender Aufsicht entstanden sind: Worker, die ohne Abschlussmeldung einfach verschwanden, oder Karten, die ein Modell schlicht erfunden hatte. Diese Fälle sind keine theoretischen Randnotizen, sondern der Grund, warum die jüngeren Versionen so viel Aufwand in Erkennung und Wiederherstellung stecken.

Praktisch heißt das für den Einstieg: Erst ein einzelnes Board mit zwei, drei Profilen aufsetzen, Abhängigkeiten klein halten und beobachten, wie oft eine Aufgabe tatsächlich in Blocked landet, bevor man auf eine ganze Flotte skaliert. Wenn Sie Hermes Kanban zum ersten Mal einrichten, sparen Sie sich damit die Fehlersuche in einer Kette von zehn parallel laufenden Karten.

Wer wissen will, wie eng Governance und Automatisierung zusammenhängen, findet ein Gegenbeispiel aus der Praxis dort, wo Agenten inzwischen die Firewall-Pflege in Unternehmen übernehmen: Auch dort funktioniert Automatisierung nur, weil klare Regeln, Protokolle und Eskalationswege vorher feststehen — nicht, weil ein Modell irgendwann autonom genug wurde. Hermes Kanban überträgt dasselbe Prinzip auf redaktionelle und organisatorische Arbeit: Delegation bis an die Grenze der Verantwortung, nicht darüber hinaus.