Kanban in Hermes Agent voor zelfgehoste LLM-workflows

Hermes Agent wordt geleverd met een Kanban-stijl board en de Hermes Gateway, die uw self-hosted LLM kan verzadigen als er te veel taken tegelijk worden uitgestuurd.

Ik kan zeggen dat je op deze manier je eigen LLM makkelijk kunt ddos-en.

Hermes Kanban is een duurzaam multiprofiel-board dat wordt ondersteund door ~/.hermes/kanban.db.
Elke lane vertegenwoordigt een fase van het werk, en elke kaart is een taak die kan worden geclaimd door een specifiek Hermes-profiel.
Standaard kan de dispatcher veel ready-taken in één keer promoten. Dat is prima voor elastische cloud-API’s, maar het kan een klein self-hosted GPU-cluster overbelasten.

Als u nieuw bent in deze stack, begin dan met de bredere Hermes setup en operations guide en de AI Systems pillar voor de omliggende architectuur.

Dit bericht toont hoe je:

• Begrijpt hoe Hermes Kanban dispatch interacteert met je LLM-gateway.
• Controleert parallelisme veilig voor zware taken.
• Batcht promoties met cron zodat achtergrondtaken niet botsen met interactief gebruik.
• Monitort en fine-tuned het systeem zodat GPUs druk blijven zonder overbelasting.

Hoe Hermes Kanban en de dispatcher werken

Op een hoog niveau heeft het systeem drie lagen:

1. Board - duurzame SQLite-status voor taken, kolommen, relaties, en geschiedenis.
2. Workers - Hermes-profielen gestart in geïsoleerde werkruimten om een taak te verwerken.
3. Dispatcher - een langlopend proces dat scant naar dispatchbare kaarten en runs start.

Taken die vanuit de CLI of dashboard worden aangemaakt, starten meestal in backlog of ready.
De dispatcher scant naar geschikte kaarten, claimt er één atoomair, en start het toegewezen profiel met zijn tools en geheugen.
Elke worker roept dan je LLM-gateway of lokale runtime aan (bijvoorbeeld OpenAI-compatibele endpoints ondersteund door Ollama, vLLM, of llama.cpp). Voor keuzes rondom deployment across deze runtimes, gebruik de LLM Hosting in 2026 Local Self-Hosted en Cloud Infrastructure Compared. Als je request fan-out op Ollama zelf fine-tuned, dit combineert goed met How Ollama Handles Parallel Requests.

Als je veel zware taken toevoegt en geen limiet stelt aan promoties, kan je gateway worden overvloed met gelijktijdige requests.
Op een single-GPU of CPU-beperkte host betekent dat vaak wachtrijen, thrashing, en timeouts in plaats van betere throughput.

De praktische beperking vandaag

In huidige Hermes builds die veel teams draaien, exposeert dispatcher config slechts twee Kanban dispatch keys en past geen globale active-task cap toe vanuit config:

kanban:
  dispatch_in_gateway: false
  dispatch_interval_seconds: 10

Voor active-task controle, vertrouw op expliciete dispatch cadence (hermes kanban dispatch --max ...) plus dependency modeling.

Bekende valkuilen:

• Voer gateway-embedded dispatch en hermes kanban daemon --force niet tegen hetzelfde board uit, anders kun je claim races krijgen.
• Als de gateway down is, dispatchen ready taken niet en kunnen later bursten wanneer de service terugkeert.
• Langere dispatch intervals voelen ongelijk omdat claiming in ticks gebeurt.
• Gedrag kan variëren tussen versies omdat run-state en reclaim edge cases in de loop der tijd zijn gepatcht.

Snelle verificatie wanneer het gedrag er verkeerd uitziet:

# 1) bevestig dat precies één dispatcher path actief is
pgrep -af "hermes gateway start|hermes kanban daemon"

# 2) check de bedrade Kanban dispatcher keys
rg "dispatch_in_gateway|dispatch_interval_seconds" ~/.hermes/config.yaml

# 3) inspecteer de wachtrij vorm
hermes kanban list --status ready
hermes kanban list --status running

Belangrijke ideeën:

• Dispatcher config bedraadt dispatch_in_gateway en dispatch_interval_seconds.
• dispatch --max beperkt nieuwe spawns in die pass, niet totale lopende taken.
• Voor kleine self-hosted clusters, begin conservatief en verhoog pas als de latency stabiel blijft.

Bij het eerste deployen van Hermes nabij je LLM gateway:

• Houd alleen ondersteunde Kanban dispatcher keys in config.
• Observeer GPU en CPU utilizatie onder echte wachtrij druk.
• Gebruik Strategie 1 of Strategie 2 voor deterministische pacing.

Onderzoeksvindsten en root cause

hermes kanban dispatch leest config.yaml niet voor max_active_tasks.

In hermes_cli/kanban.py, exposeert de dispatch command --max als een CLI cap (default None) en passant alleen args.max naar kb.dispatch_once(...). Er is geen max_active_tasks config lookup in deze path. Zie hermes_cli/kanban.py raw.

Dan in kanban_db.dispatch_once, is de enige cap max_spawn, met logica equivalent aan:

if max_spawn is not None and spawned >= max_spawn:
    break

Er is geen check van al lopende taken en geen max_active_tasks referentie in die dispatch path. Zie hermes_cli/kanban_db.py raw.

Effectief gedrag:

hermes kanban dispatch

ongebonden voor die pass (beperkt door ready wachtrij grootte).

hermes kanban dispatch --max 2

beperkt alleen nieuwe spawns in die pass, niet totale lopende taken.

De bedrade config knoppen rondom gateway dispatch zijn kanban.dispatch_in_gateway en kanban.dispatch_interval_seconds.
Dus max_active_tasks wordt genegeerd in deze dispatch path omdat het daar niet is geïmplementeerd.

Strategie 1 - Encodeer dependencies voor strikt sequentiële flows

Sommige workflows moeten strikt na elkaar draaien — bijvoorbeeld:

• multi-step data pipelines met gedeelde intermediaire artefacten
• migraties of infrastructurele wijzigingen
• batch jobs die schrijven naar dezelfde object store of database

Hermes Kanban ondersteunt parent-child dependencies tussen taken zodat een child-card alleen dispatchbaar wordt wanneer zijn parent klaar is.

Je kunt dit modelleren met een kleine helper script rondom de Hermes CLI:

#!/usr/bin/env bash

set -euo pipefail

parent_id="$(hermes kanban add \
  --title 'Ingest customer logs voor April' \
  --profile 'etl-worker' \
  --column backlog)"

hermes kanban add \
  --title 'Genereer April anomaly rapport' \
  --profile 'analytics-worker' \
  --column backlog \
  --parent "${parent_id}"

hermes kanban add \
  --title 'Publiceer April samenvatting naar dashboard' \
  --profile 'reporting-worker' \
  --column backlog \
  --parent "${parent_id}"

Met een passend board beleid en lage dispatcher limits draait alleen de parent taak eerst.
Zodra deze af is, worden de child taken geleidelijk ready, en de dispatcher trekt ze één voor één zonder ooit je concurrency caps te overschrijden.

Strategie 2 - Gebruik Linux cron met een running-aware dispatch cap

Als je deterministische pacing wilt, gebruik host cron plus een kleine wrapper script.
In plaats van altijd dispatch --max 2 aan te roepen, tel eerst momenteel lopende taken, en dispatch alleen de resterende slots.

Maak hermes-kanban-dispatch-capped.sh:

#!/usr/bin/env bash
set -euo pipefail

MAX_PARALLEL="${MAX_PARALLEL:-2}"
BOARD="${BOARD:-}"

board_args=()
if [[ -n "$BOARD" ]]; then
  board_args=(--board "$BOARD")
fi

# of waar je hermes is geïnstalleerd
export PATH="/home/abc/.local/bin:$PATH"

running_out="$(hermes kanban "${board_args[@]}" list --status running)"

if [[ "$running_out" == *"(no matching tasks)"* ]]; then
  running_count=0
else
  running_count="$(printf '%s\n' "$running_out" | wc -l)"
fi

slots=$(( MAX_PARALLEL - running_count ))

if (( slots <= 0 )); then
  echo "Al op limiet running=$running_count max=$MAX_PARALLEL dispatch overgeslagen"
  exit 0
fi

echo "running=$running_count max=$MAX_PARALLEL slots=$slots dispatching tot $slots"

hermes kanban "${board_args[@]}" dispatch --max "$slots"

Maak het uitvoerbaar:

chmod +x ./hermes-kanban-dispatch-capped.sh

Voer het uit met:

MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Voor een specifiek board:

BOARD=my-board MAX_PARALLEL=2 ./hermes-kanban-dispatch-capped.sh

Plan het eens per minuut met cron:

* * * * * /opt/hermes/scripts/hermes-kanban-dispatch-capped.sh >> /var/log/hermes/kanban-cron.log 2>&1

Operationele notities:

• Cron heeft vaak een minimale PATH, dus als hermes niet wordt gevonden, gebruik dan het volledige pad binnen de script (bijvoorbeeld /usr/local/bin/hermes).
• Als je logt naar /var/log/hermes/..., maak die directory eerst aan en zorg dat de cron user schrijftoegang heeft.

Voorbeeld:

sudo mkdir -p /var/log/hermes
sudo chown "$USER":"$USER" /var/log/hermes

Maak of bewerk cron entries met:

crontab -e

En verifieer met:

crontab -l

Sub-minute cadence met één cron entry

Cron tikt eens per minuut, maar je kunt nog steeds frequenter dispatchen door een korte loop binnen de script te draaien.

Voorbeeld hermes-kanban-dispatch-subminute.sh:

#!/usr/bin/env bash
set -euo pipefail

LOCK_FILE="/tmp/hermes-kanban-dispatch.lock"
RUNS_PER_MINUTE="${RUNS_PER_MINUTE:-4}"    # 4 runs => elke 15 seconden
CAP_SCRIPT="${CAP_SCRIPT:-/opt/hermes/scripts/hermes-kanban-dispatch-capped.sh}"

exec 9>"$LOCK_FILE"
flock -n 9 || exit 0

sleep_seconds=$(( 60 / RUNS_PER_MINUTE ))

for ((i=1; i<=RUNS_PER_MINUTE; i++)); do
  "$CAP_SCRIPT"

  if (( i < RUNS_PER_MINUTE )); then
    sleep "$sleep_seconds"
  fi
done

Maak het uitvoerbaar:

chmod +x ./hermes-kanban-dispatch-subminute.sh

Plan het eens per minuut:

* * * * * /opt/hermes/scripts/hermes-kanban-dispatch-subminute.sh >> /var/log/hermes/kanban-subminute.log 2>&1

Dit geeft een effectieve sub-minute cadence terwijl flock overlappende runs voorkomt.

Waarom dit werkt:

• list --status running geeft de huidige lopende load.
• dispatch --max N beperkt alleen nieuwe spawns voor die pass.
• Het berekenen van N als resterende slots houdt totale lopende taken dicht bij je doel limiet.

Belangrijke nuance: deze cap werkt alleen voor dispatches gemaakt via deze script.
Schakel gateway embedded dispatch uit, anders kan het taken nog steeds onafhankelijk promoten:

kanban:
  dispatch_in_gateway: false

De officiële docs beschrijven beide commando mogelijkheden en noteren gateway dispatch defaults in de Kanban feature guide: Hermes Kanban docs.

Interne Hermes Cron

Gebruik het niet. Wil je echt dat je llm regelmatige prompts verwerkt zoals Execute in terminal the command /path/hermes-kanban-dispatch-capped.sh, vooral wanneer het druk is met nuttig werk?

Hermes Kanban Monitoring en Tuning

Welke strategie je ook kiest, je zou moeten monitoren:

• LLM gateway metrics — request rate, latency, error rate, token throughput.
• Node health — GPU utilizatie, VRAM gebruik, CPU load en RAM.
• Hermes metrics — hoeveel taken zijn in backlog, ready, active en done.

Voor productie metric baselines en dashboards, zie Monitor LLM Inference in Production met Prometheus en Grafana en de bredere LLM Performance hub.

Begin met lage concurrency, en verhoog dan geleidelijk de limits terwijl je kijkt naar:

• stijgende latency bij constante throughput
• toenemende timeout of rate limit errors
• lange tails waarbij sommige taken zeer lang actief blijven

Zodra je deze symptomen ziet, roll back naar de vorige stabiele configuratie en behoud die als je default.

Wanneer Kanban het juiste tool is

Hermes Kanban blinkt uit wanneer je:

• langlopende research of engineering backlogs hebt
• multi-agent samenwerking hebt met genoemde profielen
• workflows hebt die restarts en host reboots moeten overleven
• mensen hebt die een dashboard willen om werk te triagelen

Als je alleen een single run nodig hebt om een paar tijdelijke helpers te maken, zijn de ingebouwde delegate task tools meestal eenvoudiger.
Zodra je geschiedenis, dashboards en strikte controle nodig hebt over hoe je agents self-hosted LLMs raken, is het Kanban board plus dispatcher de juiste basis.

Met een paar configuratie tweaks en optionele cron-based batching kun je Hermes Kanban responsief houden terwijl je je gateway en hardware beschermt.