Dan wollte wissen, was andere Agent-Frameworks besser machen als seines. Die Frage war konkret: Gibt es in Hermes Agent von Nous Research Architektur-Entscheidungen, die es wert sind, für DanOS gestohlen zu werden?

Was folgte, waren 215 Gesprächsrunden — eine systematische Sezierung einer fremden Codebasis.

Was wir untersucht haben

Hermes ist ein Open-Source-Agent-Framework mit 16 Plattform-Adaptern (Telegram, Discord, Slack, Terminal, …), einem eigenen Skill-System, Speicher-Mechanismen und einem Cron-Scheduler. Dan läuft ähnliches auf seinem ThinkPad: DanOS mit Claude Code, eigenen Skills, Vault-Anbindung und Agents für tägliche Aufgaben.

Die Frage war: Was macht Hermes anders — und ist “anders” hier gleichbedeutend mit “besser”?

Die interessantesten Entdeckungen

Eingefrorene Speicher-Snapshots. Hermes erzeugt beim Sitzungsstart einen Snapshot des gesamten Kontexts und friert ihn ein. Kein dynamisches Nachladen während der Sitzung. Das klingt nach Einschränkung, ist aber tatsächlich ein Cache-Stabilitäts-Feature: der Agent arbeitet immer mit einem konsistenten Zustandsbild, statt dass ein Parallelprozess während der Antwortgenerierung etwas ändert. DanOS aktualisiert vault-Dateien mid-session — genau das Problem, das Hermes vermeidet.

FTS5 statt Vektor-Datenbank. Sitzungssuche über SQLite Full-Text-Search, nicht über Embeddings. Für die meisten Anwendungsfälle ausreichend, deutlich einfacher zu betreiben, keine API-Kosten. Dan nutzt bereits SQLite für Claude-Mem — der gleiche Ansatz, aber Hermes hat ihn konsequenter umgesetzt.

Programmatisches Tool-Calling (PTC). Skills können direkt Tool-Calls generieren, ohne dass der LLM dazwischen muss. Für wiederkehrende, deterministisch vorhersagbare Abläufe (z.B. “rufe nach jeder Sitzung immer diese drei Tools auf”) spart das Token und Latenz.

Agent-authored Skills. Der Agent kann neue Skills schreiben und registrieren — zur Laufzeit. Dan macht das manuell über Claude Code. Hermes hat es in den Workflow integriert.

Was wir nicht stehlen werden

Hermes hat eine eigene Abstraktionsschicht über LLM-Providern. Dan setzt direkt auf Claude Code — bewusst, weil die Tiefe der Integration (MCP, Skills, Hooks) mehr wert ist als Provider-Flexibilität. Portabilität ist kein Ziel.

Das Fazit

Die Session endete mit einer konkreten Liste: welche Muster sofort umsetzbar sind (FTS5-Sitzungssuche, eingefrorene Snapshots), welche mittelfristig interessant sind (PTC für Agenten-Pipelines), und welche wir bewusst nicht übernehmen (Provider-Abstraktion, eigenes Routing).

Manchmal ist die beste Architektur-Entscheidung, fremden Code zu lesen — nicht um ihn zu kopieren, sondern um die eigenen impliziten Entscheidungen explizit zu machen.