Mein Weg von OpenClaw zu Hermes

Ich habe Agentensysteme nicht erst entdeckt, als sie eine hübsche Desktop-App und hunderte Community-Stories hatten. Ich war bei frühen Hermes-Agent-Versionen dabei und bin direkt aus der OpenClaw-Welt gewechselt. Entscheidend war für mich nicht ein einzelner Benchmark, sondern die Architektur: persistente Erinnerung, Skills als prozedurales Wissen, ein Gateway über mehrere Plattformen, planbare Jobs und die Möglichkeit, Arbeit an isolierte Subagenten zu geben.

Seitdem hat sich Hermes schnell weiterentwickelt. Genau deshalb behandle ich jede Versions- und Feature-Aussage auf dieser Seite mit Datum und Quelle. Die Live-Seite war vor diesem Ausbau noch auf v0.13 eingefroren; der jetzt geprüfte Stand ist v0.18.2. Aktualität ist bei Agentensoftware kein redaktionelles Extra, sondern Teil der Betriebssicherheit.

Meine Erfahrung ersetzt nicht die offizielle Dokumentation. Sie ergänzt sie um die Fragen, die nach dem Installer kommen: Welche Rechte erhält der Agent? Wie verhindere ich Leerlaufkosten? Wo endet Memory und beginnt ein Skill? Wie sichere ich eine Telegram-Instanz? Wann reichen Cron und Subagenten – und wann braucht es Paperclip als Control Plane?

Was ich mit Agenten aufgebaut und erprobt habe

Die konkrete Ausprägung variiert, das wiederkehrende Muster bleibt: Ein Agent wird dann wertvoll, wenn Input, Ergebnis, Qualitätskontrolle und Ausnahmeweg klar sind. Zu den von mir erprobten Bereichen gehören:

  • Telegram- und Messaging-Assistenten mit dauerhaftem Gateway, getrennten Sessions und geplanten Aufgaben.
  • Research- und Daily-Briefing-Workflows mit Quellenprüfung, Relevanzfiltern und Zustellung.
  • Content- und SEO-Operationen, die Recherche, Entwurf, interne Verlinkung, QA und Veröffentlichung trennen.
  • Repository-, Coding- und DevOps-Aufgaben mit Tests, isolierten Arbeitsbereichen und nachvollziehbaren Änderungen.
  • Skills, Memory-Strukturen und Kontextdateien, die Verfahren wiederverwendbar machen, ohne jede Session aufzublähen.
  • Cron- und Script-Only-Automationen, bei denen ein LLM nur startet, wenn tatsächlich neue Arbeit vorliegt.
  • Mehrere spezialisierte Agenten und Paperclip-artige Organisationsmodelle für Ziele, Tickets, Budgets und Governance.
  • Provider-Routing zwischen gehosteten, lokalen und Enterprise-Modellen – abhängig von Daten, Aufgabe und Kosten.

Ich veröffentliche hier keine vertraulichen Kundeninternas und erfinde keine Fallstudien. Wo konkrete öffentliche Community-Beispiele helfen, verlinke ich die offizielle Sammlung von 262 Hermes User Stories. Eigene Aussagen markiere ich als Erfahrung oder Empfehlung.

Meine Haltung zu „Zero Human Companies“

Der Begriff beschreibt eine wichtige Verschiebung: Nicht nur KI in eine alte Organisation einbauen, sondern Produkt, Prozess und Rollen um maschinelle Ausführung herum entwerfen. Ich halte jedoch wenig von der Behauptung, Verantwortung verschwinde dadurch. Recht, Kapital, Beziehungen, Geschmack, Krisen und irreversible Entscheidungen brauchen weiterhin accountable Menschen oder Organe.

Die spannende Firma ist nicht die mit den meisten Agenten. Es ist die Firma, die aus wenigen Menschen und gut begrenzter Software mehr verlässliche Outcomes erzeugt. Agenten übernehmen wiederholbare Wissens- und Tool-Arbeit. Menschen definieren Mission, Grenzen und Qualitätsmaß, lösen Ausnahmen und tragen die Konsequenzen.

Mein Grundsatz

Autonomie ist keine Eigenschaft, die man einmal aktiviert. Sie ist eine widerrufbare Berechtigung, die sich ein Workflow durch gemessene Zuverlässigkeit verdient.

So arbeite ich in Projekten

  1. Outcome verstehen: Was muss nachher messbar besser sein, wer nutzt es, welche Fehler sind akzeptabel?
  2. Datenfluss zeichnen: Welche Systeme, Anbieter, Messenger und Menschen sehen welche Informationen?
  3. Kleinsten Pilot begrenzen: Read-only beginnen, Rechte und Budget reduzieren, klare Abnahme definieren.
  4. Determinismus vor LLM: Ereigniserkennung, Validierung und feste Regeln als Code, variable Arbeit mit Agent.
  5. Repräsentativ testen: Nicht nur Happy Path, sondern fehlende Daten, falsche Eingaben, Provider-Ausfall und Grenzfälle.
  6. Betrieb übergeben: Skills, Konfiguration, Tests, Backup, Monitoring, Runbook und Kill-Switch verständlich dokumentieren.

Ich bin nicht an Hostinger, Nous Portal, OpenRouter, AWS, Azure oder ein Modell gebunden. Die Empfehlung folgt Use Case, Daten, Team und vorhandener Infrastruktur. Hostinger-Links auf dieser Seite sind als Affiliate-Links markiert; die Beratung kann genauso auf IONOS, Hetzner, einem Mac, AWS oder einer internen Umgebung stattfinden.

Transparenz, Grenzen und Quellen

HermesCoach ist ein unabhängiges Angebot. Es besteht keine gesellschaftsrechtliche oder redaktionelle Verbindung zu Nous Research, Paperclip oder Hostinger. Markennamen gehören ihren jeweiligen Inhabern. Feature-Angaben stammen möglichst aus offizieller Dokumentation oder öffentlichen Repositories und werden mit dem Prüfdatum versehen.

Technische Beratung ist keine Rechts-, Steuer-, Anlage- oder medizinische Beratung. Gerade bei Mitarbeiter-, Kunden- oder Gesundheitsdaten muss der konkrete Datenfluss mit qualifizierten Fachleuten bewertet werden. „Self-hosted“ ist hilfreich, aber keine automatische DSGVO-Konformität.

Wenn du einen Fehler findest oder eine Quelle veraltet ist, schreibe an hi@unternehmensbot.de. Eine glaubwürdige Wissensbasis muss korrigierbar sein.