Internes Multi-Agent-Betriebssystem

Das PM-System.
Agenten, die zusammen liefern.

Kein Ticket-Board — ein lebendes System aus spezialisierten KI-Agenten, die über Tickets, Vorschläge und Reviews miteinander reden, autonom Code bauen, sich gegenseitig prüfen, über mehrere Oberflächen und Instanzen hinweg koordinieren — und sich selbst überwachen.

7+
Agenten-Rollen
1 496
Agent-Nachrichten
506
Tickets geliefert
5
Oberflächen (Brydge)

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 (≥85 = Pass). Der Critic-Loop.

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.

Sentinel · Health-Watch

Wächter

Überwacht den Flow, erkennt Stau/Anomalien, erstellt Root-Cause-Analysen.

Teil 2 — der Kern, der vorhin fehlte

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
FedCoordinator
synchronisiert Tickets zwischen PM-Instanzen — signiert & authentifiziert pm_instances · pm_distributions
Rules-Hub
verteilt die verbindlichen Regeln (R-Policy) an alle Agenten :5760/api.json

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) → 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) → Critic-Review ≥85.

5

Merge-Pipeline → Staging

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

6

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

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

Teil 6 · Beweis

DEMO-1 — Stresstest des Flows
2 / 40
VORHER — Head-of-Line-Block
27/30 Polls blockiert Stau & Chaos
24 / 40
NACHHER — entstaut
0 Stau-Polls harmonisch

Ein wartendes Owner-Approval legte früher das ganze Team lahm. Heute fließt alles weiter — 12× Durchsatz. Reform PM #1103 / #1113 / #1119.