Compozy

CompozyOS macht jede Session zu einer dauerhaften Arbeitseinheit statt zu einem lebenden Terminalprozess. Solange eine Session aktiv ist, kann ein anderer Client sich mit compozy session resume anhängen, und nach dem Ende bleiben Status, Zusammenfassung, Ereignisverlauf und Transkript abrufbar. Ein späterer Prompt kann den Anbieter auf demselben Verlauf neu starten, der Kontext übersteht also einen Absturz, Neustart oder Übergang.

Aufgaben laufen über eine einzige Warteschlange, die Menschen und Agenten teilen. Ein Worker beansprucht einen Lauf atomar, hält ein Lease, das er per Heartbeat erneuern muss, und gibt ihn an die Warteschlange zurück, wenn er abstürzt. Die Eigentümerschaft ist token-gebunden, nur der Agent mit dem Claim-Token kann einen Lauf abschließen, und Tokens werden gehasht, bevor sie das Ereignisregister erreichen. Praktisch heißt das: keine Doppelausführung und keine verwaiste Arbeit, wenn der Daemon stirbt. Zusammen mit den Loops und Automatisierungen bildet diese Warteschlange das Rückgrat der Agenten-Orchestrierung in CompozyOS.

Loops sind die Antwort der Runtime auf zielgerichtete Agenten-Automatisierung. Sie bauen einen Loop, der auf ein Ergebnis hinarbeitet, wobei Routing und Wiederherstellung die Runtime übernimmt statt ein Skript auf gut Glück. Loop-Läufe sind in der Oberfläche lesbar, hängen an der Session-Aufsicht und lassen sich sauber stoppen, statt unkontrolliert weiterzulaufen.

Zeitpläne, Webhooks und Ereignis-Auslöser starten Arbeit ohne offenes Terminal. In der v0.3-Beta sind sie zu einem einzigen Bereich Automatisierungen verschmolzen, in dem jede Automatisierung als Satz lesbar ist: wie sie startet, welche Bedingungen gelten, was sie tut. Jobs und Auslöser teilen sich eine Detailseite und zeigen das Ergebnis des letzten Laufs mit einem Ein-/Aus-Schalter, ein fehlgeschlagener Lauf ist also ohne Graben sichtbar.

Jeder Lauf hinterlässt eine Spur. Traces, Ereigniszahlen und Werkzeugnutzung stammen aus denselben Aufzeichnungen, die die Runtime schreibt, es ist also nichts zusätzlich zu instrumentieren. Sessions zeigen Status, Zusammenfassung und Transkript, und Betreiber können Logs nach Session und Ereignistyp filtern, was das Debuggen von Agentenverhalten in das Lesen strukturierter Ausgabe verwandelt statt in Scrollback-Suche.

Die Runtime ist an jeder Naht über einfache Dateien erweiterbar, nicht über eine Plugin-API. Hooks sind typisierte Lebenszykluspunkte, die verweigern oder einschränken, aber nie umgehen können; Skills sind Markdown-Dateien mit YAML-Frontmatter; und Erweiterungen bündeln Skills, Hooks, Werkzeuge und MCP-Server als Zip-Dateien oder über ein GitHub-Register. Alles, was die Web-Oberfläche kann, kann ein Agent über CLI, HTTP oder UDS.

CompozyOS baut die Agentenlogik nicht hinter API-Hüllen nach. Es startet echte Agent-CLIs als verwaltete Sessions über eine ACP-kompatible Anbieterschicht, Claude Code bleibt also Claude Code und OpenClaw bleibt OpenClaw. Sechsundzwanzig eingebaute Anbieter sind gelistet, der native Login bleibt im jeweiligen CLI-Speicher, und API-Anbieter können optional von CompozyOS verwaltete Schlüssel nutzen.