Ping-Pong01
Erste Stufe: zwei Endpoints reichen eine Aufgabe hin und her, max-rounds als Bremse. Beweist den Cross-Device-Transport.
— Arbeitsprobe · Lab
Zwei Modelle, die sich gegenseitig prüfen.
dual-bridge ist ein verteiltes Agentensystem über zwei echte Maschinen: Claude baut, Codex reviewt — und umgekehrt. Jeder Schritt durchläuft ein adversariales Verdikt (accepted · rejected · escalate), bevor er zählt.
dual-bridge — Cross-Device-Brücke für sich selbst prüfende Agentenarbeit.
Cross-DeviceZwei ModelleAdversariales VerdiktAutonomer LoopEskalation
— Warum gebaut?
Verteilte Arbeit, die sich selbst prüft.
Der Ausgangspunkt war eine praktische Frage: Wie wird Agentenarbeit belastbar, wenn ein einzelnes Modell sich selbst nicht ausreichend kontrolliert? Ein Modell, das seinen eigenen Output bewertet, ist ein schwacher Prüfer.
dual-bridge verteilt die Arbeit deshalb über zwei echte Maschinen und zwei Modelle. Der Handoff läuft dateibasiert über getrennte Google-Drive-Lanes — kein gemeinsamer Server, kein geteilter Claim-Pool, kein Race zwischen den Geräten.
Das Ergebnis ist ein Loop, in dem das eine Modell baut und das andere adversarial prüft. Nichts wird übernommen, ohne dass die Gegenseite es freigegeben — oder bewusst an den Menschen eskaliert hat.
— Wachstum
Vier Stufen, vom Transport zur vollen Symmetrie.
Das System ist nicht in einem Stück entstanden, sondern in Stufen — jede beweist eine Fähigkeit mehr, von der reinen Übergabe bis zum vollständig symmetrischen Review.
Build-Review02
Ein Endpoint baut, der andere reviewt mit accept/reject — der erste echte adversariale Loop.
Goal-Loop03
Offenes Ziel + Done-Kriterien aus einem Seed. Läuft autonom, bis accepted — oder eskaliert bewusst an den Menschen.
Relay-Loop04
Builder und Reviewer rotieren; jedes Modell prüft das jeweils andere. Volle Symmetrie zwischen Claude und Codex.
— Cross-Device
Zwei Maschinen, eine Brücke.
Der Transport ist bewusst einfach gehalten: dateibasiert über eine geteilte Google-Drive-Ablage, mit zwei gerichteten Lanes. Keine offene Netzwerkverbindung zwischen den Geräten, kein gemeinsamer Server.
Zwei Lanes, zwei Claim-Pools: Jede Richtung hat ihre eigene Outbox. Ein Claim-Race zwischen den Geräten ist damit strukturell ausgeschlossen.
Identität über Hostname: Jede Maschine kennt ihre Rolle aus dem Hostnamen. Ein unbekannter Host ohne Override stoppt mit klarem Fehler — kein stiller Fallback.
— Adversariale Verifikation
Drei Verdikte — eines ruft den Menschen.
Jeder Build-Schritt endet mit einem von drei Verdikten der Gegenseite. Das dritte ist das wichtigste: das System eskaliert bewusst, statt riskant weiterzulaufen. Wähle ein Verdikt, um zu sehen, was es auslöst.
Der Loop stoppt und übergibt an den Menschen — bewusst, statt blind weiterzulaufen. Vier Trigger lösen das aus:
- dangerous_action
Diff-Scan (deny-first) erkennt force-push, DROP TABLE, rm -rf oder API-Keys → sofortiger Stopp.
- reviewer_requested
Der Reviewer fordert explizit einen menschlichen Eingriff statt eines Verdikts.
- stagnation
Gleicher Commit wie die Vorrunde — oder eine wortgleich wiederholte Begründung des Reviewers.
- max_rounds
Die maximale Rundenzahl ist erreicht, ohne dass je accepted erreicht wurde.
— Live bewiesen
Nicht behauptet — nachgefahren.
Die ungewöhnlichste Eigenschaft eines verteilten Loops ist nicht, dass er läuft — sondern dass er sich nach einer Eskalation am selben Branch fortsetzt. Genau das ist hier in echten Commits belegt.
479Tests
31Module
8.914Zeilen Kern
- ffa06de02.06.2026
Cross-Device-Ausführung bewiesen
Stage-2a: ein realer Commit, geschrieben vom Worker auf der Gegenmaschine — der Transport über die Lane funktioniert end-to-end (latency_probe.py).
- Eskalation · kein Commit02.06.2026
Bewusster Stopp am mehrdeutigen Kriterium
Der Reviewer fordert manuellen Eingriff statt blind weiterzubauen — eine ESCALATION-Datei wird geschrieben, der Loop hält an.
- 6ea94bc02.06.2026
Reseed-Resume mit Continuity
Nach geschärftem Seed läuft derselbe Branch fort und wird accepted (greet_util.py). Dass es derselbe Branch ist, ist hart über die Commit-Historie bewiesen.
Belege ground-truthed aus dem öffentlichen Repository · Stand 06/2026 · Commit-Hashes sind dort nachprüfbar
— Kontrolle als Design
Autonomie mit Sicherheitsnetz.
Ein System, das selbst baut und sich selbst mergt, braucht harte Grenzen — sonst ist Autonomie nur ein anderes Wort für unkontrolliert. dual-bridge zieht diese Grenzen explizit und fail-closed.
Dangerous-Action-Gate
Lokaler Diff-Scan (deny-first) auf force-push, DROP TABLE, rm -rf, API-Keys → sofortige Eskalation.
Secret-Gate
Vor jedem Schreiben in die Outbox: Token-Shapes + Shannon-Entropie ≥ 4.5 → Task blockiert.
Risk-Policy
Deklarative kind/adapter-Tabelle, fail-closed (R1/R2/R3). Kein stiller Override.
PID-Liveness
Prozess-Cmdline-Match gegen Marker erkennt recycelte fremde PIDs korrekt als stale.
Read-only Dashboard
Das Status-Cockpit schreibt nie — die Invariante ist im Code verankert.
— Übertragbare Muster
Was sich verallgemeinern lässt.
Nicht dual-bridge als Kopie, sondern die Entscheidungen dahinter — sie tragen auch in anderen Multi-Agent-Workflows.
/01
Adversariale Prüfung statt Selbstlob
Ein zweites Modell, das auf Ablehnung aus ist, fängt mehr als jede Selbstbewertung.
/02
Bewusste Eskalation statt blinder Autonomie
Der wertvollste Verdikt-Wert ist der, der den Menschen ruft, statt riskant weiterzulaufen.
/03
Getrennte Lanes statt geteiltem Pool
Richtungstrennung schließt eine ganze Klasse von Claim-Races strukturell aus.
/04
Fail-closed Gates
Unbekannt heißt blockiert, nicht durchgewunken — Sicherheit als Default, nicht als Nachgedanke.
— Sparring & Code
Welchen Teil der Brücke soll ich aufmachen?
Der Loop, die Eskalation, die Gates — wenn dich ein Mechanismus interessiert, schreib mir. Der Code liegt offen, ein Walkthrough ist jederzeit möglich.