Hermes Central Brain

Stand: 2026-05-30

Korrektur des Zielbilds

Hermes ist nicht primaer Voice oder Teams. Hermes ist die zentrale Context-, Memory-, Retrieval- und Policy-Schicht der Lanstyle AI Suite.

Voice und Teams sind nur zwei Kanaele, die besonders klar ueber den Lanstyle AI Gateway laufen muessen. OpenCode und OpenWebUI sollen langfristig ebenfalls von Hermes-Kontext profitieren, ohne ihre jeweilige Staerke zu verlieren.

Rollen im Central-Brain-Modell

Ebene	Aufgabe
Lanstyle AI Gateway	Auth, RBAC, Audit, Policy, Retrieval-Orchestrierung, Channel Adapter
Nous Hermes Core	Agent-Logik, Session Memory, native Memory, Skills, Learning Loop
Obsidian	kuratierte menschenlesbare Wissensbasis
Qdrant	semantischer Retrieval-Index
LiteLLM	Modellrouting und Model Access
MCP / Controlled Execution	read-only, preflight und scoped Infrastrukturaktionen

OpenCode Zielintegration

OpenCode ist bei Lanstyle ein Operations-Client fuer SSH, Linux, Proxmox, Aruba, UniFi, PowerShell, Intune, M365, Azure, APIs, Firewalling, Dokumentation, Runbooks, Architektur, Troubleshooting und Change Reviews.

Deshalb braucht OpenCode Zugriff auf:

• Session Context
• Obsidian Retrieval
• Qdrant Retrieval
• Projektwissen
• Architekturwissen
• Runbooks
• Change-Historie
• Governance- und Policy-Kontext

Bewertete Varianten

A: OpenCode -> Hermes -> LiteLLM

Vorteile:

• zentraler Kontext fuer alle Prompts
• einheitliche Audit-/Policy-Schicht
• Memory kann automatisch eingebunden werden

Nachteile:

• hoehere Latenz
• mehr Tokenverbrauch durch Retrieval-Kontext
• Risiko fuer Coding-Performance
• groesserer Gateway-Betriebsdruck
• Tool-/MCP-Streaming komplexer

Bewertung: nicht als Standardpfad fuer alle OpenCode-Sessions geeignet.

B: OpenCode -> LiteLLM direkt plus Hermes Tool

Vorteile:

• OpenCode bleibt schnell
• Coding-/Shell-nahe Arbeit bleibt schlank
• Hermes-Kontext wird nur bei Bedarf abgefragt
• niedriges Risiko fuer bestehende Operator-Flows
• klare Trennung zwischen Model Call und Knowledge/Policy Query

Nachteile:

• Agent muss wissen, wann Hermes-Kontext gebraucht wird
• kein automatischer globaler Session-Memory-Kontext
• UX braucht gute Tool-Beschreibungen

Bewertung: bester kurzfristiger Pfad.

C: Hybrid Routing

Vorteile:

• Standardarbeit direkt ueber LiteLLM
• Ops-/Change-/Troubleshooting-Fragen optional mit Hermes Retrieval
• bestimmte Modi koennen bewusst ueber Gateway laufen
• gute Balance aus Performance und Governance

Nachteile:

• braucht klare Routing-Regeln
• braucht Operator UX, damit Benutzer den Modus verstehen
• muss Tokenbudget und Kontextumfang begrenzen

Bewertung: Zielarchitektur fuer produktiven Betrieb.

Empfehlung fuer OpenCode

Kurzfristig:

• OpenCode bleibt direkt an LiteLLM und Remote MCP.
• Hermes wird als explizites read-only Kontext-/Policy-/Retrieval-Tool angebunden.
• Kein Default-Routing von OpenCode komplett durch Hermes.
• OpenCode nutzt Hermes zuerst fuer Operations-Kontext, Change Review, Incident Analyse und Dokumentationssuche, nicht fuer jeden kurzen Prompt.

Mittelfristig:

• OpenCode bekommt Modi:
• fast/coding: LiteLLM direkt, kein Retrieval
• ops-context: Hermes Retrieval Tool
• change-review: Hermes + Policy/Risk + Controlled Execution Preview
• incident: Hermes + State/Drift + Safe Mode Status

Langfristig:

• Hybrid-Routing mit automatisch begrenztem Kontext.
• Retrieval nur bei Infrastruktur-, Architektur-, Runbook-, Change- oder Troubleshooting-Signalen.
• Keine Rohdatenflut in OpenCode.

Governance

Hermes darf OpenCode Kontext liefern, aber keine lokalen bash/edit-Rechte erteilen und keine Controlled Execution umgehen. Echte Infrastrukturaktionen bleiben beim MCP/Controlled Execution Layer.

Details zu OpenCode Usage Profile, Ops-Modi, Obsidian Governance und Token Pressure stehen in OpenCode als AI Operations Console.