Sechs Rechner, ein Leitstand: KI-Agenten, die nur noch fragen, wenn es zählt

Das Problem

Mein Arbeitstag spielt sich auf zwei MacBooks ab, und ich wechsle ständig zwischen ihnen: Das 16-Zoll-MacBook mit M4 bleibt im Büro, das 14-Zoll-MacBook mit M5 ist für die Arbeit unterwegs.

Dazu kommen ein Mac mini, ein älteres MacBook, das für alle anderen Docker-Container betreibt, ein Linux-PC und ein gemieteter Server bei Hetzner. Auf jedem dieser sechs Rechner läuft ein KI-Agent (Hermes), auf den Macs dazu Claude Code.

Das klingt nach viel Hilfe. In der Praxis hieß es: sechsmal dieselbe Frage stellen, sechsmal nachsehen, ob noch Platz auf der Platte ist, und Wissen, das auf einem Rechner entstanden ist, auf den anderen nicht haben. Jeder Agent war für sich klug. Zusammen waren sie ein Haufen Einzelgespräche.

Das Ziel war deshalb nicht „mehr KI“, sondern weniger Rauschen: ein Ort, an dem alles zusammenläuft, und Agenten, die mich nur noch fragen, wenn eine Entscheidung wirklich von mir abhängt.

Schritt 1: Ein Stern statt sechs Einzelgespräche

Alle Rechner hängen in einem privaten Netz (Tailscale). Der Server ist die Drehscheibe, an der sich die Agenten anmelden. Ein Werkzeug namens mesh läuft alle 15 Minuten auf dem Büro-Mac und gleicht ab: Wissen, Skills und Programmversionen kommen auf jeden Rechner, und wer gerade offline war, bekommt den Rückstand beim nächsten Mal.

Das Wissen selbst liegt an zwei Stellen:

• Kuratiertes Wissen (Regeln, Rezepte, Erkenntnisse aus früheren Projekten) als Git-Repository, auf allen Rechnern gleich.
• Ein gemeinsames Gedächtnis, das „brain“: eine Datenbank auf dem Server mit den Zusammenfassungen aller Arbeitssitzungen, den Projektdokumenten und Notizen, die Agenten für spätere Sitzungen hinterlassen. Jeder Agent auf jedem Rechner kann darin suchen und hineinschreiben.

Schritt 2: Ein Gedächtnis, das Bedeutung versteht

Anfangs suchte das brain nur nach Wörtern. Wer fragte „Warum gilt das Restaurant-Feature nur in einem Land?“, fand nichts, wenn die Notiz auf Deutsch „Beta-Einschränkung auf Deutschland“ hieß.

Bevor ich das selbst baue, habe ich mir angesehen, was es schon gibt. TencentDB Agent Memory zum Beispiel ist ein beeindruckendes Projekt. Es arbeitet aber als Proxy, der zwischen Agent und Sprachmodell sitzt. Für Claude Code hieße das: eigener API-Schlüssel statt Abo, und jedes Gespräch landet ungefiltert in einer weiteren Datenbank. Übernommen habe ich deshalb nur zwei Ideen:

1. Suche nach Bedeutung. Jeder Eintrag bekommt einen Vektor, berechnet mit dem Modell bge-m3, lokal auf dem Server, ohne Cloud. Eine Suchanfrage dauert dafür etwa 0,07 Sekunden. Die Ergebnisse von Stichwort- und Bedeutungssuche werden zusammengeführt. Seitdem findet eine englische Frage auch die deutsche Notiz.
2. Fakten statt nur Protokolle. Nachts liest ein kleines lokales Modell (qwen3.5, 4 Milliarden Parameter, auf der CPU des Servers) jede Sitzung und zieht bis zu fünf dauerhafte Fakten heraus: Entscheidungen mit Begründung, Korrekturen, gemessene Werte. Jeder Fakt verweist auf seine Quelle. Das dauert etwa 75 Sekunden pro Sitzung und läuft zwischen zwei und fünf Uhr, wenn sonst nichts los ist.

Schritt 3: Der Leitstand

Der wichtigste Baustein ist eine Regel: Agenten schlagen vor, ich entscheide.

Statt mir Nachrichten zu schicken, legen Agenten einen Vorschlag ab: auf welchem Rechner, was genau, was es bringt, was schiefgehen kann. Ein Beispiel: „Inhalte aller iOS-Simulatoren löschen? Etwa 114 GB. Risiko: installierte Test-Apps sind weg, die Simulatoren selbst bleiben.“

Damit daraus kein neues Rauschen wird, gelten drei Regeln:

• Ein Eintrag pro Rechner und Thema. Schlägt ein Agent dasselbe noch einmal vor, zählt nur ein Zähler hoch.
• Ein Nein gilt 30 Tage. Danach fragt niemand dieselbe Frage erneut.
• Aufs Telefon kommt nur, was eilt. Eine fast volle Platte zum Beispiel. Alles andere wartet im Leitstand.

Der Leitstand selbst ist eine schlichte Webseite, erreichbar nur im privaten Netz. Oben steht in einem Satz, ob etwas wartet. Darunter die offenen Entscheidungen, nach Rechner gruppiert. Dann eine Karte pro Rechner, die schlechtesten zuerst, und für jeden Rechner eine eigene Detailseite.

Schritt 4: Warum ein Passkey und kein Passwort

Wer im Leitstand „Ja“ klickt, löst etwas aus, zum Beispiel das Löschen von Caches. Also muss feststehen, dass ich es war und kein Agent.

Die naheliegende Lösung wäre die Anmeldung im privaten Netz gewesen. Die taugt dafür nicht: Alle Rechner laufen unter demselben Konto, ein Agent auf einem meiner Macs sähe für den Server also genauso aus wie ich. Und ein Passwort oder Schlüssel, den die Seite kennt, kennen auch die Agenten auf demselben Rechner.

Deshalb verlangt jedes Ja und jedes Nein einen Passkey mit Touch ID (am iPhone Face ID). Einen Finger kann kein Agent geben. Jede Bestätigung gilt genau für einen Vorschlag und eine Antwort und lässt sich nur einmal verwenden. Ein weiteres Gerät kommt über einen Einmal-Link dazu, der zehn Minuten gilt. Der Leitstand listet alle Passkeys mit dem Zeitpunkt der letzten Nutzung. Ich gebe seitdem auf beiden MacBooks mit Touch ID frei, jedes mit einem eigenen Passkey.

Eine Grenze gehört ehrlich dazu: Solange ein solcher Einrichtungslink offen ist, könnte ein Agent mit einem ferngesteuerten Browser einen eigenen Passkey anlegen. Der Link entsteht aber nur, wenn ich ihn anfordere, und jeder Passkey steht sichtbar in der Liste.

Schritt 5: Rechner, die wissen, wofür sie da sind

Jeder Rechner hat eine Rolle, in einer kleinen Konfigurationsdatei beschrieben:

• wofür er da ist (der Büro-Mac entwickelt, der Server betreibt Produktiv-Apps),
• welche Aufräumarbeiten dort vorgeschlagen werden dürfen,
• was nie angefasst wird (auf dem Server zum Beispiel die Datenbanken der Produktiv-Apps),
• welche Dienste nach außen offen sein dürfen.

Alle 15 Minuten wird gemessen: Plattenplatz, Arbeitsspeicher, Auslagerung. Einmal täglich zusätzlich, wie viel Platz Caches, Simulatoren und Docker belegen, und die Sicherheit: Festplattenverschlüsselung, Firewall, ausstehende Updates und welche Dienste auf allen Netzwerken lauschen.

Aus den Messwerten und der Rolle entstehen Vorschläge. Der erste Lauf fand Dinge, die ich nicht auf dem Schirm hatte, unter anderem:

• Das Reise-MacBook, das 14-Zoll mit M5, war zu 99 % voll, 12 GB frei, davon über 100 GB in iOS-Simulatoren. Bemerkt hatte ich davon nichts. Diese Vorschläge gingen als eilig aufs Telefon.
• Auf dem Büro-Mac belegte ein Gradle-Cache fast 27 GB.
• Auf dem Linux-PC warteten 387 Updates, und die Firewall lief nicht.

Ich habe vier Vorschläge freigegeben. Beim nächsten Abgleich liefen sie, und zwar nur als feste Befehle aus einem Katalog, nie als frei formulierte Shell-Kommandos eines Agenten. Ergebnis: etwa 78 GB frei, das Reise-MacBook von 99 % auf 94 %.

Eine Sache hat mich dabei überrascht: Direkt nach dem Löschen der Simulatoren meldete das System nur 0,7 GB mehr freien Platz. macOS gibt solchen Platz verzögert frei, und die Größenmessung zählt Daten doppelt, die sich mehrere Simulatoren teilen. Ein paar Minuten später waren es etwa 35 GB.

Schritt 6: Was ein Leitstand sonst noch braucht

• Eine Sicherung. Im brain stecken jetzt Entscheidungen, Passkeys und Fakten. Einmal täglich wandern das brain und das Gedächtnis der Agenten verschlüsselt übertragen auf einen anderen Rechner, 14 Tage werden aufgehoben. Die erste Sicherung habe ich zurückgespielt und gezählt, ob alles da ist. Erst dann gilt sie für mich als Sicherung.
• Ein Verlauf. Ein Messpunkt pro Rechner und Tag. Daraus wird eine Prognose wie „voll in etwa 20 Tagen“, damit die Warnung kommt, bevor die Platte voll ist, nicht erst danach.
• Erwartete Ports. Jede Rolle listet, was nach außen offen sein darf. Gemeldet wird nur, was nicht auf der Liste steht. Beim ersten Lauf waren das vier Stellen auf sechs Rechnern, jede davon eine echte Frage.
• Eine Seite pro Rechner. Mit Verlauf, Platzverbrauch, Ports und einem Knopf „Jetzt aufräumen“ für alles, was die Rolle erlaubt. Auch der fragt Touch ID ab.

Was ich daraus mitnehme

1. Das eigentliche Problem war Rauschen, nicht fehlende Intelligenz. Sechs kluge Agenten ohne gemeinsamen Ort ergeben sechs Gespräche. Eine Regel wie „ein Eintrag pro Thema, ein Nein gilt 30 Tage“ hat mehr gebracht als jedes größere Modell.
2. Menschen entscheiden, Maschinen führen feste Befehle aus. Die Agenten dürfen alles vorschlagen. Ausgeführt wird nur, was in einem Katalog steht und was die Rolle des Rechners erlaubt, und erst nach meiner Freigabe.
3. Erst messen, dann Regeln schreiben. Die Schwellwerte und Rollen sind aus den echten Werten aller sechs Rechner entstanden, nicht aus Annahmen. Deshalb war der erste Lauf brauchbar statt laut.
4. Kleine lokale Modelle reichen für Hintergrundarbeit. Bedeutungssuche und das Herausziehen von Fakten laufen auf der CPU des Servers, ohne Cloud und ohne Kosten pro Aufruf. Langsam, aber nachts ist das egal.
5. Grenzen gehören in die Dokumentation. Wo der Passkey-Schutz endet, wo die Messung täuscht: Das steht dabei, nicht im Kleingedruckten.

Gebaut habe ich das zusammen mit Claude Code, in wenigen Sitzungen an fünf Tagen Ende Oktober. Die Agenten haben den Großteil des Codes geschrieben. Die Fragen, was gemessen wird, was ein Rechner darf und wo die Grenze zwischen Vorschlag und Ausführung liegt, haben sie mir nicht abgenommen. Und genau so soll es sein.

In Zahlen

Und bei dir?

Brauchst du so etwas für deine Firma? Oder bist du einfach neugierig, wie das im Detail läuft? Schreib mir.

→ Mail an [email protected], der Betreff ist schon ausgefüllt.

→ 30 Minuten Klönschnack buchen, wenn du lieber direkt sprechen willst.