# Cloud Communication Protocols
> Dach-Skill für Cloud-gestützte Kommunikationsprotokolle zwischen Agenten auf unterschiedlichen Maschinen (Ping-Pong, agent-beam, Listener und künftige Protokolle). Nutzen, wenn Arbeit über Maschinen hinweg per gemeinsamem Sync-Ordner oder Message-Yard koordiniert wird.
- Skill: `ellmos-ai/cloud-communication-protocols` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ellmos-ai/cloud-communication-protocols`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ellmos-ai/cloud-communication-protocols/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ellmos-ai (https://skillmd.com/u/ellmos-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ellmos-ai/cloud-communication-protocols
---
# cloud-communication-protocols
Familie von Protokollen, die zwei oder mehr Agenten auf unterschiedlichen
Maschinen über einen gemeinsamen, cloud-synchronisierten Ordner (den "Yard")
statt über einen direkten Kanal koordinieren lässt. Dieser Skill ist das
**Dach**: er sammelt die Protokolle, benennt, welches bewiesen ist, und
sperrt die, die noch Konzept sind.
## Wann nutzen
- Arbeit erstreckt sich über zwei oder mehr Maschinen (Verifikation,
gespiegelte Setups, Piloten) und es gibt keinen direkten
Agent-zu-Agent-Kanal.
- Ein gemeinsames Vokabular für Aufträge, Antworten, Takt und Eskalation
über diese Maschinen hinweg wird gebraucht.
## Protokolle dieser Familie
### 1. Ping-Pong (bewiesen, Basisprotokoll)
Zwei oder mehr Worker mit versetzten geplanten Scans überbrücken die
Cloud-Sync-Latenz: jede Seite scannt den Yard nach an sie adressierten
Aufträgen, führt aus, hinterlässt die Antwort und kann Folgeaufträge für
die andere Seite ausstellen.
Kernregeln: nur im eigenen Slot schreiben, Belege für jede Aktion,
Idempotenz, keine Geheimnisse im Yard (nur öffentliche Schlüssel/
Fingerprints/Pfade), kooperative Fehler-Deltas, Readback-über-Log-Verifikation.
**Takt: adaptive Poll-Frequenz.** Die Taktsteuerung ist nicht Teil der
Payload-Regeln des Basisprotokolls, aber jede Implementierung braucht sie —
ein fester Poll-Intervall flutet entweder einen leeren Yard oder verpasst
frische Arbeit. Zwei Mechanismen gelten und müssen beide behandelt werden,
nicht implizit bleiben:
- **A — Selbstjustierend (Standard, keine Operator-Eingabe; das
`cooldown`/Backoff-Muster).** Neuer Auftrag gefunden → direkt auf das
schnellste Intervall springen (z. B. 15 min). Leerer Lauf → auf einer
Leiter abkühlen: 4 aufeinanderfolgende leere Läufe → 30 min, 2 weitere →
1 h, danach jede weitere leere Serie verdoppeln (2 h, 4 h, 8 h) bis zu
einem harten Deckel (24 h, niemals höher). Den Leerlauf-Zähler und das
aktuelle Intervall in einer kleinen State-Datei beim Worker persistieren
(nicht im Konversationsgedächtnis), damit sie Neustarts überlebt; ein
Taktwechsel bedeutet, den alten geplanten Job zu löschen und einen neuen
im neuen Intervall anzulegen, Zähler übernommen. Vollständiges
Referenzschema, State-Datei-Schema und weitere Loop-Typen (Burst,
Wake-Assist): Begleit-Skill **`cron-tuner`**.
- **B — Peer-instruiertes Override.** Jede Seite darf den Takt der anderen
Seite explizit im Auftragstext setzen — `CADENCE: match 15m`, um auf ein
engeres Fenster zu synchronisieren, oder `CADENCE: pause 1h → 2h after 3
empty`, um eine Seite mit planbarer Kopf-runter-Arbeit zu verlangsamen.
Wer den Takt eines Peers ändert, bestätigt das neue Intervall im nächsten
Delta (Readback gilt auch für Uhren).
Beide Mechanismen ändern nur die Reaktionszeit, niemals die
Basisprotokoll-Regeln (Slot-Disziplin, Belege, keine Geheimnisse). Ein
gegenseitiger `WAKE: `-Kanal erlaubt Scans außerhalb des Zyklus als
Hinweis, niemals als Autorität; nach dem Lesen löschen.
Vollständige Spezifikation und Referenzbelege:
`dev-bricks/system-gap-master` → `docs/communications-protocols-skill.md`.
### 2. agent-beam (Konzept, gesperrt)
Für dringende Arbeit: ein Paket aus Prompt + Starter-Skript wird im
Ziel-Slot abgelegt, und ein Watcher auf der Zielmaschine startet damit
einen lokalen Agentenlauf — der Agent "landet" mit Auftrag und Starter und
beginnt sofort.
Gesperrt: benötigt einen signierten Starter-Vertrauensvertrag, einen
Quarantäne-/Review-Schritt und ausdrückliche Operator-Freigabe vor jeder
Aktivierung.
### 3. Listener / Ear-to-Ear-Listening (Konzept, gesperrt)
Watcher beobachten Trigger im Yard (Datei-Ankünfte, Flag-Dateien,
Registry-Änderungen) und starten Agenten auf der anderen Maschine.
"Ear-to-Ear": der Listener des einen Hosts beobachtet den Posteingang des
anderen Hosts.
Gesperrt: Debouncing-Regeln, Trigger-Whitelists je Slot und ein
Sicherheitsvertrag werden zuerst benötigt.
## Gemeinsame Invarianten (alle Protokolle)
- Der Yard ist Transport, niemals Arbeitsbereich und niemals
Geheimnis-Speicher.
- Jede Aktion hinterlässt einen verifizierbaren Beleg; "erledigt" ohne
Artefakt ist nicht erledigt.
- Fehlerbehandlung ist kooperativ: Fehler-Deltas mit Hypothese und
Gegentest, Zweitmeinungen willkommen.
- Abwesenheit eines Partners wird über die Vakanz-Regel der Plattform
behandelt (z. B. 48 h), nicht über Eskalation.
## Neue Protokolle hinzufügen
Neue Protokolle treten dieser Familie als Unterkapitel in
`communications-protocols-skill.md` bei (zuerst Konzept, mit eigenem
Sicherheitsvertrag und Belegen vor "bewiesen"). Hier mit je einer Zeile
listen: Name, Zustand (Konzept/Pilot/bewiesen), Zweck.