Episoden / episode 07 / 45:02

Hermes Agents, Deep Modules, SEO-Page-Intents, AI Dictionary

Vier Themen im Wechsel: Christoph setzt mit dem Hermes Agent einen SEO-Monitor für eine Website auf, der lokal im Docker läuft und unter 10 Euro im Monat kostet, Jens erklärt Deep Modules als Weg zu einer agent-tauglichen Codebase, Christoph zeigt, warum erst eine eigene Commercial Landing Page die Money-Keywords holt, und Jens stellt ein AI Coding Dictionary vor.

Begrüßung

Zum ersten Mal keine Mittwochs-Aufnahme: Christoph kam etwas dazwischen, also wurde es der Montag — Aufnahme und Veröffentlichung liegen diesmal ungewöhnlich nah beieinander. Dank an Peter, der Intro und Audio für uns in Form bringt.

Ein Hermes-Agent, der eine Website überwacht

Nachdem Jens in den letzten Folgen über OpenClaw gesprochen und dabei immer wieder auf die Alternative Hermes verwiesen hatte, hat Christoph sich Hermes Agent von Nous Research geschnappt und damit einen Agent für eine Website aufgesetzt. Die Website zum Projekt ist schon für sich sehenswert — ungewöhnlich und mutig für ein Thema wie dieses.

Webseite mit tiefblauem Hintergrund, die Hermes Agent bewirbt, mit Titel 'The agent that grows with you' und mehreren Installationsoptionen für Mac OS, Linux und Windows. Rechts ist eine künstlerische mehrarmige Figur mit Strahlen im Hintergrund zu sehen.

Angebunden ist der Agent an Telegram. Kein großer Telegram-Fan, aber das Setup ist schlicht zu einfach, um es nicht zu nehmen — Slack wäre der nächste Kandidat. Was dabei herauskommt, ist ein Wochenbericht auf Basis der Google-Search-Console-Daten: wie die Seite gerade performt, welche Seiten die Outperformer sind, wo die größten Hebel liegen. Am Ende jedes Laufs stehen konkrete Findings.

Telegram-Nachricht im Chat "RWH Daily" mit Cronjob-Antwort zum Wochen-Backlog KW30, die Statusupdates zu Klicks, Positionen und Backlog-Tasks enthält.

Das Setup dahinter ist bewusst unspektakulär. Auf der Maschine läuft ein Python-Skript, das die Daten aus der Search Console zieht, aufbereitet und in den Prompt packt. Claude wertet aus, die Findings landen in einer Postgres-Datenbank und werden bei jedem Durchlauf gegen den Bestand geprüft — so bleiben nur neue Findings übrig. Das Ergebnis geht nach Telegram. Als Testobjekt dient regenwasser-haushalt.de, eine von Christophs Experimentier-Websites.

Diagramm einer Setup-Konfiguration für einen Hermes Agent, der SEO-Monitoring-Daten von Google Search Console über Python-Skripte verarbeitet, Ergebnisse in einer PostgreSQL-Datenbank dedupliziert und Berichte per Telegram versendet.

Zwei Routinen laufen: täglich der 7-Tage-Trend mit Sonnet 5, wöchentlich das 30-Tage-Review mit Fable 5. Für den tieferen Blick mit mehr Daten darf es das teurere Modell sein, für die Tagesroutine reicht das kleinere.

Dark mode Interface mit zwei nebeneinander stehenden Boxen, die tägliche 7-Tage-Trend-Analyse und wöchentliche 30-Tage-Review zeigen, inklusive kosten- und modelldetails.

Die Kosten: 10 bis 14 Cent pro Tagesnachricht, insgesamt 8 bis 9 Euro im Monat. Das erste Learning ist genau das — das richtige Modell für die richtige Aufgabe, mit Sonnet 5 als Default. Das zweite: nicht alles muss durch den Agent. Ein Google-Search-Console-MCP mit „hol dir mal die letzten Daten" verbrennt massiv Tokens; ein Python-Skript, das jeden Tag ohnehin dasselbe tut, liefert genau die Daten in den Prompt, die gebraucht werden. Kleiner Hinweis am Rande: Sonnet 5 läuft noch im Intro-Pricing mit 2 $ pro Million Input- und 10 $ pro Million Output-Tokens, bis Ende August — danach 3 $ und 15 $.

Übersicht der Kosten für Hermes Agent mit weniger als 10 Euro pro Monat, Erläuterungen zu Modellen pro Aufgabe und Nutzung von Python zur Automatisierung repetitive Tasks, auf schwarzem Hintergrund mit grünem und weißem Text.

Der eigentlich interessante Punkt daran: Wer über die API zahlt, kommt aus dem „ist ja durchs Abo abgedeckt"-Denken heraus und überlegt wieder, was ihm eine Aufgabe wert ist. Das fühlt sich deutlich besser an — und nebenbei ist Sonnet in solchen Tasks auch schlicht schneller als Opus.

Gehostet wird nicht in der Cloud. Zuerst lief der Agent auf einem Hetzner-Server (dort sind die Kapazitäten inzwischen zeitweise ausgebucht und die Preise deutlich gestiegen), jetzt steht ein Lenovo M75q Mini-PC mit 32 GB RAM auf dem Schreibtisch, Ubuntu Server, Docker. Jede Hermes-Instanz bekommt ihren eigenen Container mit eigener Datenbank.

Textfolie zeigt ein lokales Setup für den Hermes Agent mit Lenovo M75q Gen 5 Mini-PC und 32 GB RAM, Docker-Container "hermes – regenwasser-haushalt.de" läuft, zwei weitere Instanzen sind frei. Erläuterung zum Overkill eines SEO-Monitors und Docker-Setup mit mehreren isolierten Hermes-Containern.

Jens' Einwand dazu: Hermes kann auch mehrere Agents innerhalb einer Instanz definieren — für manche Use Cases ist die harte Trennung sinnvoll, für andere unnötig. Als Nächstes soll aus dem 30-Tage-Review ein Backlog entstehen, den der Agent abarbeitet und Christoph reviewt. Ein lokales Modell scheitert vorerst an den 32 GB; ein Framework Desktop mit genug Speicher liegt bei rund 4.000 Euro — dafür ist dieser Podcast noch zu klein.

Agent-Ready Codebase: Deep Modules

Jedes Mal, wenn wir einen Agent spawnen, haben wir im Grunde einen Neuling vor uns, der sich erst mit der Codebase vertraut machen muss. Ein bisschen Orientierung kommt über den System-Prompt und über agents.md, claude.md und Konsorten — aber der Agent startet ohne Vorwissen. Der praktische Schluss daraus: Wer seine Codebase für Codebase-Neulinge optimiert, egal ob Mensch oder Agent, optimiert sie in den meisten Fällen automatisch auch für Agents.

Ein grafisches Layout mit dem Text "jeder Agent ist ein codebase-neuling" und den hervorgehobenen Begriffen "zzs", "codebase-neuling" und "nur das Kontextfenster". Es beschreibt die Optimierung einer Codebasis für Codebase-Neulinge mit drei Punkten: Software-Qualität, Tests und Änderbarkeit.

Ein Konzept, das dabei besonders trägt, sind Deep Modules aus John Ousterhouts „A Philosophy of Software Design". Ein Modul ist Interface plus Implementierung. Im Idealfall ist das Interface schmal — wenige, generische Methoden und Konfigurationsmöglichkeiten — und verbirgt darunter eine große, komplexe Implementierung. Die Falle ist der umgekehrte Fall: ein sehr breites Interface mit vielen Methoden und Optionen, hinter dem im Kern wenig steckt. Für Agents ist das teuer, weil sie sich durch die gesamte Oberfläche lesen müssen, bevor sie etwas tun können.

Eine Tabelle, die zwei Typen von Modulen in der Softwareentwicklung vergleicht: "tief – so soll es sein" mit einem schmalen Interface und Implementation, und "flach – die Falle" mit einem breiteren Interface und Implementation, ergänzt durch erklärenden Text und einem Zitat von ousterhout.

Damit landet man wieder bei Progressive Disclosure aus Folge 4: Informationen schrittweise offenlegen und dem Agent die Chance geben, sich schnell einen ersten Überblick zu verschaffen. Deep Modules leisten genau das. Christophs Frage, ob sich das auch auf API-Endpoints übertragen lässt, geht in dieselbe Richtung — statt fünf spezialisierter Endpoints lieber einer, der generisch ist, wenige Parameter hat und dafür viel kann.

Aus der Praxis: In manchen Payload-Projekten braucht Jens Audit-Fields, also pro Entity die Information, wer sie erstellt und wer sie zuletzt bearbeitet hat. Statt Felder, Hooks und Admin-Komponenten über den App-Code zu verteilen, steckt das Ganze als lokales Plugin in einem Modul — veröffentlicht werden muss es dafür nicht. Das Interface besteht aus zwei Angaben: für welche Collections und für welche Globals das Plugin gelten soll. Dahinter liegen 15 Dateien und rund 1.300 Zeilen TypeScript. Für einen Agent heißt das: Um es für eine neue Collection einzurichten oder zu sehen, welche Collection welche Funktionen hat, muss er nur den Aufruf verstehen.

Screenshot einer Präsentationsfolie über ein Interface mit 15 Dateien, das ein Audit-Fields-Plugin enthält, inklusive Details zu Dateien, Zeilen TypeScript-Code und Pflicht-Optionen, sowie einer Anleitung zum Verstehen des Aufrufs.

Ein Nebeneffekt, der oft untergeht: Was sauber gekapselt ist, lässt sich auch gut testen — und Tests zu schreiben ist mit den heutigen Sprachmodellen deutlich billiger geworden. Christophs Bild dazu passt gut: Man sieht nur die Spitze des Eisbergs, und das reicht. Wie tief es darunter geht, muss man nicht wissen.

Ressourcen:

Money-Keywords brauchen Commercial Intent

Ausnahmsweise ein Non-AI-Thema: klassisches SEO, aus einem Projekt, in dem Jens die technische und Christoph die konzeptionelle Seite übernimmt. Die Idee dahinter ist die übliche — Besucher organisch schon außerhalb des Conversion-Kreises abholen. Wer noch nicht „ich möchte das kaufen" sucht, sondern „worauf muss man achten, wenn man das kaufen möchte", landet auf einer Ratgeberseite und wird von dort weitergeführt.

Ratgeberseiten, Themenseiten und Blogartikel gibt es reichlich, und für sich funktionieren sie gut. Bei den schwierigen Keywords — den Money-Keywords — war die Seite trotzdem nicht sichtbar. Nicht wenig sichtbar, sondern null.

Der Grund lag im Content Hub, also der übergeordneten Seite über Ratgebern und Themenseiten. Der war zwar auf die Conversion ausgerichtet und zeigte das Angebot, aber Google hat ihn ausschließlich als Informations-Hub eingeordnet. Es fehlte schlicht eine Seite mit echtem Commercial Intent — eine, bei der klar ist: Hier kann ich etwas kaufen, buchen, anfragen.

Diagramm zeigt die Struktur und Verbindung zwischen Content Hub, Ratgeber, Themenseiten, Blogartikeln und einer Commercial Landing Page mit klarem kommerziellen Intent für Money-Keywords in einem SEO Kundenprojekt.

Die Lösung war eine neue Landing Page als Commercial Hub. Alle Unterseiten — Content Hub, Ratgeber, Themenseiten, Blogartikel — verlinken intern dorthin und machen sie damit auch strukturell zum Knotenpunkt. Zwei, drei Tage nach der Indexierung kamen die Impressionen und die Sichtbarkeit für genau die Keywords, die vorher gefehlt hatten.

Das Learning: Den Search Intent muss man klar bedienen und sich mit seinem Angebot nicht verstecken. Nur Info-Besucher auf die Seite zu holen, bringt am Ende wenig. Dazu passt ein Sneak Peek für die nächste Folge: Bei einem Test war eine Marke für die KI plötzlich kein wichtiger Anbieter im deutschen Markt mehr — weil eine der Hauptquellen ein Listicle eines Mitbewerbers war, das den Anbieter in den Jahren davor gelistet und 2026 einfach herausgenommen hatte. Nicht erwähnt zu werden ist also selbst eine Information, aus der sich die KI ein Bild macht.

Und noch ein Punkt, der dazugehört: Es ist die Zeit des Ausdünnens. Der Google-Index ist überflutet, es wurde nie so viel neu publiziert wie jetzt. Lieber zehn richtig gute Artikel als 120, die sich von nichts abheben — Qualität vor Quantität war schon vorher richtig und ist es jetzt umso mehr.

Vokabular für die Agent-Arbeit: das AI Coding Dictionary

Einstieg über eine Frage an Christoph: Wie sehr achtest du eigentlich auf die verbrauchten Tokens innerhalb einer Session? In Claude Code sehr — nach jedem Mini-Milestone einmal /context, um zu sehen, was verbraucht ist und was noch da ist. In der Chat-UI dagegen so gut wie gar nicht, und zwar auch deshalb, weil es dort schlicht keine Anzeige gibt.

Das stimmt: Weder ChatGPT noch claude.ai zeigen den Verbrauch innerhalb eines Chats an. Claude Code im Web hat unten einen kleinen Indikator. Dass es für weniger technische Nutzung wenig Wert liefert, ist nachvollziehbar — schade ist trotzdem, dass man es nicht wenigstens ein- und ausschalten kann.

Damit zum eigentlichen Thema: eine Website, die die vielen neuen Begriffe rund um AI, LLMs und Agents sauber definiert. Einer davon ist die Smart Zone. Sie beschreibt, dass ein Agent am Anfang einer Session sehr fokussiert ist und mit wachsender Session — mehr Instruktionen, mehr Tokens pro Turn — zunehmend unkonzentrierter wird. Beide arbeiten entsprechend: Jens hat sich im Terminal die Status Line eingebaut und zieht bei rund 150.000 Tokens den Schnitt, Christoph liegt bei 100.000 bis 150.000. Das Compact-Feature nutzt keiner von beiden, weil man nicht kontrollieren kann, an welcher Stelle komprimiert wird und dabei Wichtiges verloren geht. Stattdessen: Milestones von vornherein so klein schneiden, dass sie in eine Session passen, am Ende Commit und Pull Request, einen Kick-off-Prompt für die nächste Session erzeugen lassen, /clear, weiter. Bei Jens heißt dasselbe Handoff — funktioniert seit Monaten zuverlässig.

Im Dictionary stehen auch Context Clearing und das Handoff-Artefakt, und zwar mit einer Visualisierung, wie die Begriffe zusammenhängen: Das Handoff-Artefakt hängt an Session, Agent, Clearing und Compaction. Es lohnt sich, da einmal durchzuscrollen und den Dingen, die man täglich ohnehin tut, einen Namen zu geben. Nebenbei spart das sogar Tokens — die Modelle kennen diese Begriffe, und wer präzise formuliert, muss weniger erklären.

Zum Schluss die offene Frage, wie lange die großen Modelle noch so großzügig im Abo bleiben. Die Vermutung beider: Das fädelt sich langsam aus, und die Provider schieben uns für die besten Modelle Richtung Usage-based Pricing. Ein guter Umgang mit Tokens wird jetzt zu einem Vorteil, der sich später auszahlt.

Ressourcen: