Rolle in der Werkstatt
Die Übergabe- und Review-Schicht der Werkstatt: Arbeit bekommt einen Besitzer, ein unabhängiges Verdikt und einen separat geprüften Zielzustand.
— Verteilte Agentenarbeit · Arbeitsprobe
Wie meine Agenten Arbeit übergeben
Dual Bridge, Build-Pipeline und Review zwischen Claude und Codex. Ich zeige, wie aus einem Auftrag eine gerichtete Übergabe, ein unabhängiges Verdikt und ein überprüfter Zielzustand werden.
Die wichtigste Trennung: Dass ein Agent fertig meldet, bedeutet noch nicht, dass seine Änderung reviewt, verifiziert oder übernommen wurde.
Arbeitszustände
- angenommen
- abgeschlossen
- reviewt
- verifiziert
- übernommen
Ehrliche Systemgrenze: Diese Leitseite verbindet mehrere eigenständige Bausteine zu einem zusammengesetzten Gesamtbild. Dual Bridge belegt den Cross-Device-Transport öffentlich. DCO, Orchestrated Bridge, Dream Team, Bridge Replay und Agent Observatory bleiben getrennte Systeme mit eigenem Reifegrad.
Zwei RechnerGerichtete ÜbergabeUnabhängiges ReviewBewusster StoppGround Truth
Zuletzt aktualisiert:
Jetzt prüfbar
- Öffentliches Repository: dynamic-dome/dual-bridge
- Verdikt-Mechanik: interaktive Demo auf dieser Seite
- Architektur & Kontrolllogik — hier dokumentiert
— Rollen-Transfer
Was diese Route in der Werkstatt beweist.
Hier zeige ich nicht nur einen Datei-Transport, sondern die Verantwortungen rund um eine belastbare Übergabe zwischen Agenten.
Transfer
Übertragbar sind gerichtete Lanes, explizite Zustände, getrennte Builder- und Reviewer-Rollen, Heartbeats (regelmäßige Lebenszeichen laufender Arbeit), Stop-Bedingungen und Ground-Truth-Prüfungen.
Öffentlicher Beleg
Der Cross-Device-Teil ist im öffentlichen Dual-Bridge-Repository und in zwei verlinkten Commit-Belegen nachvollziehbar; die Verdikt-Mechanik ist auf dieser Seite interaktiv.
Grenze
Die große Ablaufgrafik ist eine zusammengesetzte Stack-Sicht. Sie behauptet keine bereits vollständig verdrahtete Pipeline über alle genannten Systeme.
01Zustände statt Fertigmeldung
Zustände statt Fertigmeldung
Agent fertig ist kein Zielzustand
Dass ein Agent fertig meldet, bedeutet noch nicht, dass seine Änderung geprüft oder übernommen wurde. Ich trenne deshalb fünf Zustände, die in einfachen Agentenläufen oft zu einem einzigen Erfolgssignal zusammenfallen.
- 01
angenommen
Ein Agent oder Worker hat den Auftrag übernommen.
- 02
abgeschlossen
Der Builder meldet seinen Arbeitsschritt als fertig.
- 03
reviewt
Eine zweite Rolle hat den Diff und die Begründung geprüft.
- 04
verifiziert
Unabhängige Checks bestätigen den vereinbarten Zielzustand.
- 05
übernommen
Die Änderung ist tatsächlich im vorgesehenen Branch oder System angekommen.
Ein gutes Handoff-Protokoll zeigt nicht nur, wer gerade arbeitet. Es zeigt auch, welcher Nachweis noch fehlt.
02Dual Bridge
Dual Bridge
Vom Datei-Handoff zum Protokoll
Dual Bridge begann mit einer einfachen Übergabe zwischen zwei Rechnern. Belastbar wurde sie erst, als Richtung, Besitz, Verdikt und Fehlerzustände ausdrücklich Teil des Protokolls wurden.
Gerichteter Transport
Eine Lane führt von Rechner A nach B, eine zweite zurück. Dadurch teilen sich beide Seiten keinen Claim-Pool.
Nachvollziehbarer Lebenszyklus
Outbox, Inbox, verarbeitet und fehlerhaft bleiben als unterscheidbare Stationen erhalten.
Verdikt als Rückgabe
accepted, rejected und escalate beschreiben, wie der Builder mit dem Review weiterarbeiten darf.
Der öffentliche Beleg dieser Seite gehört zur Dual Bridge. Die weiter unten gezeigten Rollen und Nachbarsysteme erweitern die Arbeitsweise, ohne ihren Reifegrad auf diesen Prototyp zu übertragen.
03Verantwortung
Verantwortung
Rollen statt Modelllager
Claude und Codex sind für mich keine fest verdrahteten Abteilungen. Entscheidend ist die Verantwortung im jeweiligen Auftrag: planen, bauen, reviewen oder verifizieren.
/01Verantwortung
Planungsrolle
Aufgabe: zerlegt das Ziel, setzt Grenzen und benennt den späteren Nachweis.
Übergabe: übergibt einen prüfbaren Auftrag statt einer offenen Wunschliste.
/02Verantwortung
Builder
Aufgabe: setzt eng im vereinbarten Bereich um.
Übergabe: liefert Diff, Begründung und ausgeführte Checks.
/03Verantwortung
Reviewer
Aufgabe: sucht unabhängig nach Fehlern und Vertragsbrüchen.
Übergabe: gibt accepted, rejected oder escalate mit Begründung zurück.
/04Verantwortung
Verifier
Aufgabe: prüft Tests, Git-Zustand und Zielsystem als Ground Truth.
Übergabe: bestätigt die Übernahme oder hält den Befund offen.
Wichtige Grenze: Diese vier Verantwortungen sind im Stack vorhanden, aber nicht als eine einzige, immer aktive Vier-Agenten-Kette. Dream Team verteilt selektiv; ein fehlender Testnachweis bleibt ausdrücklich offen.
04Zusammengesetzter Ablauf
Zusammengesetzter Ablauf
Ein Auftrag, einmal komplett
Erst in der zusammengesetzten Sicht wird erkennbar, welche Aufgabe jedes System übernimmt und an welcher Stelle ein menschlicher Entscheid erhalten bleibt.
Zusammengesetzte Stack-Sicht
So verbinde ich Auftrag, Übergabe, Review und Verifikation.
Die Bausteine existieren als getrennte Systeme und Werkzeuge. Diese Reihenfolge zeigt mein Arbeitsmodell, keine vollautomatische Pipeline und keinen bereits durchgehend verdrahteten Monolithen.
- 01Mensch / DCO
Auftrag und Grenze klären
Ziel, Arbeitsbereich und Abbruchkriterien werden festgelegt, bevor ein Agent baut.
- 02Planungsrolle
Arbeit in prüfbare Schritte teilen
Der Plan beschreibt nicht nur das Ergebnis, sondern auch den späteren Nachweis.
- 03DCO
Auftrag vergeben und überwachen
Jobs können geleast, per Heartbeat beobachtet und bei einem Ausfall erneut freigegeben werden.
- 04Builder
Eng begrenzt umsetzen
Der ausführende Agent arbeitet im vereinbarten Bereich und hinterlässt einen prüfbaren Diff.
- 05Dual Bridge
Arbeit gerichtet übergeben
Zwei getrennte Datei-Lanes transportieren Aufgabe und Rückmeldung zwischen den Rechnern.
- 06Reviewer
Unabhängig prüfen
Eine zweite Rolle sucht gezielt nach Fehlern und gibt accepted, rejected oder escalate zurück.
- 07Verifier
Ground Truth prüfen
Tests, Git-Zustand und die vereinbarte Zielumgebung entscheiden, ob die Änderung wirklich angekommen ist.
- 08Mensch
Übernehmen oder bewusst stoppen
Erst nach dem Nachweis wird übernommen. Bei Risiko, Stagnation oder Unklarheit endet der Lauf begründet.
Lease und Heartbeat: sichtbar machen, ob ein Job noch lebt.
Review und Verdikt: Fehler suchen, statt den eigenen Output zu bestätigen.
Ground Truth: accepted heißt nicht automatisch gemergt.
Der Ablauf endet erst nach einer unabhängigen Prüfung und einem Nachweis im Zielsystem.
DCO
vergibt Jobs, hält Leases und Heartbeats nach und kann abgebrochene Arbeit erneut freigeben.
separates Orchestrator-System
Dual Bridge
transportiert Aufgaben und Verdikte über zwei gerichtete Datei-Lanes zwischen Rechnern.
öffentlich belegter Cross-Device-Prototyp
Orchestrated Bridge (historisch: Orchestrated Loop)
verbindet einen lokalen Werkzeug-Hook mit einem getrennten Review-Auftrag.
lokale Komponente; der Hook muss bewusst installiert werden
Dream Team
ordnet Aufgaben passenden Agenten-Clustern zu und hält unklare Verifikation offen.
selektive Aufgabenverteilung, keine pauschale Vierer-Kette
Bridge Replay
spielt gespeicherte Loop-Entscheidungen offline nach und prüft deren Determinismus.
kein Test-, Git- oder Zielsystem-Verifier
Agent Observatory
macht Werkzeug- und Agentenereignisse sichtbar.
eigene Beobachtungsschicht; nicht automatisch mit jeder Bridge verbunden
05Sicherheit und Liveness
Sicherheit und Liveness
Grenzen, Liveness und begründetes Ende
Liveness bedeutet hier, dass ein Auftrag erkennbar weiterlebt: Heartbeats zeigen Aktivität, Limits verhindern Endlosschleifen und ein Stopp nennt seinen Grund.
Risiko erkannt
Ein lokaler Scan oder eine Richtlinie blockiert die Aktion, bevor sie weitergereicht wird.
Reviewer verlangt den Menschen
Das Verdikt escalate beendet den automatischen Lauf und macht die offene Entscheidung sichtbar.
Keine erkennbare Bewegung
Gleicher Stand oder wiederholte Begründungen gelten als Stagnation, nicht als Fortschritt.
Rundenlimit erreicht
Ein festes Maximum verhindert, dass ein Loop ohne neue Erkenntnis unbegrenzt weiterläuft.
Hook bewusst aktivieren
Der Werkzeug-Hook der Orchestrated Bridge ist keine automatisch aktive Schutzschicht. Er muss lokal installiert werden; erst dann kann er riskante Schreibaktionen prüfen und bei Bedarf ein Review-Ticket anlegen.
Heartbeat ist kein Qualitätsbeweis
Ein Heartbeat belegt Aktivität, nicht Richtigkeit. Deshalb folgen nach dem lebenden Job weiterhin Review, Verifikation und der Abgleich mit dem Zielsystem.
06Stärken und Kosten
Stärken und Kosten
Verdikt, Ground Truth und Kosten
Die Arbeitsweise wird stärker, weil sie Selbstbewertung aufteilt. Sie wird zugleich teurer, weil jede zusätzliche Grenze erklärt, transportiert und beobachtet werden muss.
Unabhängige Rollen
Der Builder entscheidet nicht allein, ob seine eigene Arbeit genügt.
Kosten
Jede zusätzliche Rolle braucht Kontext, Zeit und eine klare Übergabe.
Gerichtete Übergaben
Getrennte Lanes machen Besitz und Richtung der Arbeit nachvollziehbar.
Kosten
Dateibasierter Transport ist robust und prüfbar, aber nicht so unmittelbar wie ein gemeinsamer Dienst.
Explizite Endzustände
Review, Verifikation und Übernahme bleiben unterscheidbar.
Kosten
Mehr Zustände bedeuten mehr Buchführung und mehr Stellen, an denen Drift entstehen kann.
Begründeter Stopp
Risiko und Unklarheit werden sichtbar, statt als stiller Erfolg zu verschwinden.
Kosten
Ein sicherer Stopp löst die fachliche Entscheidung nicht; er gibt sie bewusst an einen Menschen zurück.
Was Bridge Replay wirklich prüft
Bridge Replay rekonstruiert gespeicherte Loop-Entscheidungen offline und kann zeigen, ob derselbe Verlauf zum selben Verdikt führt. Es startet keine Tests, prüft kein Git-Repository und bestätigt nicht das Zielsystem.
Was das Agent Observatory ergänzt
Das Agent Observatory kann Ereignisse und Laufspuren sichtbar machen. Die automatische Verbindung aller Bridge-Schritte in diese Ansicht ist auf dieser Seite kein belegter Integrationsclaim.
accepted heißt nicht automatisch gemergt. Erst die unabhängige Verifikation zeigt, ob der vereinbarte Zielzustand wirklich erreicht wurde.
— Technische Vertiefung
Der belegte Dual-Bridge-Ausschnitt.
Die Leitseite ordnet mehrere Systeme ein. Die folgenden Diagramme und Commits bleiben bewusst beim öffentlich nachprüfbaren Cross-Device-Prototyp.
01 · Transport
Zwei Rechner, zwei gerichtete Lanes
Datei-Lanes trennen Hin- und Rückweg. Jede Richtung behält ihren eigenen Claim-Pool.
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.
02 · Review-Durchlauf
Vom Builder-Schritt zum begründeten Verdikt
Der gezeigte Lauf gehört zur Dual Bridge. accepted erlaubt den nächsten Schritt, ersetzt aber nicht den Abgleich mit Git und Zielsystem.
accepted: Die Gegenseite gibt frei — und ein Ground-Truth-Check prüft, ob das Ergebnis wirklich auf origin/base gelandet ist. accepted heißt nicht automatisch gemergt.
rejected: Zurück in den Rework — mit der Begründung des Reviewers, nicht mit Selbstlob.
escalate: Das wichtigste Verdikt — das System ruft bewusst den Menschen, statt riskant weiterzulaufen.
03 · Verdikt
Freigeben, zurückgeben oder den Menschen rufen
Die interaktive Ansicht erklärt die drei Antworten des Reviewers und die Bedingungen für einen bewussten Stopp.
Der Loop stoppt und übergibt an den Menschen — bewusst, statt blind weiterzulaufen. Vier Trigger lösen das aus:
- dangerous_action
Der Diff-Scan (deny-first) erkennt force-push, DROP TABLE, rm -rf oder API-Keys und stoppt sofort.
- 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.
04 · Öffentlicher Beleg
Eskalation und Fortsetzung im selben Branch
Zwei öffentliche Commits rahmen den bewussten Zwischenstopp ein und machen den Fortsetzungsweg nachvollziehbar.
- 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 über beide Geräte (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 verlinken direkt auf den Commit
— Kurz beantwortet
Häufige Fragen zur Agenten-Übergabe
Die Antworten halten die Rollen und die öffentliche Beleggrenze der Leitseite kompakt fest.
Was zeigt die Leitseite zur Agenten-Übergabe?
Sie verbindet Auftrag, gerichtete Übergabe, unabhängiges Review, Verifikation und bewusste Stop-Bedingungen zu einer zusammengesetzten Stack-Sicht. Die genannten Bausteine bleiben eigenständige Systeme mit eigenem Reifegrad.
Was ist der Unterschied zwischen abgeschlossen und verifiziert?
Abgeschlossen bedeutet, dass der Builder seinen Schritt fertig gemeldet hat. Verifiziert ist er erst, wenn unabhängige Checks den vereinbarten Zielzustand bestätigen. Auch accepted heißt nicht automatisch gemergt.
Welche Rollen und Systeme werden unterschieden?
Die Rollen sind Planung, Build, Review und Verifikation. DCO, Dual Bridge, Orchestrated Bridge, Dream Team, Bridge Replay und Agent Observatory übernehmen jeweils nur einen Teil des zusammengesetzten Arbeitswegs.
Welcher Teil ist öffentlich nachprüfbar?
Der Cross-Device-Transport, die gerichteten Datei-Lanes, die Verdikt-Mechanik und zwei Commit-Belege sind über das öffentliche Repository github.com/dynamic-dome/dual-bridge nachvollziehbar.
— Sparring & Code
Schreib mir, welchen Teil der Brücke ich aufmachen soll.
Ich kann den Transport, die Rollen, die Stop-Bedingungen oder die Verifikation an einem konkreten Auftrag durchgehen. Der belegte Dual-Bridge-Code liegt offen.
Wie ich solche Läufe beobachte und nachvollziehe, zeigt das Observatory