Von starren Pipelines zu agentischen Bots: warum ich n8n durch Hermes ersetzt habe
Jahrelang lief meine Automatisierung auf n8n: deterministische Workflows, auf Skalierung ausgelegt. Jede Weiterentwicklung verlangte trotzdem einen Umbau der Architektur. Als die Token-Kosten fielen, wurden Agents zum besseren Kompromiss. Hier ist, warum ich gewechselt habe und wie der Hybrid läuft.
Das Problem
Jahrelang lief meine persönliche Automatisierung auf n8n. Deterministische Workflows: Monitoring, Akquise, E-Mails, Publikation. Saubere Nodes, Templates, eine auf Skalierung ausgelegte Architektur.
Das Design war richtig. Das Problem war nie die Skalierung. Es war die Flexibilität.
Die Wand: Umbau bei jeder Weiterentwicklung
Jede Änderung, eine neue Quelle, ein neues Format, eine neue Regel, verlangte einen Umbau der Architektur. Mal klein, mal groß. Selbst wenn die Struktur auf Skalierung ausgelegt war: an dem Tag, an dem sich die Schleife änderte, habe ich die Teile von Hand neu verkabelt.
Beispiel Monitoring. Eine Quelle hinzufügen: Node neu verkabeln. Das Ausgabeformat ändern: Node neu verkabeln. Die Datenflüsse stimmten, aber jede Weiterentwicklung kostete Architektur, nicht Logik. Der Workflow tat exakt das, was ich ihm gesagt hatte. Das Sagen selbst skalierte nicht.
Ein Workflow ist eine Leiterplatte: zuverlässig und starr. Der Pfad wird einmal gezeichnet, für immer. Ein Agent ist anders: er trägt Kontext, er passt sich an, er entscheidet innerhalb des Rahmens, den man ihm gibt. Die Schleife kann sich biegen, ohne neu gezeichnet zu werden.
Die Ökonomie hat sich verändert
Der zweite Faktor war wirtschaftlich. Lange waren autonome Agents ein Luxus: teure Tokens, unvorhersehbare Kosten. Die Gleichung änderte sich, als die Token-Kosten so weit fielen, dass die Frage nicht mehr lautete „kann ich mir einen Agent leisten?", sondern „wo soll die Intelligenz leben, lokal oder in der Cloud?"
Genau diese Frage beantwortet dieser Artikel.
Der Ersatz: ein Hybrid, keine Migration
Ich habe einen Teil meiner n8n-Schleifen durch Hermes ersetzt. Keine Migration von einem Tool zum anderen: eine zweistufige Architektur.
Die Regel in einem Satz: lokal für die schwere Last, Cloud für die Agent-Intelligenz, menschliche Validierung an der Grenze.
Lokale Stufe · Linux + Ollama (Qwen)
Schwere Last: Monitoring, Crawling, Dev-Aufgaben. Grenzkosten = Strom.
Cloud-Stufe · VPS + DeepSeek
Agent-Ebene: verstehen, entscheiden, Schritte verketten, Kontext halten.
Menschliche Validierung an der Grenze
Entwürfe, Akquise-Kandidaten und Monitoring-Digests werden vor dem Versand geprüft.
Ausgabe · E-Mail versendet, Kontakt hergestellt, Artikel veröffentlicht
Lokal · Ollama + Qwen
Die lokale Stufe läuft auf meinen eigenen Maschinen (Linux). Ollama mit Qwen-Modellen übernimmt Monitoring und Entwicklung. Dorthin gehen die intensiven, schweren Aufgaben, die in der Cloud sinnlos Tokens verbrennen würden.
Ich habe die Hardware. Die Grenzkosten eines schweren lokalen Laufs sind Strom, keine Tokens.
Cloud · DeepSeek für die Agents
Die Agents laufen auf einem VPS, betrieben mit DeepSeek. Nicht für die schweren Aufgaben, sondern für die Agent-Ebene: verstehen, entscheiden, Schritte verketten. Die Cloud dort, wo der Agent Reaktivität und Kapazität braucht; das Lokale dort, wo die Last konstant und intensiv ist.
Die Aufteilung ist keine Performance-Frage. Es geht um Kostenkontrolle. DeepSeek gibt mir Agent-taugliche Intelligenz zu einem Preis, der die Architektur tragfähig macht, und die lokale Stufe hält die token-hungrige Arbeit vom Zähler fern.
Die Regel, die alles trägt: Autonomie mit menschlicher Validierung
Die Agents sind autonom. Sie sind nicht unbeaufsichtigt.
- E-Mails entstehen als Entwurf und werden vor dem Versand geprüft.
- Akquise-Kandidaten werden gesammelt und vor jedem Kontakt validiert.
- Monitoring-Ergebnisse landen in einem Chat, sie werden nicht automatisch veröffentlicht.
Der Agent schlägt vor. Ich entscheide. Autonomie im Rahmen, Mensch an der Grenze. Diese Linie macht das System vertrauenswürdig genug, um unbeaufsichtigt zu laufen: der Agent macht die Arbeit, die Entscheidung gehört mir.
Was sich in der Praxis geändert hat
Eine Änderung ist jetzt eine Anweisung, kein Refactor. Wenn eine Schleife sich entwickeln muss, sage ich es dem Agent. Die Architektur bleibt.
Kontext überlebt. Der Agent weiß, was er gestern getan hat. Die Schleife startet nicht mehr bei jedem Lauf bei null.
Fehler sind besprechbar. Wenn eine Ausgabe falsch ist, reden wir darüber, sie wird korrigiert, die Schleife läuft weiter. Kein stiller Fehler mehr, vergraben in einem Node.
Das System wurde zum Produkt. Das ist die Design-Ops-Lektion: ein System, das man weiterentwickelt, ist ein Produkt. Ein System, das man neu verkabelt, ist eine Last. Dieselbe Logik gilt für Design Systems, für Automatisierung, für alles, was seine erste Version überleben soll. Die Architektur ist absichtlich langweilig. Sie muss nicht elegant sein. Sie muss sich biegen können.
Das Pipeline hinter diesem Blog: vom Monitoring zum veröffentlichten Post
Dieser Blog entsteht nicht im Vakuum. Er ist das Ergebnis einer Pipeline, derselben Art von System, die ich für Kunden entwerfe, angewandt auf meine eigenen Inhalte. So reist eine Idee vom Monitoring zum veröffentlichten Post.
Monitoring
Ich sammle Signale aus Quellen, denen ich vertraue: Design-Newsletter, Produkt-Launches, Forschungspapiere, Branchenberichte, Gespräche. Der Agent liest nicht alles. Er scannt, filtert und markiert, was zu meinen aktuellen Interessen passt.
Vault
Markierte Einträge landen in einem Vault: einem strukturierten Repository aus Rohsignalen mit Tags, Quellen und einem Confidence-Score. Nicht alles ist gut. Nicht alles ist nützlich. Der Vault erlaubt mir, durchzusehen, bevor ich mich festlege.
Ideen
Ich überprüfe den Vault regelmäßig und wandle Signale in Ideen um. Manche werden zu Artikeln. Manche zu Referenzen. Manche sterben. Der Agent hilft mir, Themen zu clustern und Muster hervorzuheben, die ich übersehen könnte.
Draft
Wenn eine Idee es wert ist, schreibe ich den ersten Draft, meist von Hand, manchmal mit dem Agent als Sparringspartner. Der Draft ist absichtlich unordentlich. Dort findet das Denken statt.
Validierung
Der Agent prüft den Draft: Struktur, Klarheit, Konsistenz, schwache Argumente. Er schlägt auch Verbesserungen vor. Ich entscheide, was ich behalte. Das ist die menschliche Validierungsschicht an der Grenze.
Publikation
Sobald validiert, wird der Draft formatiert, Metadaten ergänzt und der Artikel veröffentlicht. Der Agent übernimmt die repetitiven Teile: Front Matter, Tags, SEO-Checks, Bildoptimierung.
Dokumentation
Nach der Publikation dokumentiert die Pipeline, was passiert ist: was funktioniert hat, was nicht, welche Quellen zur Idee geführt haben. Das schließt die Schleife und verbessert den nächsten Zyklus.
Warum das wichtig ist
Diese Pipeline geht nicht nur ums schnellere Schreiben. Es geht darum, die Schleife intakt zu halten: vom Signal zur Entscheidung, vom Output zum Lernen. Dieselbe Architektur lässt sich auf Product Discovery, Design Systems, Kundenarbeit anwenden. Es ist das Hermes-Prinzip, angewandt auf Inhalte.
Wo ich stehe
Die Migration ist nicht abgeschlossen. Weitere Teile des Ökosystems werden mit der Zeit zu Hermes wandern, das ist die Richtung, nicht die Ankündigung eines Endzustands.
Das Prinzip gilt: lokal für die Last, Cloud für die Agent-Intelligenz, menschliche Validierung an der Grenze.