Das Problem
Alles über einen Kunden ist auf viele Werkzeuge verteilt: Zoom-Transkripte jedes Meetings, Aufgaben in ProofHub, Gespräche in Slack — auch im eigenen Slack-Bereich des Kunden — und vier Werbeplattformen.
Fragen wie „Was hat der Kunde gestern geschrieben?“, „Welche Action Items stehen noch nicht in ProofHub, und wer ist zuständig?“ oder „Wer muss dem Kunden noch antworten?“ hießen: mehrere Werkzeuge öffnen und viel lesen.
So ist es gebaut
- Ein Agent pro Kunde. Jeder der 18 Kunden hat eine eigene Claude-Code-Sitzung mit eigenen Anweisungen und Wissensdateien.
- Ein Router im Kanal. Ein zentraler Agent liest jede Frage, erkennt, um welchen Kunden es geht, und leitet sie an dessen Agenten weiter.
- Wissen in Dateien, von den Agenten selbst aktuell gehalten. Zum Beispiel eine Roadmap pro Kunde. Nach einem Neustart geht nichts verloren — ohne die Anweisungen ständig zu ändern.
- Für das Team nur lesend — im Code durchgesetzt. Keine Änderungen an Anzeigen, Landingpages oder WordPress. Die Grenze ist programmatisch gesetzt, nicht nur in einen Prompt geschrieben.
- Eine Ausnahme, nur für mich: Ich kann über die Agenten Landingpages bauen lassen; solche Anfragen gehen an einen eigenen Landingpage-Agenten.
So sieht das aus
| Von | Nachricht |
|---|---|
| Jamie (Account Manager), 09:12 | Welche Action Items aus dem letzten Meeting mit Acme HVAC stehen noch nicht in ProofHub — und wer ist zuständig? |
| client-control, 09:12 → weitergeleitet an den Acme-HVAC-Agenten | Aus dem Call am Dienstag fehlen noch zwei Punkte in ProofHub: überarbeitetes Sommerbudget senden — Dana; Call-Tracking auf der neuen Landingpage prüfen — Luis. Außerdem schuldet Dana dem Kunden noch eine Antwort auf die Slack-Nachricht vom Montag. |
| Jamie (Account Manager), 09:14 | Pausier die Samstags-Anzeigen für Acme. |
| client-control, 09:14 → Acme-HVAC-Agent | Ich kann keine Kampagnen ändern — dieser Kanal ist nur lesend. Unten stehen die aktuellen Samstagsausgaben und der Kampagnen-Link, damit das PPC-Team die Änderung machen kann. |
# client-control, fiktiver Kunde „Acme HVAC“, fiktive Namen). Echte Verläufe enthalten Kundendaten und werden nicht gezeigt.Betrieb rund um die Uhr
- 38 Agenten auf zwei Servern (31 + 7)
- 57 tmux-Sitzungen insgesamt
- ~30 Dienste unter pm2
- 1 Min. Watchdog-Takt
- 3 / 30 Min. Neustart-Grenze gegen Schleifen
- Minuten, bis ein neuer Kunden-Agent per Skript steht
Abgestürzte Agenten werden automatisch neu aufgebaut. Ein Schutz gegen Neustart-Schleifen stoppt nach drei Neustarts in 30 Minuten, damit ein defekter Agent die Maschine nicht dauerhaft beschäftigt.
Neue Kunden-Agenten entstehen per Skript in Minuten. Die Flotte lässt sich auch aus der Ferne bedienen, unter anderem per Claude Code Remote Control.
Der Betrieb im Detail: Lebenszeichen-Prüfung, hängende Jobs und drei Fehler beim Portieren →
Was ich jedem rate, der so etwas baut
- Jedem Agenten einen Kunden geben. Jeder Agent hat eigene Sitzung, Anweisungen und Wissensdateien — so ist immer klar, wohin Wissen über einen Kunden gehört.
- Grenzen im Code setzen, nicht im Prompt. Das Team darf alles fragen; die Agenten können technisch nichts ändern.
- Gedächtnis in Dateien halten. Agenten starten neu. Wissen in Dateien, die sie selbst pflegen, übersteht das.
- Davon ausgehen, dass Agenten abstürzen. Watchdog, Neuaufbau und Schleifenschutz planen, bevor der erste Agent live geht.