📚 HF Wiki

aktualisiert 18:55:40
Wiki / system / strategie-archiv / 2026-05-02 / agentensystem-konzept-2026.md

Viaviva Agentensystem — Konzept und Strategie 2026

Stand: 2026-04-27 Status: Konzept-Dokument zur Auswertung vor Umsetzung Adressat: Chapaty (Review) und Claude Code (Umsetzungs-Basis) Vorgänger-Konzept: OpenClaw-Stack (CLAUDE.md, ARCHITEKTUR_V1.6.md, 04_NEXT_STEPS.md)

---

Worum es in diesem Dokument geht

Dieses Dokument beschreibt das überarbeitete Agentensystem für das Viaviva-Ökosystem (Hochfrequenz, GFKB, Immovia, Viaviva-Kern). Es ersetzt das bisherige OpenClaw-Konzept aus dem Übergabe-Paket vom April 2026.

Das Dokument ist bewusst keine reine Auftragsanweisung sondern eine erklärende Konzept-Beschreibung. Du sollst es lesen können und verstehen warum welche Entscheidung getroffen wurde, bevor irgendetwas umgesetzt wird. Erst nach deiner Zustimmung werden daraus konkrete Auftragsdokumente für Claude Code abgeleitet.

Falls du beim Lesen merkst dass etwas nicht stimmt, anders entschieden werden soll, oder unklar ist — markiere es. Wir arbeiten dann an dieser Stelle nach. Erst wenn das Konzept solide steht beginnen wir mit der Umsetzung.

---

Teil 1 — Was hat zu dieser Überarbeitung geführt

Erkenntnisse aus dem alten OpenClaw-Stack

Das ursprüngliche Konzept hatte mehrere strukturelle Probleme die im Betrieb sichtbar wurden:

Problem 1: Große Multi-Step-Prompts auf CPU-only-Hardware

OpenClaw hat einen Reasoning-Stil bei dem große Prompts (System-Prompt, Tool-Schema, Persona-Beschreibung, Aufgaben-Kontext, Memory) zu jedem LLM-Call geschickt werden. Auf der vorhandenen Hardware (8 vCPU EPYC, kein GPU) bedeutet das pro Call erhebliche Inferenz-Last für qwen3:14b. Bei Multi-Step-Workflows (Dispatcher → Architekt → Worker → QA) summiert sich das. Konkretes Beispiel aus dem Live-Betrieb: ein qwen3:14b-Call blockierte 7 von 8 CPU-Kernen. Während dieser Zeit ist das gesamte System praktisch unbenutzbar für andere Tasks.

Problem 2: Acht Personas als Architektur-Komponenten

Die Aufteilung in Lenny (Dispatcher), Howard (Builder), Sheldon (Architect), Amy (QA), Raj (Ops), Zack (Media), Bernadette (Security), plus Penny als Telegram-Frontend, bedeutet: jede Persona hat eigenen System-Prompt, eigene Konfiguration, eigene Schablonen-Zuordnung. Funktional sind das aber im Grunde drei Modell-Größen: ein Klassifizierer (1.7B), ein Standard-Worker (8B), ein schwerer Worker (14B). Die Persona-Vielfalt verteilt Komplexität ohne funktionalen Gewinn.

Problem 3: OpenClaw als Engine ist redundant

Was OpenClaw macht — Telegram-Trigger empfangen, LLM-Call orchestrieren, Antwort zurückschicken — kann n8n nativ. n8n hat Telegram-Trigger-Node, HTTP-Request-Node für Ollama, alle benötigten Bausteine eingebaut. OpenClaw verteilt eine Komponente die nicht nötig ist und bringt zusätzliche Failure-Modes (Stuck-Sessions, Reasoning-JSON-Bugs, Disk-Recovery-Probleme aus der Vergangenheit).

Problem 4: RAG-Wiki als Eigenbau wo Standard reicht

Das geplante /root/openclaw-wiki/ mit Snippet-Lernschleife und PDF-Ingestion war ein eigenes Subsystem in Aufbau. Für Email-Antwort-Templates mit Self-Learning reicht eine Q+A-Tabelle in Postgres mit pgvector-Embedding und Confidence-Threshold — kein neues Subsystem.

Was am alten Konzept richtig war und bleibt

Bei aller Kritik gibt es Kern-Entscheidungen die strategisch korrekt sind und übernommen werden:

---

Teil 2 — Die zentrale strategische Verschiebung

Vom "Agent-First-System" zum "klassisch-orchestrierten Stack mit LLM-Veredelung"

Das ist die wichtigste konzeptuelle Verschiebung. Das alte Konzept versuchte einen LLM-Agenten als Generalisten für alle Aufgaben zu bauen — Dispatcher entscheidet alles per Reasoning, Workflows entstehen ad-hoc.

Das neue Konzept dreht die Reihenfolge um:

  1. Klassische Orchestrierung als Fundament — n8n-Workflows mit deterministischer Logik, Schablonen, IF-THEN-Regeln, Datenbank-Lookups
  2. LLM nur dort wo wirklich Sprache verarbeitet werden muss — Email-Antwort-Personalisierung, Klassifikation ambiger Eingaben, Long-Form-Content-Generation
  3. Cloud-LLM für anspruchsvolle Tasks, lokales LLM nur für klassifizier/embedding-Aufgaben

Warum diese Verschiebung sinnvoll ist

Token-Geschwindigkeit als limitierender Faktor: auf CPU-only-Hardware ist jeder LLM-Call teuer. Wenn ein Großteil der Workflows ohne LLM auskommt weil sie deterministisch sind, sparen wir entsprechend Inferenz-Last. Das macht die Hardware ausreichend.

Vorhersagbarkeit: klassische Workflows sind vorhersagbar. LLM-Outputs sind probabilistisch. Bei produktiven Geschäftsprozessen (Newsletter-Versand, Bestellabwicklung, Lead-Übermittlung) ist Vorhersagbarkeit wichtiger als Flexibilität.

Wartbarkeit: ein n8n-Workflow ist visuell, debugbar, testbar. Ein LLM-Agent-Reasoning-Pfad ist eine Blackbox. Bei Fehlern willst du den Workflow im n8n-UI lesen können.

Stabilität bei Token-Engpässen: wenn Cloud-LLM-Quotas erschöpft sind oder lokale Inferenz hängt, bleiben deterministische Workflows funktionsfähig. Das System bricht nicht zusammen.

LLMs für das was sie wirklich gut können: Sprache verstehen und produzieren. Nicht für komplexe Logik-Bäume oder Tool-Auswahl-Reasoning auf schwacher Hardware.

Konkretes Beispiel der Verschiebung

Alt — Agent-First:


Email kommt → OpenClaw-Dispatcher (qwen3:14b, großer Prompt)
  → entscheidet Workflow-Typ (Reasoning)
  → ruft Howard auf (qwen3:14b)
  → Howard generiert Antwort (Long Reasoning)
  → Amy QA (qwen3:8b)
  → Versand

Neu — Stack-First:


Email kommt → n8n-Webhook
  → Spam-Filter-Regel (kein LLM)
  → Q+A-Wiki-Suche via pgvector (kein LLM)
  → Match > 0.85? → fertige Antwort senden, dich informieren
  → Match 0.7-0.85? → qwen3:8b personalisiert Antwort
                    → Telegram-Approval von dir
  → Match < 0.7? → Cloud-LLM generiert Draft
                 → Telegram-Approval von dir

Gleicher Output, andere Architektur. Vorhersagbarer, ressourcen-schonender.

---

Teil 3 — Die Multi-Server-Architektur und Eigentums-Trennung

Warum die Architektur über zwei Server verteilt ist

Du betreust GFKB als Partner. Die saubere Doktrin lautet: bei Trennung der Partnerschaft müssen alle GFKB-relevanten Daten und Operationen für GFKB weiternutzbar sein, ohne dich. Das ist nicht nur freundlich gemeint sondern juristisch und ethisch sauber.

Daraus folgt eine klare Eigentumstrennung:

All-Inkl (GFKB-Eigentum):

Hostinger (dein Eigentum, dein Service-Layer):

Die Werkstattbuch-vs-Lieferschein-Disziplin

Wenn dein Hostinger-System für GFKB arbeitet, läuft das wie bei einem externen Dienstleister:

Werkstattbuch (Perfex-Viaviva, deins): detaillierte Operations-Logs. Welcher Workflow lief, welches Tool wurde genutzt, welche LLM-Antwort kam, welche Schablone wurde verwendet. Das sind deine Betriebsgeheimnisse und Werkzeuge.

Lieferschein (Perfex-GFKB, ihres): Ergebnis-Dokumentation. "Newsletter Thema X versandt am Y an Z Empfänger, Open-Rate W. Anhang: Newsletter-HTML, Empfängerliste, Tracking-Daten." Das ist GFKB-Eigentum und überlebt die Partnerschaft.

Praktisch heißt das: jeder n8n-Workflow der GFKB-Daten verarbeitet, hat als finalen Schritt einen Perfex-GFKB-API-Call der das Ergebnis dort einträgt. Kein GFKB-Workflow ohne Niederschlag bei GFKB.

Bei Trennung: du nimmst dein Werkstattbuch mit (Workflows, Schablonen, Brand-Voices, Q+A-Wiki-Embeddings). GFKB behält ihre Kundendaten, ihre Ergebnis-Historie, ihr Perfex. Beide Seiten sind handlungsfähig.

Warum die Eigenmarken alle auf Hostinger laufen

Hochfrequenz, Immovia und Viaviva sind deine Marken. Hier gibt es keine Eigentumstrennung, alles auf einem Server (Hostinger), eine kohärente Welt. Das vereinfacht die Architektur erheblich für den Großteil der Operations und macht die Cross-Server-Komplexität zu einem GFKB-Sonderfall statt zur Standard-Architektur.

---

Teil 4 — Der Tech-Stack und warum jede Komponente

Die Stack-Karte


┌─────────────────────────────────────────────────────────────┐
│  STEUERUNG-LAYER                                            │
│  Telegram-Bot (Mensch ↔ System) | Outline-Wiki (Inbox)     │
└──────────┬──────────────────────────────────────────────────┘
           │
┌──────────┴──────────────────────────────────────────────────┐
│  ORCHESTRATOR-LAYER                                         │
│  n8n (Workflows) | Postgres+pgvector (State + Q+A-Wiki)    │
└──────────┬──────────────────────────────────────────────────┘
           │
┌──────────┴──────────────────────────────────────────────────┐
│  SERVICE-LAYER                                              │
│  Listmonk (Newsletter) | Mailcow (Mailserver)              │
│  Chatwoot (Inbox-Helpdesk) | Plausible (Tracking)          │
│  Browser-Use (Web-Automation) | SearXNG (Suche)            │
│  Vaultwarden (Secrets) | Uptime-Kuma (Monitoring)          │
└──────────┬──────────────────────────────────────────────────┘
           │
┌──────────┴──────────────────────────────────────────────────┐
│  LLM-LAYER                                                  │
│  Lokal: qwen3:1.7b (Klassifikation), qwen3:8b (Standard)   │
│  Cloud: Kimi K2, Codex/GPT-5, Claude (über Abos)           │
│  ElevenLabs Pro (Voice für Video-Pipeline)                 │
└──────────┬──────────────────────────────────────────────────┘
           │
┌──────────┴──────────────────────────────────────────────────┐
│  CONTENT-LAYER                                              │
│  Astro (Static Sites Eigenmarken)                           │
│  Plugin v2 (WP-Pflege für GFKB-WP-Sites)                   │
│  Member-App (SvelteKit, HF-Universum)                       │
│  Remotion (Video-Pipeline)                                  │
└─────────────────────────────────────────────────────────────┘

Warum diese Komponenten

Telegram als Steuer-Oberfläche — bewährt aus Vorgängerkonzept, mobiler Zugriff jederzeit, Approval-Loops natürlich. Bleibt.

Outline als Wiki und Auftrags-Inbox — OSS, MIT-Lizenz, hat REST-API plus Webhooks, läuft als ein Docker-Container mit Postgres-Backend. Du arbeitest in Claude.ai mit Outline-MCP-Anbindung, schreibst Aufträge in einem /auftrage/inbox/-Ordner, n8n triggert auf Webhook bei neuen Einträgen. Eigenes Brand-Wiki pro Marke (HF-Voice, GFKB-Compliance, Immovia-Objektlogik). Das ersetzt das geplante OpenClaw-Wiki.

n8n als Orchestrator — ist im aktuellen Stack schon vorhanden, hat alle nötigen Trigger und Nodes (Telegram, HTTP, Webhook, Cron, IMAP, alles), visuell debugbar. Wird die zentrale Schaltstelle für alle Workflows.

Postgres mit pgvector — Postgres ist im Stack, pgvector-Extension ist das Standard-Tool für Embedding-basierte Suche. Q+A-Wiki, Member-App-Daten, Studien-Datenbank, alles in einem System.

Listmonk — OSS Newsletter-System mit Sequencing, Behavioral-Triggers, REST-API, Open/Click-Tracking. Genau das was Newsletter-Workflows brauchen. Gibt's schon, bleibt.

Mailcow — OSS All-in-One-Mailserver für die GoDaddy-Migration. Ersetzt das jetzige GoDaddy-Mail-Setup. Eigenständig, alles auf Hostinger, 7 Konten zu migrieren.

Chatwoot — OSS Helpdesk der Email + Telegram + WhatsApp + Web-Chat in eine Inbox legt, mit Auto-Reply-Regeln und Tagging. Hier landen alle Kundendialoge, n8n hängt drüber für Klassifikation und Q+A-Wiki-Match. Macht den Email-Workflow viel sauberer als die jetzige Multi-Inbox-Lösung.

Plausible — OSS Analytics, cookieless, DSGVO-tauglich. Wird Behavioral-Trigger-Quelle für Onboarding-Workflows. Alternative wäre Eigenbau-Tracking im Plugin v2 — Entscheidung kommt mit Plugin-v2-Reife.

Browser-Use — OSS Browser-Automation mit LLM-Backend. Für Aufgaben wo gescraped, ein Formular ausgefüllt, oder ein Login bedient werden muss (z.B. Universitäts-Webseiten für Lead-Recherche). Ersetzt Browserless+manueller-OpenClaw-Kombi durch eine fokussierte Lösung.

SearXNG — OSS Meta-Search-Engine self-hosted. Ersetzt Google-API-Calls für den Großteil der Recherche-Aufgaben. Kostenlos, anonym.

Vaultwarden — OSS self-hosted Bitwarden für Secret-Management. Alle API-Tokens, Passwörter, Credentials zentral. Ablöser für die jetzige .secrets/-Datei-Struktur.

Uptime-Kuma — OSS Monitoring mit Telegram-Alerts. Statt selbstgebautes Diagnostic-Script. Erkennt Container-Down, Service-Down, hohe CPU-Last automatisch.

Lokale LLMs (qwen3-Familie):

Cloud-LLMs: für anspruchsvolle Sprach-Tasks (Long-Form-Content, Script-Generation, Email-Drafts mit Brand-Voice). Nutzen deine bestehenden Abos (Kimi K2 NIM, Codex/GPT-5, Claude). Lokale Modelle sind Backup wenn Cloud-Quota erschöpft.

ElevenLabs Pro — für Video-Pipeline (Voice-Cloning, Multi-Voice-Generation für Zitate-Collagen). Aktiv wenn Video-Pipeline gebaut wird.

Was raus fliegt aus dem alten Stack

OpenClaw — komplett. Funktion wird von n8n übernommen.

LiteLLM — wird durch direkte Ollama-API-Calls aus n8n ersetzt. Eine Schicht weniger.

media_server.py auf Port 8766 — wird durch Chatwoot + Mailcow + n8n-IMAP/SMTP-Nodes ersetzt. Sauberer und wartbarer.

Acht-Personas-Architektur — wird zu drei funktionalen Modell-Größen reduziert. Personas können als Stilvorgaben in einzelnen n8n-Workflows weiterleben (Telegram-Antworten dürfen "Lenny-Stil" haben), aber sie sind keine Architektur-Komponenten mehr.

OpenClaw-Wiki als Eigenbau-Subsystem — wird zu Outline (allgemeines Wiki) plus Postgres-pgvector-Tabelle (Q+A-Wiki spezifisch).

---

Teil 5 — Die zentrale Konvention: Auftrags-Inbox

Was das ist und warum es wichtig ist

Eine der wichtigsten Architektur-Entscheidungen ist die zentrale Auftrags-Inbox. Das ist eine Konvention die alle Akteure (du, Claude Code, Cloud-LLMs, n8n, lokale LLMs) miteinander verbindet.

Konkret: in Outline gibt es eine Ordnerstruktur:


/auftrage/
  /inbox/          (neu eingegangene Aufträge)
  /in-arbeit/
    /claudecode/   (Claude Code arbeitet daran)
    /kimi/         (Cloud-LLM arbeitet daran)
    /local-qwen/   (lokales Modell arbeitet daran)
    /mensch/       (du arbeitest daran)
  /wartet-auf-freigabe/  (fertig, dein Approval ausstehend)
  /erledigt/       (abgeschlossen, archiviert)
  /abgebrochen/    (verworfen mit Begründung)

Jeder Auftrag ist eine Markdown-Datei mit standardisiertem Frontmatter:


---
auftrag-id: 2026-04-27-001
quelle: telegram | claude-chat | n8n-trigger | manuell
prioritaet: niedrig | normal | hoch | kritisch
ausfuehrer: claudecode | kimi | codex | local-qwen | mensch
brand: hochfrequenz | gfkb | immovia | viaviva
backup-vor-aktion: ja | nein
freigabe-noetig-vor-deploy: ja | nein
perfex-niederschlag: required | optional | nicht-zutreffend
---

# Auftrag: ...

## Kontext
...

## Was zu tun ist
...

## Pfade/Files betroffen
...

## Erfolgs-Kriterien
...

## Rollback-Plan
...

## Lessons-Learned (nach Abschluss)
...

Warum diese Konvention so wichtig ist

Eine gemeinsame Sprache für alle Akteure: ob du via Telegram einen Auftrag startest, oder n8n einen automatisch generiert weil ein Trigger gefeuert hat, oder du in Claude.ai etwas ausarbeitest und ablegst — alles landet im gleichen Format an gleicher Stelle.

Klare Übergaben: wenn ein Auftrag von Cloud-LLM-Drafting zu deinem Approval zu Claude-Code-Umsetzung läuft, wandert er durch die Status-Ordner. Jederzeit ist klar wo er steht.

Nachvollziehbarkeit: alle erledigten Aufträge sind im /erledigt/-Ordner archiviert. Was wurde wann von wem warum gemacht — durchsuchbar.

Lernschleife: der Lessons-Learned-Abschnitt am Ende jedes Auftrags fließt in das System-Wiki ein. Cloud-LLM analysiert Patterns, Brand-Voices werden geschärft, Workflows werden optimiert.

GFKB-Compliance: durch das perfex-niederschlag-Feld ist sichergestellt dass jeder GFKB-Auftrag einen Lieferschein-Eintrag in Perfex-GFKB bekommt.

Wie n8n das nutzt

Outline hat Webhooks. Bei neuem Auftrag in /auftrage/inbox/ triggert n8n. Liest das Frontmatter, parst den Auftragstyp, fragt dich via Telegram nach Approval (wenn freigabe-noetig-vor-deploy: ja), übergibt an den Ausführer.

Das ist keine experimentelle Architektur — das ist ein bewährtes Workflow-Pattern.

---

Teil 6 — Die Brand-Wikis als LLM-Kontext

Warum LLMs Kontext brauchen

Das alte System hatte ein Problem: Cloud-LLMs (und auch lokale) wussten zu wenig über die Marken. Bei jedem Call mussten lange Prompts mit Brand-Voice, Compliance-Regeln, Produktinfos mitgeschickt werden — was Token-Last erzeugt und trotzdem inkonsistent war.

Die Lösung: Brand-Wiki in Outline

Pro Marke ein dediziertes Wiki:


/wiki/hochfrequenz/
  brand-voice.md          (Tonalität, Worte die wir nutzen, Worte die wir vermeiden)
  produkt-claims.md       (was wir behaupten dürfen, was nicht)
  compliance-tabu.md      (HMG/UWG-Begriffe die niemals fallen)
  haeufige-fragen.md      (Q+A für wiederkehrende Themen)
  hoerbuch-content.md     (Inhaltliches Wissen aus Dartsch-Hörbuch)
  studien-zusammenfassung.md (Dartsch-Studien strukturiert)
  erfahrungsberichte/
    migraene/
      bericht-001.md
      ...
    diabetes/
      ...

/wiki/gfkb/
  brand-voice.md
  compliance-themen.md
  produktkatalog.md
  ...

/wiki/immovia/
  brand-voice.md
  objekt-template.md
  zielgruppen.md
  paraguay-kontext.md
  ...

Plus eine Knowledge-Base für allgemeine Workflows:


/wiki/system/
  workflow-templates.md
  schablonen-bibliothek.md
  api-credentials-mapping.md  (verweist auf Vaultwarden, kein Klartext)
  troubleshooting/
    ...

Wie das im Workflow funktioniert

Wenn ein n8n-Workflow einen LLM-Call braucht (z.B. Email-Personalisierung für HF), passiert folgendes:

  1. n8n erkennt: das ist ein HF-bezogener Task
  2. n8n lädt die HF-relevanten Wiki-Dokumente in den Prompt-Kontext (statisch, mechanisch)
  3. Plus den spezifischen Aufgaben-Kontext (welche Email konkret)
  4. Plus die Aufgaben-Anweisung
  5. → Cloud-LLM oder lokales Modell

Bei kompakten Wiki-Dokumenten reicht das in jedes Modell. Statisch, vorhersagbar, kein RAG-System nötig.

Wo es doch RAG braucht: Q+A-Wiki

Für Email-Antworten ist statisches Laden nicht genug — die Frage des Kunden muss semantisch mit gespeicherten ähnlichen Fragen abgeglichen werden. Das ist das Q+A-Wiki:


qa_entries:
  id              SERIAL PRIMARY KEY
  brand           VARCHAR (hochfrequenz | gfkb | immovia | viaviva)
  trigger_phrases TEXT[]
  embedding       vector(384)  -- pgvector-Spalte
  answer_template TEXT
  confidence_threshold FLOAT
  approved_by     VARCHAR
  approved_at     TIMESTAMP
  use_count       INTEGER
  edit_history    JSONB
  created_at      TIMESTAMP

Bei Email-Eingang:

  1. Email wird mit qwen3:1.7b oder Cloud-Embedding-Modell zu einem Vektor konvertiert
  2. pgvector findet nächste Nachbarn in der Q+A-Tabelle (cosine similarity)
  3. Top-Match: similarity > 0.85 UND use_count >= 5 UND approved_by gesetzt → Auto-Send
  4. Match 0.7-0.85 oder neu → Telegram-Approval mit Vorschlag
  5. Match < 0.7 → Cloud-LLM generiert frischen Draft
  6. Deine Korrektur → use_count erhöht, edit_history erweitert, Embedding ggf. aktualisiert

Das ist die Lernschleife: bei jeder Korrektur wächst die Wissensbasis pro Brand und beantwortet wiederkehrende Fragen ohne dich.

---

Teil 7 — Die LLM-Eskalations-Pyramide

Wie Modelle ausgewählt werden

Das System eskaliert von billig zu teuer in dieser Reihenfolge:

Stufe 0 — Kein LLM: Erst prüfen ob die Aufgabe deterministisch lösbar ist. Schablonen-Match? Datenbank-Lookup? Reguläre Ausdrücke? Wenn ja: kein LLM. Beispiel: "Wann kommt meine Bestellung" → DB-Lookup nach Order-ID, fertig.

Stufe 1 — qwen3:1.7b lokal: Kurze Klassifikationen, Embeddings, Routing-Entscheidungen. Beispiel: "Ist diese Email Spam, Frage oder Bestellung?"

Stufe 2 — qwen3:8b lokal: Standard-Tasks mit Brand-Voice-Personalisierung. Beispiel: "Antworte auf diese Frage im HF-Stil mit dieser Q+A-Vorlage als Basis."

Stufe 3 — qwen3:14b lokal: Tiefere Reasoning-Tasks, Long-Form-Content. Nur als Batch-Job, nicht in interaktiven Pfaden. Beispiel: "Schreibe Blogpost zu Thema X aus diesen Studien."

Stufe 4 — Cloud-LLM (Kimi K2, Codex, Claude): Wenn lokale Modelle nicht reichen (Komplexität) oder zu langsam sind (Echtzeit-Bedarf). Token-Verbrauch aus deinen Abos. Beispiel: "Generiere Sylke-Format-Script aus diesen 47 Erfahrungsberichten und Dartsch-Studien."

Eskalations-Regeln:

Warum diese Pyramide

Auf eurer Hardware ist jeder LLM-Call ein Ressourcen-Aufwand. Wenn du blind Stufe 4 für alles nimmst, sind die Cloud-Quotas schnell erschöpft. Wenn du blind Stufe 3 für alles nimmst, ist das System dauerausgelastet. Die Pyramide stellt sicher dass die richtige Werkzeug-Größe für jede Aufgabe genutzt wird.

---

Teil 8 — Die Hauptanwendungsfälle

Anwendungsfall 1: Email-Eingang verarbeiten

Eine Email kommt rein. Was passiert?


Email an info@viaviva.team / info@hochfrequenz.tech / etc.
  → Mailcow empfängt
  → IMAP-Push an n8n
  → n8n-Workflow "email-handling" startet
  → qwen3:1.7b klassifiziert: Spam? Frage? Bestellung? Antwort? Auftrag?
  → Bei Spam: ignorieren, in Spam-Ordner verschieben
  → Bei Auftrag-Versuch: Auto-Reply "Aufträge nur via Telegram"
  → Bei Bestellung: Weiterleitung an Rechnungs-Verantwortlichen
  → Bei Frage:
      pgvector-Suche in Q+A-Wiki
      Match > 0.85 und vertraut: Auto-Send + Telegram-Info
      Match unsicher: Cloud-LLM Draft → Telegram-Approval
  → Eintrag in Chatwoot als Ticket
  → Eintrag in Perfex (bei GFKB-Kunden auch in Perfex-GFKB)

Vorteile gegenüber dem alten Setup:

Anwendungsfall 2: Newsletter versenden

Du via Telegram: "Newsletter Donnerstag 19 Uhr an HF-Mitglieder zum Thema Vagusnerv"


Telegram → n8n-Workflow "newsletter-create"
  → Outline-Eintrag in /auftrage/inbox/ wird erstellt
  → Cloud-LLM (Kimi K2) lädt:
      - HF-Brand-Voice-Wiki
      - HF-Compliance-Tabu-Wiki
      - Bestehende Newsletter-Beispiele aus Outline
      - Dein Briefing
  → Generiert Newsletter-Draft
  → Schickt dir Draft via Telegram
  → Du: Approve / Edit / Reject
  → Bei Approve: Listmonk-Campaign erstellen
      - Empfänger-Segment: HF-Mitglieder
      - Schedule: Donnerstag 19 Uhr
  → Folgetag: n8n holt Open-Rate, Click-Rate aus Listmonk
  → Telegram-Report an dich
  → Outline /auftrage/erledigt/ Eintrag mit Lessons-Learned

Anwendungsfall 3: Schlafstudie-Tagesfrage

Cron 8:00 Uhr Asuncion-Zeit:


n8n-Cron "schlafstudie-daily-question"
  → SELECT * FROM studienteilnehmer WHERE active = true
  → Pro Teilnehmer:
      - Welcher Wochentag? Welche Frage steht heute an?
      - Telegram/WhatsApp via Bot-API
      - Mit Inline-Buttons: [😴 1] [😐 2] [🙂 3] [💤 5]
  → Antworten landen via Webhook in n8n
  → INSERT INTO studienantworten ...
  → Wenn-Dann-Logik:
      - Antwort = 1 oder 2 → Folgefrage "Was glaubst du war der Grund?"
      - Spezielle Antworten → an dich eskalieren
  → Quartalsweise: Cloud-LLM analysiert Studien-Daten, generiert Report

Hier ist NULL LLM im Standard-Workflow. Erst bei Quartals-Auswertung kommt Cloud-LLM ins Spiel.

Anwendungsfall 4: Lead-Recherche für Universitäten

Telegram: "Recherchiere 10 Lehrstühle für Biophysik in DACH"


n8n-Workflow "lead-recherche-uni"
  → Cloud-LLM (Kimi) bekommt Aufgabe + SearXNG-API
  → SearXNG-Suche: "Lehrstuhl Biophysik Universität site:de OR site:at OR site:ch"
  → Browser-Use besucht Top 30 Treffer
  → Extrahiert: Lehrstuhlname, Professor, Email, Forschungsgebiet
  → Cloud-LLM filtert: welche 10 sind am relevantesten für HF-Thema?
  → Telegram an dich: "10 Vorschläge mit Kontext, soll ich Anschreiben drafter?"
  → Bei Approval: Cloud-LLM generiert personalisiertes Anschreiben pro Lead
  → Telegram: 10 Drafts zum Review
  → Versand mit Throttling (max 3 pro Tag)
  → Tracking in Postgres + Perfex
  → Bei Antwort: Chatwoot-Ticket + Telegram-Alert an dich

Anwendungsfall 5: WordPress-Pflege via Plugin v2

Cron wöchentlich:


n8n-Workflow "wp-maintenance"
  → Plugin v2 API auf hochfrequenz.tech
  → /backup → erstellt Backup
  → /plugins → checkt verfügbare Updates
  → Pro Update:
      - Backup-ID merken
      - Update durchführen
      - /health → check ob alles ok
      - Bei Fehler: Auto-Rollback aus Backup
  → /seo/score → liefert Optimierungsvorschläge
  → /performance → Lighthouse-Scan
  → Wochenreport an dich via Telegram

---

Teil 9 — Was die HF-spezifischen Workflows sind

Hochfrequenz ist die mit Abstand komplexeste Marke und hat eigene Pipeline-Anforderungen.

HF-Content-Pipeline (Sylke + Investigativ-Format)

Das ist der größte Workflow-Komplex. Eingang: ein Krankheitsbild aus deiner Liste. Output: ein Großvideo plus Hochformat-Shorts.


Auftrag in Outline: "Erstelle Sylke-Format-Video für Migräne"
  → Cloud-LLM (Kimi/Codex) lädt:
      - HF-Brand-Voice-Wiki
      - Klassifizierte Migräne-Erfahrungsberichte aus Postgres
      - Dartsch-Studien zu Migräne aus Wiki
      - Video-Schablonen-Wiki (Sylke-Format-Struktur)
  → Generiert Script (8 Szenen, je mit Voice-Over-Text und Asset-Tags)
  → Telegram an dich: Script-Draft
  → Du editierst auf finale Version
  → Voice-Over-Aufnahme:
      - Deine Frau spricht Script ein (Audacity)
      - Auto-Editor bereinigt Stille
      - Pro Szene ein Audio-File
  → Asset-Generation:
      - Servier-Medical-Art-SVGs aus lokaler Library
      - Linien-Skizzen via lokaler Stable-Diffusion + HF-Style-LoRA
      - Stock-Sound aus Freesound
  → Remotion-Pipeline:
      - JSON-Konfig mit Szenen-Komponenten und Props
      - Render zu MP4
  → Telegram an dich: Vorschau-Video
  → Du: Approve / Re-Render einzelne Szenen
  → Bei Approve:
      - YouTube-Upload via Data-API mit Title, Description, Timestamps
      - 4 Hochformat-Shorts extrahieren (FFmpeg-Crop + Untertitel)
      - Cross-Posting via Mixpost
      - Eintrag in Outline /erledigt/ mit Lessons-Learned
  → Plus: Investigativ-Pendant zum gleichen Krankheitsbild als Folge-Format

HF-Member-App (HF-Universum)

Member-App auf SvelteKit unter app.hochfrequenz.tech:

Diese App wird der zentrale Conversion-Punkt für HF. Alle Wege führen dorthin.

Schlafstudie-Workflow (siehe oben)

Der WhatsApp/Telegram-getriebene Workflow ist die Erstaufnahme. Member in der App sehen das visuell mit Verlaufs-Anzeige. Quartalsweise generiert Cloud-LLM einen Studien-Report aus den anonymisierten aggregierten Daten.

---

Teil 10 — Die GFKB-Integration als Sonderfall

GFKB-Workflows haben strukturell eine zusätzliche Anforderung: alles muss seine Spuren in Perfex-GFKB hinterlassen, nicht nur in Perfex-Viaviva.

Beispiel: Newsletter für GFKB


Telegram: "Newsletter zu Krisenvorsorge-Update an alle GFKB-Mitglieder"
  → n8n-Workflow "gfkb-newsletter"
  → Cloud-LLM lädt GFKB-Brand-Voice + GFKB-Compliance-Wiki
  → Draft, Approval-Loop
  → Versand via Listmonk auf Hostinger (mit @gfkb.org-Absender via Mailcow)
  → Nach Versand:
      - Perfex-Viaviva: Eintrag "GFKB-Newsletter ausgeführt am X" (kurz)
      - Perfex-GFKB API: vollständiger Newsletter-Eintrag mit:
        - HTML-Inhalt als Anhang
        - Empfängerliste
        - Versandzeitpunkt
        - Open/Click-Daten als Nachtrag

Bei Trennung der Partnerschaft kann GFKB in Perfex-GFKB die komplette Newsletter-Historie sehen, die Inhalte herunterladen, und nahtlos das Perfex-Newsletter-Modul oder einen anderen Anbieter weiternutzen.

Datenfluss-Regel für GFKB

Master-Daten leben immer auf All-Inkl in Perfex-GFKB. Hostinger arbeitet mit ephemeren Verarbeitungs-Kopien.

Konkret:

AVV (Auftragsverarbeitungsvertrag)

Bevor produktive GFKB-Daten auf Hostinger verarbeitet werden, brauchen wir einen schriftlichen AVV zwischen dir und GFKB. Das ist DSGVO-Pflicht und keine Formalität.

---

Teil 11 — Die Bauphasen

Die Reihenfolge ist nicht zwingend linear, aber Phase A ist Voraussetzung für alle weiteren.

Phase A — Stabilisierung und Migration

Phase B — Stack-Foundation auf Hostinger

Phase C — Plugin v2 und erste WP-Automation

Phase D — Astro-Komponenten-Library

Phase E — Member-App (HF-Universum)

Phase F — Video-Pipeline

Phase G — GFKB-Integration

Phase H — Lead-Recherche und Marketing-Skalierung

---

Teil 12 — Was bewusst NICHT gebaut wird

Damit es im Konzept klar bleibt:

Vollautomatische Forenkommentare oder Reddit-Outreach. Bot-Detection ist heute gut, Account-Bans sind real, Brand-Schaden ist möglich. Stattdessen: Listening (was wird wo geschrieben) + manuelles Drafting + manuelle Posts mit deinem Account. Browser-Use unterstützt beim Login, postet nicht autonom.

Echtzeit-Telefonbot. Inferenz-Latenz auf CPU-only zu hoch. Wenn Telefon-Support nötig: Mensch.

Live-Chat in der Member-App. Wartungsaufwand zu hoch für eine Person. Stattdessen: asynchroner Email-Support mit kurzer SLA und Q+A-Wiki-System.

Eigener WordPress-Pagebuilder. Wäre ein eigenes Software-Projekt mit hohem Wartungsaufwand. Stattdessen: Astro für neue Sites, Plugin v2 für existierende WP-Sites die nicht anders zu betreiben sind (GFKB).

Vollautomatisierte App-Store-Apps. Web-App als Standard. Native App nur wenn sich zeigt dass sie wirklich genutzt wird.

14B-Modell in interaktiven Workflows. Zu langsam auf CPU. Nur als Batch-Job für Spezialfälle.

---

Teil 13 — Eskalations-Pfade und Notfall-Verhalten

Was passiert wenn Cloud-LLM-Quota erschöpft ist

n8n-Workflow versucht Cloud-LLM-Call → Fehler (Rate-Limit, Quota erschöpft) → Fallback auf nächst-niedrigere Stufe (Cloud-Alternative oder lokales qwen3:14b als Batch) → Bei Long-Form-Tasks: Auftrag in /auftrage/wartet-auf-mensch/ mit Hinweis "Cloud-Quota erschöpft, manuelle Bearbeitung empfohlen" → Telegram-Info an dich

Was passiert wenn lokales Modell hängt

Uptime-Kuma erkennt: Ollama-Container nicht responsive → Telegram-Alert an dich → Auto-Heal-Versuch: Container restart → Bei Erfolg: Hinweis "auto-healed", System läuft weiter → Bei Fehlschlag: Eskalation, manuelle Investigation nötig

Was passiert wenn ein Workflow falsche Antworten produziert

Du erkennst es entweder:

Bei letzterem: Workflow wird in /auftrage/inbox/ mit Tag "fehlerhaft" angelegt, du arbeitest mit Claude Code an Korrektur, Q+A-Wiki-Eintrag wird in confidence_threshold heraufgesetzt sodass dieser Eintrag nicht mehr auto-genutzt wird.

Was passiert wenn das System unter Last zusammenbricht

Uptime-Kuma erkennt: zu viele Container-Failures, Server-Load-Average hoch → n8n-Workflow "emergency-throttle" startet → Pausiert nicht-kritische Cron-Jobs → Reduziert Worker-Count → Telegram-Alert: "System unter Last, throttled" → Du entscheidest manuell: weiter throttlen oder skalieren

---

Teil 14 — Was noch ungeklärt ist

Diese Punkte muss du beantworten bevor wir mit der Umsetzung weitergehen können:

1. AVV mit GFKB: ist der schon gemacht oder muss er noch erstellt werden? Ich kann eine Vorlage entwerfen aber das geht in die GFKB-Integration-Phase.

2. App-Store-Plan für Member-App: Web-App als Standard, aber ob (und wann) der Schritt zur nativen App erfolgen soll, hat Implikationen auf die Architektur (Capacitor? Tauri? PWA?).

3. Voice-Recording-Setup deiner Frau: Mikrofon-Auswahl, Aufnahme-Disziplin, ihre tatsächliche Bereitschaft. Hat Auswirkung auf Phase F.

4. Hochfrequenz-Compliance-Anwalt: vor produktiver Video-Veröffentlichung sollte einmal ein Fachanwalt für Medizinwerberecht das Format prüfen. Ist das eingeplant?

5. Petitions-Plattform: echte Petition oder eigene Lösung in der Member-App? OpenPetition.de? Eigene Implementation?

6. Studien-Aggregation und Veröffentlichung: wie sollen die Schlafstudien-Daten am Ende publiziert werden? Eigenes Whitepaper? Hörbuch-Material? Wissenschaftliche Veröffentlichung?

7. Hardware-Upgrade-Schwelle: klare Trigger definieren ab welcher Member-Last oder Video-Pipeline-Aktivität ein GPU- oder Server-Upgrade gemacht wird.

8. Backup-Strategie für Production: in der jetzigen Phase reicht "manuell + VPS-Snapshot". Im Produktiv-Betrieb braucht es automatisierte tägliche Backups mit Off-Site-Sicherung.

---

Teil 15 — Wie dieses Dokument als Basis dient

Wenn wir dieses Konzept als finalisiert betrachten, geschieht folgendes:

1. Dokument wird in Outline abgelegt unter /wiki/system/architektur-foundation.md. Das ist die zentrale Wahrheit gegen die alle künftigen Entscheidungen geprüft werden.

2. Pro Phase wird ein konkretes Auftragsdokument für Claude Code erstellt das auf dieses Foundation-Dokument verweist und die spezifischen Schritte für die Phase definiert.

3. Bei Bauarbeiten prüft Claude Code immer: "passt das was ich baue zur Foundation?" Wenn nein, Rückfrage an dich.

4. Lessons-Learned aus jeder Phase fließen zurück in das Foundation-Dokument als Updates.

---

Schluss-Bemerkungen

Das hier ist die zweite große Iteration eines Konzepts das aus monatelanger Arbeit gewachsen ist. Die ehrlichen Stärken:

Die ehrlichen Schwächen:

Wenn du beim Lesen Punkte siehst die anders entschieden werden sollen, oder die unklar sind, oder die fehlen — markiere sie. Wir arbeiten dann nach.

Wenn das Konzept passt, fangen wir mit Auftrag #001 (System pausieren + Backup) an, danach folgt die GoDaddy-Migration als großer Block, und dann kommt Phase B (Stack-Foundation) als erstes echtes Bau-Projekt.

---

Ende des Konzept-Dokuments. Bitte zur Auswertung lesen.