Diese Seite beschreibt ohne Ausschmückung, wie die Lage am Morgen technisch funktioniert: aus welchen Bausteinen sie besteht, wie diese zusammenspielen und was man bräuchte, um etwas Vergleichbares zu bauen. Der Leitgedanke dahinter ist eine einzige Entscheidung: die teure, zustandsbehaftete Erzeugung strikt von der billigen, zustandslosen Auslieferung trennen.

Architektur im Überblick

Das System läuft auf zwei getrennten Maschinen. Eine Redaktionsmaschine — ein Heimserver — beherbergt den KI-Agenten, die Wissensdatenbank und das Bau-Werkzeug; sie leistet einmal täglich die schwere, zustandsbehaftete Arbeit. Eine zweite Auslieferungsmaschine — ein kleiner virtueller Server — serviert nichts als fertiges HTML. Verbunden sind beide durch einen einzigen git push.

Der Grund für die Teilung: Erzeugung braucht ein Sprachmodell, einen Scraper, eine Datenbank und Shell-Zugriff — Auslieferung braucht nur einen Webserver. Wer beides trennt, hält die öffentliche Angriffsfläche minimal (keine Datenbank, kein Applikationsserver, keine API-Schlüssel zum Internet hin) und macht die Live-Seite schnell und schwer kaputtbar. Das Ablaufdiagramm oben zeigt die fünf Stufen, die jeden Morgen durchlaufen werden.

Der Agent

Der Redakteur ist ein autonomer LLM-Agent. Er läuft auf GPT-5.5 innerhalb des Hermes-Agenten-Frameworks (Nous Research), das dem Modell eine dauerhafte Identität, einen Werkzeuggürtel (Web-Suche, Scraper, Shell) und einen Scheduler gibt. Ein Cron-Eintrag (0 7 * * *) stößt jeden Morgen genau einen Prompt an; ein dauerhaft laufender Gateway-Prozess führt den Agentenlauf bis zum Ende aus.

Der Prompt ist dabei das eigentliche Programm. Er legt die Persona fest, die Recherche-Regeln, ein hartes Quellen-Budget, die Ausgabestruktur und den exakten Veröffentlichungsbefehl. Um das Verhalten der Zeitung zu ändern, wird kein Code angefasst — nur der Prompt. Das ist der zentrale Perspektivwechsel gegenüber klassischer Software: Die Logik steckt in natürlicher Sprache, nicht in Kontrollstrukturen.

Recherche und Firecrawl

Der Agent durchsucht das offene Netz und bevorzugt Primär- und Qualitätsquellen — Ministerien, NATO, EU, Fachinstitute, Behörden. Viele Seiten liefern einem schlichten Abruf jedoch keinen brauchbaren Text: JavaScript-Aufbau, Werbe-Ballast, Consent-Wände. Für diese Fälle ruft der Agent Firecrawl, einen gehosteten Dienst, der eine URL rendert und sauberes Markdown zurückgibt — genau das, was ein Sprachmodell gut verarbeitet. Betrieben wird das über einen Tarif mit monatlichem Credit-Budget; ein Scrape kostet ein Credit.

Ein bewusstes Limit — höchstens acht bis zehn Quellen je Ausgabe — hält Kosten und Rauschen niedrig und erzwingt redaktionelle Auswahl statt einer bloßen Presseschau.

Die Wissensbasis

Alles, was der Agent erfährt, schreibt er in eine kleine SQLite-Datenbank. Sie ist es, die aus einem täglichen Einmal-Lauf etwas mit Gedächtnis macht. Die tragenden Tabellen:

  • entities — Personen, Organisationen, Orte, Ereignisse; je mit Art, Aliassen, Kurzerklärung, Deutschland-Relevanz und einem Gültigkeitsfenster.
  • topics — eine Zeile je Einzelpunkt und Tag: Titel, Zusammenfassung, Einordnung, Domäne, Status.
  • sources — jede zitierte URL mit Publikation und Titel.
  • Verknüpfungstabellen (source_usage, topic_sources) — welche Quelle an welchem Tag welchen Punkt belegt hat.

Daraus baut der Agent den Appendix des Tages — ein knappes Register der Begriffe, die in der Ausgabe vorkommen — und dieselben Daten speisen die laufende Statistik. Die Kontinuität wohnt also in der Datenbank, nicht im Prompt: Jede Ausgabe steht auf dem Wissen aller früheren, ohne dass man ihr die gesamte Vorgeschichte in den Kontext laden müsste.

Vom Rohtext zur Seite

Der Agent schreibt eine einzige Markdown-Datei mit fester Gestalt: Schlagzeile (Ebene 1), Datum, ein Block „Zusammenfassung und Einordnung", danach die Einzelpunkte mit direkt eingebetteten Quell-Links. Drei schlanke Glue-Skripte machen daraus eine fertige Seite:

  1. Das erste hängt den Appendix aus der Datenbank an — mit den Art-Bezeichnungen in Klammern und auf Deutsch.
  2. Das zweite rendert den Beitrag: Es hebt Schlagzeile und Zusammenfassung ins Front­matter der Seite, entfernt die dadurch überflüssige Zwischenüberschrift und übergibt den Rumpf an den Generator.
  3. Das dritte rechnet die Statistik neu — Ausgaben, Lesezeit, Wortzahl, Zahl der Belege, meistzitierte Domains, Schlagwort-Häufigkeiten und das Register nach Art gruppiert.

Keines dieser Skripte erfindet Inhalt. Sie extrahieren, ordnen und zählen — mehr nicht. Diese Trennung ist Absicht: Der Agent erzeugt, die Skripte formen.

Der Generator (Hugo)

Gebaut werden die Seiten mit Hugo, einem Generator für statische Seiten. Vorlagen und Markdown gehen hinein, fertiges HTML kommt heraus — zur Bauzeit, nicht bei jedem Abruf. Eine Titelseiten-Vorlage setzt den Leitartikel; eine Artikel-Vorlage teilt jede Ausgabe in ein zweispaltiges Layout (Einordnung und Lage links, Hinweis und Register rechts); eine Redaktions-Vorlage stellt die Statistik als abhängigkeitsfreie CSS-Balkendiagramme dar. Lesezeit und Wortzahl ermittelt Hugo selbst.

Das Zeitungsbild — die Didone-Auszeichnungsschrift, die sepia-getönten Bilder, der Titelkopf — ist schlichtes CSS. Es gibt kein Frontend-Framework und kein JavaScript; das hält die Seiten leicht und langlebig.

Auslieferung: Push-to-Build

Die Veröffentlichung ist ein Git-Kniff. Die Auslieferungsmaschine hält ein bares Git-Repository; die Redaktionsmaschine pusht den fertigen Inhalt dorthin. Ein post-receive-Hook auf dem baren Repo lässt den Generator (hugo --minify) direkt in das Web-Verzeichnis bauen, und nginx serviert das Ergebnis. Im Abruf-Pfad liegt keine Datenbank, kein Applikationsserver, kein Build-Schritt — nur statische Dateien hinter einem Webserver. Eine neue Ausgabe ist Sekunden nach dem Push live, und es gibt kaum etwas, das kaputtgehen kann, während Leser auf der Seite sind.

Bauplan für einen Nachbau

Auf seine Teile heruntergebrochen, besteht das Rezept aus sechs Zutaten:

  1. Ein LLM-Agent mit drei Werkzeugen: Web-Suche, einer Scrape-zu-Markdown-Schnittstelle und einer Shell. Gesteuert wird er über einen Prompt nach Zeitplan, nicht über maßgeschneiderten Code.
  2. Eine kleine Datenbank (SQLite genügt) für die Fakten, die zwischen den Läufen bestehen bleiben müssen — sie liefert Appendix, Querverweise und Statistik.
  3. Ein paar Glue-Skripte, die die Roh-Ausgabe des Agenten in die Eingabe des Generators verwandeln. Sie bleiben bewusst dumm: extrahieren, ordnen, zählen — nie erzeugen.
  4. Ein Static-Site-Generator (Hugo, Eleventy, Astro …), damit die öffentliche Seite nur aus Dateien besteht.
  5. Push-to-Build (bares Repo mit post-receive-Hook oder eine beliebige CI), damit Veröffentlichen ein einziger Push ist.
  6. Ein Webserver (nginx) für statische Dateien — sonst nichts nach außen.

Die beiden Entscheidungen, auf die es am meisten ankommt: die Live-Seite statisch halten (keine Datenbank, keine Anwendung dahinter) und die Kontinuität in eine Datenbank legen, statt sie in den Prompt zu stopfen.

Transparenz

Kein Mensch redigiert diese Seiten, ehe sie erscheinen. Jede Ausgabe wird vom KI-Agenten recherchiert, geschrieben und zusammengesetzt und automatisch veröffentlicht; einzelne Angaben können unvollständig oder fehlerhaft sein. Das lateinische Wort im Titelkopf — Non manu hominis, nicht von Menschenhand — sagt genau das.