# Portabilität: UNIVERSAL
# Version: 1.0.0
# Zuletzt validiert: 2026-02-17 (Claude Opus 4.6)
# Nächste Prüfung: 2026-08-17
# Ressourcen: [Multi-LLM-Protocol, Bridge, Schwarm-System, Claude Code Docs]

LLM-KOMMUNIKATION -- ÜBERBLICK ALLER METHODEN
================================================

Stand: 2026-02-17
Kontext: Wie können LLM-Instanzen (Claude, Gemini, Ollama) miteinander
         und mit der Aussenwelt kommunizieren? Katalog aller bekannten
         Methoden, bewertet nach Eignung für verschiedene Szenarien.

21 KOMMUNIKATIONSFORMEN
========================

HINWEIS: 15 generische Methoden (1-15) + 6 BACH-spezifische (16-21).
Die generischen Methoden sind auf jedes LLM-System übertragbar.
Die BACH-spezifischen nutzen BACHs eigene Infrastruktur.

1. DATEIEN HINTERLASSEN (Drop-File)
-----------------------------------
   Methode:    LLM schreibt Datei, anderes LLM liest sie später
   Richtung:   Unidirektional (Schreiber -> Leser)
   Latenz:     Hoch (Leser muss aktiv prüfen)
   Beispiel:   Agent schreibt ergebnis.txt, nächster Agent liest sie
   Stärke:    Einfachst mögliche Methode, keine Infrastruktur nötig
   Schwaeche:  Kein Benachrichtigungsmechanismus, Timing-Probleme
   BACH:       Grundlegende Methode in vielen Workflows

2. MEMORY.md (Gemeinsam geteilte Datei)
----------------------------------------
   Methode:    Alle LLM-Partner lesen/schreiben dieselbe MEMORY.md
   Richtung:   Bidirektional (alle lesen und schreiben)
   Latenz:     Session-basiert (Änderungen wirken ab nächster Session)
   Beispiel:   Claude schreibt Lesson Learned, Gemini liest es nächste Session
   Stärke:    Automatisch injiziert bei Session-Start (Claude Code)
   Schwaeche:  200-Zeilen-Limit, keine Echtzeit, manuell gepflegt
   BACH:       Aktuell je eine pro Partner; SQ043 plant gemeinsame Memory-DB

3. GEMEINSAMES GEDAECHTNIS (Datenbank)
---------------------------------------
   Methode:    Zentrale DB (bach.db) in die alle schreiben/lesen
   Richtung:   Bidirektional, Multi-Party
   Latenz:     Sofort (bei DB-Zugriff innerhalb einer Session)
   Beispiel:   Agent speichert Fact, anderer Agent fragt Facts ab
   Stärke:    Strukturiert, durchsuchbar, gewichtet, persistent
   Schwaeche:  Braucht DB-Zugriffs-Handler, nicht automatisch injiziert
   BACH:       facts, lessons, context_triggers in bach.db (890+ Einträge)

4. INJEKTOREN ALS KOMMUNIKATION
---------------------------------
   Methode:    System-Reminders werden in den Nachrichtenstrom injiziert
   Richtung:   System -> LLM (unidirektional)
   Latenz:     Sofort (bei nächster Nachricht)
   Beispiel:   Hook injiziert Nachricht via hook_additional_context
   Varianten:
     a) Claude Code Injektoren (52 Typen, nicht steuerbar)
     b) BACH Injektoren (5 Typen, LLM-steuerbar)
     c) Hook-basiert (UserPromptSubmit liest "Inbox"-Datei)
   Stärke:    Erscheint im Kontext ohne aktives Abrufen
   Schwaeche:  CC-Injektoren nicht vom User/LLM kontrollierbar
   BACH:       ContextInjector, SessionInjector, PartnerInjector,
               HealthInjector, SpendenInjector
   Siehe auch: claude-code-injections.txt, injectors.txt

5. STIGMERGY / KARTE DES RUMTREIBERS
--------------------------------------
   Methode:    Agenten hinterlassen Marker-Dateien (Pheromone)
               Andere Agenten lesen die Marker und passen Verhalten an
   Richtung:   Indirekt bidirektional (über Umgebung)
   Latenz:     Sofort (File-System)
   Beispiel:   Bot schreibt .visited.log, andere meiden besuchte Bereiche
   Marker:     .done, .in_progress, .visited.log, .counter, .flag
   Stärke:    Keine direkte Kommunikation nötig, skaliert gut
   Schwaeche:  Keine Garantie dass Marker gelesen wird, Verdunstung nötig
   BACH:       data/swarm/map/, maintenance_swarm.py, marauders_map.py
   Siehe auch: trampelpfadanalyse.md (Kapitel 2: Schwarm-Verfahren)

6. HANDOFF-DATEIEN (Explizite Übergabe)
------------------------------------------
   Methode:    Strukturiertes Übergabedokument zwischen Instanzen
   Richtung:   Unidirektional (Vorgaenger -> Nachfolger)
   Latenz:     Sofort (Datei wird vor Start des Nachfolgers geschrieben)
   Beispiel:   Marble-Run: handoff.md mit Task, Status, Ergebnis, Feedback
   Stärke:    Volle Kontextweitergabe, strukturiert, nachvollziehbar
   Schwaeche:  Nur für serielle Ketten, nicht für parallele Kommunikation
   BACH:       tools/llmauto/state/handoff.md (Murmelbahn-Pipeline)

7. BRIDGE / CONNECTORS (Externe Kanaele)
------------------------------------------
   Methode:    BACH sendet/empfaengt Nachrichten über externe Dienste
   Richtung:   Bidirektional (BACH <-> Mensch/anderes System)
   Latenz:     Sekunden (abhängig vom Dienst)
   Beispiel:   User schreibt Telegram-Nachricht, BACH antwortet
   Kanaele:    Telegram (Beta), Discord (Beta), HomeAssistant (Beta),
               Signal (geplant), WhatsApp (geplant)
   Stärke:    Kommunikation mit der realen Welt, nicht nur LLM-zu-LLM
   Schwaeche:  Abhängig von externen APIs, Scraping-basiert bei manchen
   BACH:       connectors/, hub/connector.py, Bridge-System
   Siehe auch: bridge.txt, connectors.txt

8. CLAUDE CODE TEAM-MODUS
---------------------------
   Methode:    Eingebaute Team-Koordination in Claude Code CLI
   Richtung:   Bidirektional (Leader <-> Teammates)
   Latenz:     Sofort (Message-Queue innerhalb der Session)
   Beispiel:   Team-Lead sendet Aufgabe an Researcher, bekommt Ergebnis
   Features:   SendMessage, TaskList, TaskCreate, TaskUpdate, Broadcast
   Stärke:    Anthropic-native, gut integriert, parallele Arbeit
   Schwaeche:  Nur innerhalb einer Claude Code Session, kein Opus/Sonnet-Mix
   BACH:       Nicht direkt integriert (Claude Code Feature, nicht BACH)

9. GIT ALS KOMMUNIKATION
--------------------------
   Methode:    Commits + Commit-Messages als Nachrichten zwischen Instanzen
   Richtung:   Bidirektional (Push/Pull)
   Latenz:     Minuten (Commit + Push + Pull)
   Beispiel:   Worker committed Änderung, Reviewer liest git diff + Message
   Stärke:    Versioniert, nachvollziehbar, Standard-Tooling
   Schwaeche:  Overhead für kleine Nachrichten, braucht Repo
   BACH:       Nicht systematisch genutzt, aber möglich (SQ020 Versionierung)

10. DB-TABELLEN ALS KANAL
---------------------------
    Methode:    Agenten schreiben in gemeinsame DB-Tabelle, andere lesen
    Richtung:   Bidirektional, Multi-Party
    Latenz:     Sofort (innerhalb einer Session bei DB-Zugriff)
    Beispiel:   Agent schreibt Nachricht in messages-Tabelle, Empfaenger pollt
    Stärke:    Strukturiert, persistent, durchsuchbar, bereits vorhanden
    Schwaeche:  Polling nötig (kein Push), braucht Handler
    BACH:       bach.db hat Infrastruktur, aber kein explizites Message-System

11. HOOKS (Event-basierte Injektion)
--------------------------------------
    Methode:    Shell-Kommando wird bei Event ausgeführt, Ergebnis injiziert
    Richtung:   Extern -> LLM (unidirektional pro Hook-Aufruf)
    Latenz:     Sofort (bei jedem User-Prompt oder Tool-Call)
    Beispiel:   UserPromptSubmit-Hook liest "Inbox"-Datei und injiziert Inhalt
    Hook-Typen: PreToolUse, PostToolUse, SessionStart, UserPromptSubmit, etc.
    Stärke:    Einfachster Weg für Inter-Instanz-Messaging ohne Source-Patch
    Schwaeche:  Nur bei Events (nicht on-demand), Hook-Konfiguration nötig
    BACH:       Empfohlener Ansatz für Claude Code Integration
    Siehe auch: claude-code-injections.txt (Abschnitt "Messaging-System")

12. MCP-SERVER ALS VERMITTLER
-------------------------------
    Methode:    Gemeinsamer MCP-Server den mehrere LLM-Instanzen nutzen
    Richtung:   Bidirektional (alle Instanzen rufen gleichen Server auf)
    Latenz:     Sofort (Tool-Call)
    Beispiel:   ellmos-codecommander-mcp als Shared-Service für alle Claude-Instanzen
    Stärke:    Standardisiert (MCP-Protokoll), tool-basiert, erweiterbar
    Schwaeche:  Server muss laufen, kein Push-Mechanismus
    BACH:       ellmos-codecommander-mcp (14 Tools), ellmos-filecommander-mcp (38 Tools)

13. PROCESS-CHAINING (.bat als Signal)
----------------------------------------
    Methode:    Ein Prozess startet den nächsten via Batch-Datei
    Richtung:   Unidirektional (Vorgaenger -> Nachfolger)
    Latenz:     Sofort (Prozess-Start)
    Beispiel:   Marble-Run: Opus Worker beendet sich, .bat startet Sonnet Reviewer
    Stärke:    Deterministisch, keine Infrastruktur, BS-nativ
    Schwaeche:  Nur serielle Ketten, kein Feedback-Kanal (braucht Handoff-Datei)
    BACH:       tools/llmauto/ (llmauto-CLI) (Murmelbahn-System)

14. SHARED FILESYSTEM (File-Watcher)
--------------------------------------
    Methode:    Agenten überwachen gemeinsames Verzeichnis auf Änderungen
    Richtung:   Bidirektional (alle können schreiben/lesen)
    Latenz:     Sekunden (Polling-Intervall des Watchers)
    Beispiel:   Agent schreibt neue_aufgabe.json, Watcher erkennt und reagiert
    Stärke:    Einfach, keine spezielle Infrastruktur
    Schwaeche:  Polling-basiert, Race Conditions möglich, OneDrive-Sync-Probleme
    BACH:       Grundsaetzlich möglich, nicht systematisch implementiert

15. STDOUT/STDIN-PIPING
-------------------------
    Methode:    Ausgabe eines Prozesses wird direkt zur Eingabe des nächsten
    Richtung:   Unidirektional (Producer -> Consumer)
    Latenz:     Sofort (Pipe)
    Beispiel:   claude --print "Analysiere X" | claude --print "Bewerte: $(cat -)"
    Stärke:    Unix-Philosophie, minimaler Overhead, kein Dateisystem nötig
    Schwaeche:  Nur Text, kein strukturierter Kontext, keine Persistenz
    BACH:       Nicht genutzt (Claude Code unterstützt --print aber kein stdin-Pipe)

BACH-SPEZIFISCHE KOMMUNIKATIONSFORMEN (16-21)
===============================================

16. MULTI-LLM-PROTOKOLL V3 (Presence + Locking)
-------------------------------------------------
    Methode:    Presence-Dateien + Lock-Dateien + Handshake im Dateisystem
    Richtung:   Bidirektional, Multi-Party
    Latenz:     Sekunden (Heartbeat alle 30s, Timeout 120s)
    Beispiel:   Claude erkennt dass Gemini online ist via .gemini_presence
    Features:   Presence, Locking, Handshake, Heartbeat, Agent-Detection
    Bekannte:   claude, gemini, copilot, ollama, perplexity, mistral-watcher
    Stärke:    Koordination ohne zentrale Instanz, Race-Condition-sicher
    Schwaeche:  Dateisystem-basiert (langsamer als DB), Stale-Presence möglich
    BACH:       hub/multi_llm_protocol.py (V3), CLI: bach llm presence/check/lock

17. PARTNER-PRESENCE DB (Stempelkarten)
----------------------------------------
    Methode:    SQLite-Tabelle partner_presence mit clock_in/out/heartbeat
    Richtung:   Bidirektional (jeder meldet sich an/ab)
    Latenz:     Sofort (DB-Abfrage)
    Beispiel:   bach llm status -> zeigt wer online ist und was er tut
    Features:   clock_in(), clock_out(), heartbeat(), get_online_partners()
    Stärke:    Zuverlaessiger als Dateien, persistenter Status
    Schwaeche:  Braucht DB-Zugriff, nicht dateisystem-kompatibel
    BACH:       hub/multi_llm_protocol.py (PartnerPresenceDB Klasse)

18. NACHRICHTEN-SYSTEM (INBOX/OUTBOX)
--------------------------------------
    Methode:    DB-basiertes Messaging mit sender, recipient, body, status
    Richtung:   Bidirektional, gerichtet (Empfaenger bestimmt)
    Latenz:     Sofort (bei Abfrage) oder Polling (Watch-Modus alle 10s)
    Beispiel:   bach msg send gemini "Analysiere dieses Bild"
    Features:   Send, Read, Watch (Polling), Ping, Lesebestaetigung (--ack)
    Status:     unread, read, archived
    Stärke:    Strukturiert, persistent, durchsuchbar, Lesebestaetigung
    Schwaeche:  Pull-basiert (kein Push), braucht aktives Polling
    BACH:       hub/messages.py, DB-Tabelle: messages

19. BENACHRICHTIGUNGS-SYSTEM (Multi-Channel Push)
--------------------------------------------------
    Methode:    Ausgehende Benachrichtigungen über externe Kanaele
    Richtung:   Unidirektional (BACH -> Extern)
    Latenz:     Sekunden
    Kanaele:    Discord (Webhook), Telegram (Bot API), Slack (Webhook),
                Email (SMTP/SSL), Signal (Direct), Generic Webhook
    Beispiel:   bach notify send telegram "Task erledigt"
    Stärke:    Multi-Channel, konfigurierbar
    Schwaeche:  Nur ausgehend (kein Empfang über notify)
    BACH:       hub/notify.py, CLI: bach notify setup/send/test/list

20. QUEUE PROCESSOR & SMART ROUTER
------------------------------------
    Methode:    Zuverlaessiges Routing von Connector-Nachrichten
    Richtung:   Bidirektional (Connector <-> BACH intern)
    Latenz:     Sekunden (Poll-Intervalle: Telegram 15s, Discord 60s)
    Features:   Retry/Backoff (5 Stufen: 30s-480s), Circuit Breaker (5 Fehler)
    Smart:      Parst Commands aus Nachrichten ("/task add Test")
    Stärke:    Zuverlaessig, selbstheilend, Command-Erkennung
    Schwaeche:  Komplex, braucht laufenden Daemon
    BACH:       hub/_services/connector/queue_processor.py, smart_router.py

21. GEMINI DELEGATION PROTOCOL
--------------------------------
    Methode:    Task-Dateien in gemini/inbox/, Ergebnisse in gemini/outbox/
    Richtung:   Bidirektional (Claude -> Gemini und zurück)
    Latenz:     Minuten bis Stunden (manuell oder via Google Drive Sync)
    Trigger:    Keyword, Token-Budget, Dokument-Laenge, explizit
    Beispiel:   Claude erstellt Research-Task, Gemini arbeitet ab, Ergebnis zurück
    Stärke:    Nutzt Geminis Stärken (grosse Dokumente, Bilder)
    Schwaeche:  Manueller Transfer nötig (oder Google Drive Sync)
    BACH:       skills/workflows/gemini-delegation.md

VERGLEICHSMATRIX
=================

  Methode              | Richtung | Latenz   | Persistenz | Skalierung | Komplexitaet
  ---------------------|----------|----------|------------|------------|-------------
  GENERISCH (übertragbar auf jedes LLM-System):
  1  Drop-File         | Uni      | Hoch     | Ja         | Gut        | Minimal
  2  MEMORY.md         | Bi       | Session  | Ja         | Begrenzt   | Gering
  3  Gemeinsame DB     | Multi    | Sofort   | Ja         | Sehr gut   | Mittel
  4  Injektoren        | Uni      | Sofort   | Nein       | Begrenzt   | Mittel
  5  Stigmergy         | Indirekt | Sofort   | Ja (TTL)   | Sehr gut   | Mittel
  6  Handoff-Dateien   | Uni      | Sofort   | Ja         | Seriell    | Gering
  7  Bridge/Connectors | Bi       | Sekunden | Ja         | Gut        | Hoch
  8  Team-Modus        | Bi       | Sofort   | Session    | Parallel   | Mittel
  9  Git               | Bi       | Minuten  | Ja         | Gut        | Mittel
  10 DB-Tabellen       | Multi    | Sofort   | Ja         | Sehr gut   | Mittel
  11 Hooks             | Uni      | Event    | Nein       | Begrenzt   | Gering
  12 MCP-Server        | Bi       | Sofort   | Variabel   | Gut        | Hoch
  13 Process-Chaining  | Uni      | Sofort   | Nein       | Seriell    | Gering
  14 File-Watcher      | Bi       | Sekunden | Ja         | Gut        | Mittel
  15 Stdout-Piping     | Uni      | Sofort   | Nein       | Seriell    | Minimal

  BACH-SPEZIFISCH (nutzt BACH-Infrastruktur):
  16 Multi-LLM-Prot.   | Multi    | 30s      | Ja         | Gut        | Mittel
  17 Partner-Presence   | Multi    | Sofort   | Ja         | Gut        | Mittel
  18 Nachrichten-Sys.   | Bi       | Sofort   | Ja         | Gut        | Mittel
  19 Notify (Push)      | Uni      | Sekunden | Ja         | Multi-Ch.  | Mittel
  20 Queue/Router       | Bi       | Sekunden | Ja         | Gut        | Hoch
  21 Gemini-Delegation  | Bi       | Minuten  | Ja         | Begrenzt   | Gering

EMPFEHLUNGEN NACH ANWENDUNGSFALL
==================================

  Anwendungsfall                    | Empfohlene Methode(n)
  ----------------------------------|---------------------------------------
  Schwarm (viele parallele Agenten) | 5 (Stigmergy) + 3 (DB) + 14 (Watcher)
  Serielle Pipeline (Marble-Run)    | 6 (Handoff) + 13 (Process-Chain)
  Team-Arbeit (2-5 Agenten)         | 8 (Team-Modus) oder 10 (DB-Tabellen)
  Langzeit-Wissenstransfer          | 2 (MEMORY.md) + 3 (DB)
  Echtzeit-Benachrichtigung         | 4 (Injektoren) + 11 (Hooks)
  Kommunikation mit Aussenwelt      | 7 (Bridge/Connectors)
  Asynchrone Zusammenarbeit         | 1 (Drop-File) + 9 (Git)
  Toolbasierte Integration          | 12 (MCP-Server)

BACH-SPEZIFISCHE ARCHITEKTUR
==============================

BACHs Stärke ist die Kombination mehrerer Methoden:
- Bridge (7) für die Aussenwelt
- DB (3+10) als zentraler Wissensspeicher
- Injektoren (4) für proaktive Kontext-Anreicherung
- Stigmergy (5) für Schwarm-Operationen
- Handoff (6) + Process-Chaining (13) für Marble-Run-Pipelines

Im Gegensatz dazu ist Claude Code auf eine Methode pro Szenario beschränkt:
Team-Modus (8) ODER Injektoren (4), nicht kombinierbar.

BACH kann alle 15 Methoden gleichzeitig nutzen und dynamisch wechseln --
das ist der architektonische Vorteil eines LLM-zentrierten Systems.

SIEHE AUCH
===========
  bridge.txt                    Bridge/Connector-System
  connectors.txt                Connector-Typen im Detail
  injectors.txt                 BACH Injektor-System
  claude-code-injections.txt    Claude Code Injektions-Anatomie
  multi-llm.txt                 Multi-LLM-Protokoll
  schwarm.txt                   Schwarm-Operationen (falls vorhanden)
