AI Operating System v1¶
Stand: 2026-05-30
1. Komponenten¶
| Komponente | Rolle |
|---|---|
| OpenCode | Operations-Client fuer Admins und Operatoren |
| OpenWebUI | Chat-UI und Self-Service Einstieg |
| Voice / Jarvis | Audio-Client mit Hermes Backend |
| Teams | geplanter Chat-Kanal fuer Hermes |
| Lanstyle Agent Gateway | zentrale Context-/Policy-/Routing-Schicht |
| Nous Hermes Core | Agent-Core mit Memory, Skills, Sessions |
| LiteLLM | Modellrouting und Model Access |
| Qdrant | semantischer Retrieval-Index |
| Obsidian | menschenlesbare Knowledge Source |
| MCPHub / Remote MCP | Tool-Zugriff |
| Controlled Execution | sichere Infrastruktur-Aenderungen |
2. Datenfluesse¶
flowchart TD
OpenCode["OpenCode"] --> LiteLLM
OpenCode --> MCP["Remote MCP"]
OpenCode -. "optional context" .-> Gateway["Lanstyle Agent Gateway"]
OpenWebUI["OpenWebUI"] --> LiteLLM
Voice["Voice Client"] --> Gateway
Teams["Teams"] --> Gateway
Gateway --> Core["Nous Hermes Core"]
Gateway --> Qdrant["Qdrant"]
Qdrant --> Obsidian["Obsidian Vault"]
Core --> LiteLLM
MCP --> CE["Controlled Execution"]
3. Memory Layer¶
- Native Nous Memory fuer Agent-/User-Kontext.
- Obsidian fuer kuratierte Betriebsfakten.
- Qdrant fuer semantisches Retrieval.
- MkDocs fuer veroeffentlichte Betriebsdoku.
- Vaultwarden fuer Secrets.
4. Governance Layer¶
Governance besteht aus:
- RBAC
- Approval
- Policy/Risk Engine
- Dependency Locks
- Backup Enforcement
- Audit
- Verification
- Rollback/Recovery
5. Modellrouting¶
| Zweck | Modell |
|---|---|
| Schnell | lanstyle/fast |
| Standard | lanstyle/agent-stable |
| Planung | lanstyle/architect |
| Embedding | lanstyle/embed |
| Experiment | lanstyle/agent, entfernt |
6. Retrieval Layer¶
Retrieval darf Kontext liefern, aber keine Wahrheit erzwingen. Jede Antwort soll Quelle, Confidence und Unsicherheit sichtbar machen.
Phase-3-Werkzeug:
hermes_context_search: read-only Kontextsuche in Obsidian/Qdrant fuer OpenCode und Operator-Flows.- Antwort mit
trust_summary, Quellen, Confidence und begrenzter Excerpt-Laenge. - Keine Infrastrukturwrites und keine Secret-Ausgabe.
7. Tool Layer¶
Tools sind getrennt:
- read-only
- preflight
- approval preview
- scoped write
- recovery
- destructive nur separat und streng
Writes laufen nur ueber Controlled Execution.
8. User Journey¶
Normaler Benutzer¶
- Nutzt OpenWebUI oder OpenCode Operator-Profil.
- Sieht kuratierte Modelle.
- Nutzt read-only oder Self-Service.
- Keine Secrets im Chat.
Operator¶
- Startet Preflight oder Change Review.
- Bekommt Operator Summary, Risk, Policy, Locks, Backup Readiness.
- Bereitet Approval vor.
- Fuehrt keine direkten Writes ohne Approval aus.
OpenCode mit Hermes-Kontext¶
- Operator arbeitet weiter direkt in OpenCode mit LiteLLM/MCP.
- Bei Infrastruktur-, Runbook-, Architektur- oder Change-Fragen ruft OpenCode
hermes_context_searchauf. - Das Tool liefert kompakte Quellen aus Obsidian/Qdrant.
- Fuer echte Aenderungen folgt danach Preflight/Approval ueber Controlled Execution.
Admin¶
- Verwaltet Tokens, Modelle, Runtime und Recovery.
- Darf Evaluation-Modelle sehen.
- Muss Secrets ueber Vaultwarden fuehren.
9. Leitsatz¶
Hermes ist das zentrale Brain fuer Kontext, Memory, Retrieval und Policy. Execution bleibt kontrolliert, scoped und auditierbar.