Was Hermes jeden Morgen erledigt

Ein KI-Agent ist ein Programm, das selbständig Arbeitsschritte ausführt. Mein eigener Agent heisst Hermes und läuft rund um die Uhr auf einem Linux-Server (Ubuntu) bei Contabo, einem Hosting-Anbieter. Ich steuere ihn per WhatsApp. Ich schreibe ihm eine Nachricht, er führt den Auftrag aus und meldet das Ergebnis zurück. Für das Schreiben und Auswerten nutzt er Sprachmodelle über OpenRouter, einen Dienst, der viele Modelle über eine Schnittstelle anbietet. Jeden Morgen erledigt Hermes drei Aufgaben ohne mein Zutun: Um 06:30 postet er einen Bibelleseplan in einen WhatsApp-Kanal, um 06:40 publiziert er einen Blogeintrag im Logbuch auf medienautomatisierung.com, und um 06:50 verschickt er einen Nutzungsbericht per Mail. Die Protokolle dieser Läufe existieren. Zwei Ausschnitte davon zeige ich in diesem Beitrag im Original, einen gelungenen Lauf und einen Abbruch.

Die drei Morgenjobs

Den Anfang macht um 06:30 der Bibelleseplan. Eine Website, die ich für eine Berner Organisation betreue, berechnet aus dem Datum, welcher Leseabschnitt an diesem Tag dran ist. Hermes holt den Tageslink und postet ihn in einen WhatsApp-Kanal. Angestossen wird der Lauf von einem Cronjob; das ist ein zeitgesteuerter Auftrag, den der Server selber startet, ganz ohne Zuruf von aussen.

Um 06:40 folgt der Blogeintrag. Hermes lädt die Schlagzeilen aus acht Nachrichtenquellen, filtert die Meldungen zu KI und Automatisierung heraus und schreibt daraus das werktägliche Briefing für das Logbuch auf medienautomatisierung.com. Danach baut ein Skript die Blogseiten neu und lädt die geänderten Dateien zu Cloudflare hoch, dem Dienst, auf dem meine Websites laufen.

Um 06:50 verschickt Hermes den Nutzungsbericht. Meine Websites zählen Zugriffe anonym und ohne Cookies; ein Skript fasst diese Zahlen zusammen und schickt mir die Übersicht per Mail. Beim Frühstück weiss ich damit, welche Seiten am Vortag gelesen wurden.

Ein gelungener Lauf im Protokoll

So sieht der Blogeintrag-Lauf vom 22. Juli 2026 im Protokoll aus, gekürzt um die Upload-Zeilen:

== 2026-07-22 06:40:01 LOGBUCH-Lauf [briefing] ==
Gefunden: 18 KI-Meldungen aus 8 Quellen.
Modell: openai/gpt-5.5
✓ Beitrag geschrieben: /root/medienauto/site/blog/posts/2026-07-22-briefing.md (6 Meldungen)
✓ LOGBUCH gebaut: 7 Beiträge (davon 2 erklärt), Index, Register, Feed, Sitemap, Homepage-Teaser.
== 2026-07-22 06:40:48 fertig [briefing] ==

Die Zeilen sagen Folgendes. Der Lauf fand 18 KI-Meldungen aus 8 Quellen und wählte 6 davon für den Beitrag aus. Geschrieben hat ihn das Sprachmodell openai/gpt-5.5. Vom Start um 06:40:01 bis zur Schlussmeldung um 06:40:48 vergingen 47 Sekunden. Danach lud das Deploy-Werkzeug 8 geänderte Dateien zu Cloudflare hoch; 41 weitere Dateien waren unverändert und blieben, wo sie waren. Der Beitrag aus diesem Lauf steht seither im Logbuch auf medienautomatisierung.com, und jede der sechs Meldungen trägt dort den Link auf ihre Quelle.

Ein Abbruch im selben Protokoll

Wenige Zeilen über dem gelungenen Lauf steht im selben Logfile ein Fehlschlag. Ein zweiter Lauf schreibt Erklärstücke zu KI-Begriffen und verlangt dafür vom Sprachmodell unter anderem ein gefülltes Feld namens «begriff». Die Antwort des Modells liess dieses Feld leer oder zu dünn, und die Prüfung im Code brach den Lauf ab:

Error: Feld "begriff" fehlt oder ist zu dünn — Abbruch.
    at baue (file:///root/medienauto/ops/hermes-erklaerer.mjs:134:80)

An diesem Punkt passierte genau das, was passieren soll. Vor jeder Publikation prüft der Code, ob die Pflichtfelder gefüllt und die Texte brauchbar sind. Fällt die Prüfung durch, erscheint kein Beitrag, und der Fehler steht im Protokoll. Ein dünnes Erklärstück im Netz wäre schlimmer als ein fehlendes. Ich lasse den Abbruch hier bewusst stehen, weil er belegt, dass die Prüfungen greifen.

Aufbau und Härtung

Der Server ist gehärtet. Gehärtet heisst hier, dass nur mein SSH-Schlüssel Zugang hat und eine Firewall alle übrigen Verbindungen blockt. Ein SSH-Schlüssel ist eine Schlüsseldatei auf meinem Rechner; ein Login mit Passwort ist auf dem Server abgeschaltet. Die Systemanzeige meldete am 22. Juli 2026 eine Laufzeit von einer Woche und sechs Tagen seit dem letzten Neustart.

Für die Steuerung zwischendurch reicht das Handy. Ich schreibe Hermes eine WhatsApp-Nachricht, er erledigt die Aufgabe und meldet sich zurück. Die Morgenjobs brauchen diese Nachrichten gar nie; sie laufen über die Cronjobs von selbst an.

Neben den drei Morgenjobs läuft ein viertes System durch den ganzen Tag. Eine Netzwerk-Überwachung prüft alle 30 Minuten die Geräte und Verbindungen an einem Standort, den ich betreue, und schickt bei einer Auffälligkeit eine Mail. Zusammen sind das vier Systeme, die täglich laufen: Leseplan-Versand, Blogeintrag, Nutzungsbericht und Netzwerk-Überwachung.

Was davon übertragbar ist

Der Bibelleseplan ist mein Anwendungsfall. Der Mechanismus dahinter passt auf viele kleine Betriebe, weil er aus drei einfachen Teilen besteht: einem festen Zeitpunkt, einem Skript mit eingebauten Prüfungen und einem Protokoll, das jeden Lauf festhält. Eine Treuhand-Kanzlei kann sich jeden Morgen die offenen Posten aus der Buchhaltung zusammenfassen und zustellen lassen. Ein Handwerksbetrieb kann Anfragen aus dem Kontaktformular vorsortieren und mit einem Terminvorschlag versehen lassen. Eine Eventlocation kann die Belegung der kommenden Woche jeden Freitag als Übersicht ins Team schicken lassen.

Drei Regeln nehme ich aus dem eigenen Betrieb mit. Erstens schreibt jeder Lauf ein Protokoll; ohne Protokoll gibt es im Fehlerfall nichts zu lesen. Zweitens prüft der Code das Ergebnis vor der Publikation und bricht im Zweifel ab; der Erklärer-Abbruch oben zeigt, wie das aussieht. Drittens bleibt der Mensch dort in der Schleife, wo Geld oder Aussenwirkung dranhängen; bei mir gibt es vor jedem Videoschnitt und vor jeder teuren Generierung eine Freigabe.

Wenn Sie wissen wollen, welcher Ablauf in Ihrem Betrieb für einen solchen Morgenjob taugt, schreiben Sie mir. Ich schaue zuerst an, was sich bei Ihnen täglich wiederholt, und schlage danach den kleinsten sinnvollen Umfang vor.