Hermes Kanban ist das eingebaute Multi Agent Board von Hermes Agent. Aufgaben liegen als Tasks auf einem Board, bekommen einen zuständigen Agenten und dürfen voneinander abhängen. Ein Dispatcher startet fertige Tasks automatisch, mehrere Worker arbeiten parallel, und jeder Schritt bleibt nachvollziehbar.

Der Unterschied zum einfachen Delegieren ist die Struktur. Ein Subagent erledigt eine Aufgabe und verschwindet. Auf dem Board bleiben Zustand, Abhängigkeiten, Versuche und Übergaben erhalten. Damit taugt Kanban für Arbeit, die länger läuft als eine Session und mehr als einen Kopf braucht.

Kanban kam mit den Versionen 0.12 und 0.13 im Frühjahr 2026 und wurde seitdem in fast jedem Release ausgebaut. Aktuell ist es ein eigenständiger Baustein neben dem Bot Mode, mit eigenem Toolset, eigenem Dashboard und Anbindung an alle Gateways.

Never Code Alone arbeitet täglich mit KI Agenten im echten Projektalltag. Unser Stack läuft auf Sulu, Symfony, Astro und Cypress, dazu n8n und Paperclip für Workflows. Wir kennen den Punkt, an dem ein einzelner Agent nicht mehr reicht und Orchestrierung anfängt, mehr Probleme zu machen als zu lösen. Genau dort ordnen wir ein, statt Werkzeuge zu verkaufen.

Passend dazu helfen wir bei Vibe Coding Consulting, beim Agentic Coding im Team, bei Best Practices für KI gestützte Entwicklung, beim Aufbau von Qualitätsgates mit PHP Refactoring und bei der Auswahl passender KI Modelle. Für Teams, die den Einstieg suchen, gibt es das Vibe Coding Training.

Ein Task hat einen Titel, einen Rumpf, einen zuständigen Agenten, eine Priorität und optional einen Mandanten. Der spannende Teil sind die Abhängigkeiten. Wer ein Kind an einen Elterntask hängt, legt damit die Reihenfolge fest. Nur Tasks ohne offene Eltern stehen auf ready, alles andere wartet in todo. Diese Beförderungslogik erledigt das Board von allein.

Im Beispiel startet nur der Schema Task. Die API wartet auf das Schema, die Tests warten auf die API. Kein Worker greift sich das Testschreiben, solange es nichts zu testen gibt. Genau diese Selbstverständlichkeit fehlt bei loser Delegation.

Der Dispatcher läuft im Gateway Prozess und prüft im Standard alle 60 Sekunden, ob etwas bereitsteht. Es gibt keinen zusätzlichen Dienst zu installieren. Läuft kein Gateway, bleiben fertige Tasks einfach liegen, darauf weist Hermes beim Anlegen hin. Der frühere eigenständige Daemon ist abgekündigt, der Weg führt über das Gateway.

Ein wichtiges Detail für das Verständnis: Die Agenten, die der Dispatcher startet, sehen weder das Dashboard noch die CLI. Sie steuern das Board über ein eigenes Toolset. Das erste, was ein frisch gestarteter Worker tut, ist der Aufruf von kanban_show, um seinen Auftrag zu lesen. Danach meldet er Fortschritt, hängt Ergebnisse an oder blockiert sich selbst, wenn etwas fehlt.

Für Menschen gibt es das Dashboard unter hermes dashboard. Dort sieht man Spalten, Versuche, Dauer und die Übergabezusammenfassung jedes Laufs. Zusätzlich ist jeder CLI Befehl als Slash Befehl aus jedem Gateway erreichbar, von Telegram über Slack bis Mail. Beide Wege laufen durch dieselbe Datenschicht, die Sicht driftet also nicht auseinander.

Wer Worker Profile pflegt, prüft vorher, ob das Kanban Toolset im jeweiligen Profil überhaupt freigegeben ist. Ein Worker ohne diese Tools nimmt den Task an und kommt nicht weiter. Das ist der häufigste Stolperstein beim ersten Aufbau.

Für den häufigsten Fall gibt es eine Abkürzung. Ein Swarm zerlegt eine Aufgabe in parallele Worker, hängt einen Prüfer dahinter und lässt am Ende jemanden zusammenfassen. Der Graph wird atomar angelegt: entweder steht die komplette Struktur oder gar nichts. Halb verdrahtete Bretter gibt es nicht.

Danach läuft alles wie bei jedem anderen Task. Die Worker arbeiten gleichzeitig, der Prüfer wacht auf, sobald alle fertig sind, und der Zusammenfasser startet erst, wenn der Prüfer die Arbeit für sauber erklärt. Diese Kette ist der Grund, warum Ergebnisse aus einem Swarm brauchbarer sind als drei parallele Chats, die niemand gegenliest.

Wichtig bleibt die Rollentrennung. Wer prüft, hat nicht selbst geschrieben. Das gilt bei KI Agenten genauso wie bei Menschen und ist der einzige Weg, aus paralleler Arbeit auch belastbare Arbeit zu machen.

Nous Research nennt fünf Muster, für die Kanban gebaut wurde. Sie beschreiben ziemlich genau die Grenze, ab der loses Delegieren aufhört zu tragen.

Recherche mit Vorsortierung: mehrere Rechercheure parallel, ein Analyst dahinter, ein Mensch mit letztem Wort. Wiederkehrende Abläufe: tägliche Zusammenfassungen, die über Wochen ein Journal aufbauen. Dauerhafte Assistenten: benannte Helfer für Postfach oder Betrieb, die mit der Zeit Wissen ansammeln. Entwicklungsketten: zerlegen, parallel in eigenen Worktrees umsetzen, prüfen, iterieren, Pull Request. Flottenarbeit: ein Spezialist betreut viele gleichartige Objekte, etwa überwachte Dienste.

Für die Entwicklungskette lohnt der Blick auf Git Worktrees. Parallele Agenten brauchen getrennte Arbeitsverzeichnisse, sonst treten sie sich gegenseitig auf die Füße. Und vor jeder Automatisierung von Umbauten gilt die Reihenfolge, die wir bei Refactoring immer predigen: erst Qualitätsgates mit statischer Analyse und Tests, dann aufräumen.

Ein Board macht Arbeit sichtbar, es macht sie nicht billiger. Jeder Worker ist ein eigener Kontext, jeder Prüfdurchlauf kostet erneut. Wer einen Swarm mit fünf Rollen auf eine unscharfe Aufgabe wirft, zahlt fünfmal für fünfmal dieselbe Unschärfe. Vorher zuschneiden schlägt hinterher zusammenfassen.

Verbrauch messen und deckeln gehört deshalb dazu. Ein Proxy mit harten Budgets wie LiteLLM schaltet am Limit ab, statt still weiterzulaufen. Für Dauerläufer eignen sich kleine Modelle über Ollama, die großen Modelle bleiben den Schritten vorbehalten, die sie wirklich brauchen.

Beim Datenschutz gilt die NCA Regel: Coding aus der Cloud, Datenverarbeitung im eigenen Netz. Ein Worker mit Terminalzugriff, der stundenlang unbeaufsichtigt läuft, gehört gegen lokale Entwicklungsumgebungen mit Fake Daten, nie gegen echte Bestände. Zugriffe werden pro Worker Profil einzeln freigegeben. Wer weiter denkt, plant das als self hosted Architektur und prüft die Compliance Anforderungen vorher.

Ehrlich bleibt auch: Automatisch startende Agenten sind kein Selbstläufer. Ein Task, der auf fehlende Zugangsdaten läuft, blockiert und wartet auf einen Menschen. Genau so soll es sein. Wer das Board als Ersatz für Verantwortung versteht, bekommt schnell ein sehr ordentlich dokumentiertes Chaos.

Never Code Alone beobachtet das Feld der Agenten Orchestrierung seit seinem Aufkommen und ordnet Plattformen für Teams ein. Wir vergleichen Architekturen, nicht Feature Listen: Paperclip mit Org Chart und Budget, CrewAI mit Rollen, LangGraph mit Graphen und Hermes Kanban mit Board und Abhängigkeiten.

Die Erfahrung aus Beratungsprojekten ist eindeutig: Teams scheitern selten am Werkzeug und fast immer am Zuschnitt. Zu große Aufgaben, zu breite Rechte, kein Prüfschritt. Deshalb fangen wir mit Qualitätsgates an: statische Analyse, Unit Tests, funktionale Tests und E2E Tests mit Cypress. Erst wenn die stehen, darf ein Agent unbeaufsichtigt arbeiten.

Wer Hermes Kanban ausprobieren will, startet klein: ein Mandant, drei Tasks, ein Worker Profil mit eng freigegebenen Tools. Danach wächst das Brett mit dem Vertrauen. Beim Aufbau von Guardrails und beim Einordnen gegen den eigenen Stack begleiten wir Teams von Anfang an.

Die wichtigsten Fragen und Antworten rund um das Multi Agent Board von Hermes Agent: Aufbau, Dispatcher, Abgrenzung zu Bot Mode, Kosten und der DSGVO konforme Betrieb.