Internes Multi-Agent-Betriebssystem

Das PM-System.
Agenten, die zusammen liefern.

Kein Ticket-Board — ein lebendes System aus spezialisierten KI-Agenten, die autonom Code bauen, sich gegenseitig prüfen, Unsicheres hart blockieren, über mehrere Oberflächen und Instanzen hinweg koordinieren — und sich selbst überwachen. Der Mensch entscheidet nur noch das Irreversible.

8
Agenten-Rollen
5
Oberflächen (Brydge)
130
Assets überwacht (APEX)
L4
Mensch nur ganz oben

Teil 1

Das Agenten-Team
Owner

Mensch im Loop

Entscheidet nur das Kritische/Irreversible. Per Telegram & Voice erreichbar.

Lead / Dev

Orchestrator

Plant, verteilt Tickets, führt Ops aus, koordiniert die Specialists.

Codex · GPT-Reviewer

Reviewer / Critic

Prüfen Code & Vorschläge gegen ein Score-Schema. Multi-Model-Konsens 92–97.

Connector

Surface-Brücke

Verbindet Agenten über Oberflächen & Tools hinweg (Brydge).

FederationCoordinator

Multi-Instanz

Koordiniert verbundene PM-Instanzen (Zentrale + Satelliten).

Specialist-A…Z

Worker-Pool

Werden vom Runner in isolierten Worktrees gespawnt — bauen, testen, committen.

root

Sys-Admin

DNS, Certs, Deploy, systemd — die operative Infrastruktur.

Security-Agent · Sentinel

Wächter neu

Fährt das Production-Gate, überwacht den Flow, erkennt Stau/Anomalien, schreibt Root-Cause-Analysen.

Teil 2

Wie die Agenten miteinander reden
Lead
verteilt Tickets, hinterlässt Aufträge als Kommentar pm_comments
Specialist
meldet „completed — ready for review" zurück ans Ticket pm_comments
Reviewer/Critic
schlägt vor & bewertet — Proposal-/Review-Loop pm_proposals · pm_reviews
Owner
gibt frei / fragt nach — per Telegram-Inline-Buttons & Sprache @Aipm1bot · Whisper
Connector
reicht Kontext über Oberflächen weiter: Chat · Cowork · Code · Design · Terminal Brydge :5320
Shared-Brain
NEU — jeder Agent liest alle Kanäle: board_search · chat_read, read-only & gehärtet Brydge-Mesh L1
Event-Bus
NEU — Trigger feuern, Agenten reagieren selbst statt auf Befehl zu warten brydge-event-bus

Teil 3

Der autonome Liefer-Flow
1

Detect & Pick

Runner pollt das PM, wählt nach Priorität. cloud-pm-runner :5331

2

Classify

Risiko-Level L1–L4. L1–L3 autonom, L4 (Security/Payment/Migration/Live) → Owner.

3

Approve

Nur Kritisches wartet. Kein Head-of-Line-Block — 3 Freigaben parallel. max_pending_approvals=3

4

Spawn · Validate · Review

Specialist arbeitet im Worktree → Validatoren (Secret/Lint/Test) → Multi-Model-Konsens-Gate.

5

Security-Gate neu

Vor Production prüft der Wächter deterministisch auf offene Critical/High — sonst hart 403. APEX /security/gate

6

Merge-Pipeline → Staging

Risiko-klassifiziert, stückweise nach dev — nie alles auf einmal nach Live.

7

Heal · Measure

Wächter erkennt Stau/Zombie/Fehler → RCA. PM misst sich selbst: Tokens, ETA. pm_task_metrics

Teil 4

Schnittstellen & Federation

Telegram + Voice

@Aipm1bot: Push, Inline-Approve/Reject, Sprachbefehle (Whisper → Intent).pm-notify-svc :5340 · transcribe :5341

Brydge — 5 Oberflächen

Verbindet Claude Chat · Cowork · Code · Design · Terminal als gemeinsamer Daten-Bus.MCP :5320 · Doku :5520

Federation

Zentrale (Adam-Eve) + Satelliten-Instanzen, signiert vernetzt — Tickets fließen instanz-übergreifend.pm_instances · signing_secret

Rules-Hub + Sentinel

Verbindliche Regel-Verteilung + Anomalie-/Betriebs-Überwachung.:5760 · sentinel :9701

Teil 5 neu

Intelligence- & Autonomie-Mesh
APEX

Intelligence-Layer

Bewertet die ganze Estate: Assets ↔ PM ↔ Git ↔ Server ↔ Agent-Provenienz. Deterministisch, 0 LLM.apex-api :8200 · 130 Assets

Brydge-Mesh L1+L2

Shared-Brain + Event-Bus

Alle Agenten lesen alle Kanäle (board_search/chat_read), Events triggern Arbeit autonom — Mensch-raus-Hebel.brydge-event-bus · ADR-001

APEX → PM → Runner

Wertschöpfungs-Loop

Läuft ohne Trigger: APEX-Cycle erkennt Chancen → legt PM-Tickets an → Runner baut → LaunchPad stellt live./autonomy/cycle · autonom seit 31.05

Emergency-Board

Nie Wissen verlieren

Flüchtige Ideen/Aufträge werden sofort festgehalten — kein falsches „erledigt", superseded ≠ done.EMERGENCY_BOARD.md + PM

Teil 6 neu

Die Vereinbarung — Mensch ↔ System

Autonomie hat klare Grenzen. Diese Regeln sind im Code verankert, nicht nur Absicht — sie bestimmen, was das System allein darf und was immer beim Menschen bleibt.

L1–L2
Reversibles: Bauen, Testen, Staging-Deploy, Doku
autonom
L3
Größere Änderungen mit Review-Konsens
autonom + Review
L4
Geld · Löschen · fremde Production · Migration · Infra
nur Mensch

Live-Deploy immer Human

Production geht nie ohne Owner-Klick live — hart im Code, kein Override.

Autonome Freigabe ab 92 %

Live autonom nur bei verifiziertem Score ≥ 92 % UND Konsens mehrerer Modelle (Opus · Sonnet · Haiku · Codex).

Security is key

Kein Go-Live mit offenem Critical/High. Das Gate gibt 403 — auch gegen den eigenen Wunsch.

Im Zweifel Ticket

Operatives an root, Unklares ins PM/Emergency-Board — nie still übergehen, nie Wissen verlieren.

Teil 7

Drei Umgebungen, sauber getrennt
LIVE
master · Production · von der Pipeline nie direkt berührt
STAGING
dev · isolierte DB · hier wird getestet
DASHBOARD
Merge-Steuerung · Login — Features auswählen & promoten

Teil 8 · Beweis neu

Das Gate lässt sich nicht überreden

Live-Lauf des deterministischen Security-Gates über die Estate. „Pass" nur, wenn keine offenen Critical/High existieren — sonst Production hart blockiert.

brydge0 Critical · max 5.0PASS
canva-adam-eve-api11 Critical · max 9.9BLOCKIERT
taxonair-admin17 Critical · max 10.0BLOCKIERT
maxxipower8 Critical · max 9.5BLOCKIERT
signtrust5 Critical · max 9.0BLOCKIERT
cloud-adam-eve3 Critical · max 9.5BLOCKIERT
404
Security-Findings erfasst
392 offen · 47 Critical · 102 High
5 / 6
Production-Systeme blockiert
nur das saubere kam durch Gate hält

Früher legte ein wartendes Owner-Approval das ganze Team lahm — heute fließt alles weiter, 12× Durchsatz, und nichts Unsicheres kommt live. Reform PM #1103 / #1113 / #1119 · Security-Gate PM #1546.