38 KI-Agenten, die weiterlaufen, wenn niemand hinschaut

Das Problem

Ein KI-Agent im Chatfenster tut, was man ihm sagt, solange man zusieht. Das ist noch keine KI, die Arbeit erledigt. Die Lücke dazwischen ist unspektakulär: Was passiert, wenn niemand hinschaut?

Jeder echte Ausfall, den ich erlebt habe, war ein Betriebsproblem, keine Frage der Intelligenz:

• Die Maschine startet neu. Alle Agenten sind weg, und niemand merkt es.
• Ein Agent wird untätig, obwohl Arbeit wartet. Er hat seine Aufgabe erledigt und wartet jetzt darauf, angesprochen zu werden.
• Ein Agent stürzt ab, aber seine Sitzung lebt weiter. Jeder Health-Check meldet Grün, während der Agent tot ist. Das ist der teure Fall.
• Ein Agent stirbt mitten in einem Auftrag. Der Auftrag bleibt für immer „in Arbeit“, und kein anderer Agent rührt ihn an.
• Eine Aufgabe braucht Zugangsdaten. Dann trifft eine einzige falsche Anweisung potenziell jeden Kunden.

Mit einem besseren Prompt ist davon nichts gelöst. Das ist klassische Zuverlässigkeitsarbeit – und nach meiner Erfahrung genau das, was Firmen davon abhält, Agenten produktiv einzusetzen. Nicht die Fähigkeiten der Modelle.

Der Ansatz: Queue, Watchdog und eine echte Definition von „läuft“

Aufträge über eine Queue statt über Aufmerksamkeit. Aufgaben kommen über Slack und eigene Message Queues (Node.js + SQLite) an, jeweils markiert mit dem Agenten, dem sie gehören. Agenten übernehmen, arbeiten, antworten. Ein geplanter Job stupst jede Sitzung an, damit ein untätiger Agent wartende Arbeit aufnimmt, ohne dass ihn jemand anspricht. Arbeit erzeugen und abarbeiten sind komplett entkoppelt: Ich kann um Mitternacht zwanzig Aufgaben einstellen und schlafen gehen.

Ein Supervisor, der genau weiß, was „läuft“ heißt. Ein Steuerungswerkzeug liefert Status, ensure-all, Neustart, einen Pane-Dump für verstummte Agenten und einen doctor-Befehl, der Konfigurationsabweichungen und fehlende Scheduler-Einträge findet. Der Watchdog läuft jede Minute und beim Booten. Abgestürzte Agenten werden automatisch neu aufgebaut – mit Schutz gegen Neustart-Schleifen: höchstens 3 Neustarts in 30 Minuten.

Die wichtigste Designentscheidung: „Läuft“ heißt nicht „die Sitzung existiert“. Genau diese Prüfung hat abgestürzte Agenten unsichtbar gemacht. Der Supervisor schaut nach, was in der Sitzung tatsächlich läuft – denn der Fehler, den ich am dringendsten erkennen musste, war der, der gesund aussieht.

$ agentctl doctor
── registry drift ───────────────────────
  ✓ registry matches disk
── keepalive coverage ───────────────────
  ✓ all agents covered
── recovery jobs ────────────────────────
  ✓ @reboot recovery installed
  ✓ periodic ensure installed
── unmanaged sessions (informational) ───
  ℹ  ad-hoc sessions, not supervised
✓ doctor: no problems found

Neue Kunden-Agenten richte ich per Skript in wenigen Minuten ein. Rund 30 begleitende Dienste laufen unter pm2.

Trennung nach Schadensradius

Trennung pro Maschine. Kundenarbeit läuft auf dem dauerhaft laufenden Server, der die Kunden-Zugangsdaten hält. Experimentelles läuft auf der GPU-Workstation mit eigener Queue und eigener Datenbank; die Supervisor-Konfiguration dort lehnt Kunden-Agenten grundsätzlich ab. Beide Flotten laufen ohne Berechtigungsabfragen – und genau deshalb erzwingt die Maschine die Grenze, nicht der gute Vorsatz.

Hängende Aufträge, pro Maschine abgestimmt. Ein Reaper gibt Aufträge wieder frei, die ein abgestürzter Agent noch festhält. Auf der GPU-Maschine ist sein Timeout länger, weil ein Transkriptions-Batch oder ein Render dort zu Recht länger dauert – und einen laufenden Auftrag neu zu vergeben, verschwendet genau die GPU, auf die er gewartet hat.

Die Portierung: drei Fehler, die gleich aussahen

Den Supervisor habe ich auf dem Server gebaut und dann auf die Workstation übertragen. Er scheiterte dreimal, und jedes Mal sah es gleich aus: Sitzung da, Agent tut nichts.

1. Die Vertrauensabfrage war umgekehrt. Auf der einen Maschine war „Yes, I trust this folder“ vorausgewählt, auf der anderen stand „No, exit“ oben. Der Supervisor antwortete nach Tastenposition und wählte auf der zweiten Maschine zielsicher Nein. Der Agent beendete sich, die Sitzung blieb als leere Shell bestehen, und jeder Health-Check blieb grün. Lösung: die Option über ihre Beschriftung wählen – das übersteht auch die nächste Umsortierung im Upstream.
2. In einem Verzeichnis starten heißt nicht, darin zu sein. Das Shell-Profil der Workstation setzte jede neue Sitzung zurück ins Home-Verzeichnis. Die Agenten öffneten den falschen Arbeitsbereich, fanden keine Spezifikationsdatei und liefen ganz ohne Anweisungen und Grenzen. Der gefährlichste der drei Fehler, und der leiseste. Lösung: ein expliziter Verzeichniswechsel vor dem Start.
3. Ein Health-Check, der immer warnt, liest niemand. Ich hatte die Keepalive-Skripte – eines pro Agent – zu einem parametrisierten Skript zusammengelegt. Der doctor-Befehl erkannte Agenten an ihrem Namen in der Scheduler-Zeile, und das generische Skript nennt keinen davon. Also warnte jeder Agent dauerhaft. Eine Prüfung, die immer anschlägt, erzieht dazu, sie zu ignorieren – das ist schlimmer als gar keine.

Ein still falsch konfigurierter Agent ist schlimmer als ein offensichtlich toter. Der tote wird neu gestartet. Der falsch konfigurierte nimmt weiter Arbeit an.

Ergebnis und wo das passt

Heute laufen 38 Claude-Code-Agenten auf zwei Maschinen (31 auf dem Server, 7 auf der GPU-Workstation unter WSL2), verteilt auf insgesamt 57 tmux-Sitzungen. 18 davon sind Kunden-Experten-Agenten, einer pro Agenturkunde, jeder mit eigener CLAUDE.md und eigenen Wissensdateien. Sie erledigen jeden Tag echte Arbeit und kommen nach Neustarts und Abstürzen ohne Eingriff wieder hoch. Steuern kann ich sie auch unterwegs per Claude-Code-Remote-Control.

Die schwierigen Teile waren Zuverlässigkeit, Isolation und Beobachtbarkeit – nicht das Modell.

Das passt für jedes Team, das einen KI-Workflow im Chatfenster erprobt hat und ihn jetzt unbeaufsichtigt, zeitgesteuert und in großer Menge laufen lassen will – ohne dass jemand danebensitzt, und so, dass man Ausfälle selbst bemerkt, statt sie vom Kunden zu hören. Genauso passt es überall dort, wo Agenten strikt von produktiven Zugangsdaten getrennt sein müssen, also in den meisten regulierten Umgebungen.

Technik