Werkzeuge, die zusammenspielen

Ein festgeschriebener Workflow, eine agentische Mission und eine Codeänderung sind drei verschiedene Einheiten. Wer sie unter „Orchestrierung“ zusammenfasst, verwischt ihre Freigaben und Ergebnisse.

Die sechs Produkte teilen weder Framework noch Datenbank noch ein zentrales Portal. Alle trennen menschliche Entscheidungen von begrenzten Maschinenverträgen. Menschen brauchen eine verständliche Oberfläche für Entscheidungen. Dienste und Agenten brauchen dokumentierte Zugänge. Innerhalb jeder Produktgrenze bleibt die Fachlogik im jeweiligen Produkt; Cockpit und Maschinenzugänge projizieren dasselbe Modell.

Deshalb besitzt jedes Produkt ein eigenes Cockpit und eigene Maschinenzugänge. Die Cockpits verwenden eine gemeinsame Interaktionsgrammatik, werden aber im jeweiligen Repository gebaut und mit dem jeweiligen Produkt ausgeliefert. Zusammengesetzt werden die Kits über HTTP, MCP, A2A, Webhooks und portable Artefakte. Eine gemeinsame Laufzeit ist dafür weder nötig noch vorgesehen.

Der Zuschnitt folgt sechs verschiedenen Verantwortungen. Ein System entscheidet, welches Wissen freigegeben ist. Ein anderes macht eine geprüfte Inhaltsrevision sichtbar. Ein Ablauf muss nach seiner Freigabe wiederholbar bleiben. Ein offenes Ziel braucht begrenzte Autorität. Eine Codeänderung braucht einen isolierten Arbeitsbereich sowie Entscheidungen vor und nach der Ausführung. Und die beteiligten Dienste müssen belegen können, ob sie sich entsprechend ihrer Dokumentation verhalten.

Sechs Produkte, sechs Verantwortungen

Produkt	Verantwortung	Verantwortete Einheit
ContentKit	Inhalte veröffentlichen	unveränderliche Inhaltsrevision und Release
WikiKit	Wissen kuratieren	belegter Claim und freigegebene Wissensrevision
SubKit	wiederholbare Abläufe ausführen	versionierter Workflow und protokollierter Lauf
WatchKit	Verhalten beobachten und belegen	Evidenz und daraus abgeleitetes Urteil
WorkKit	offene Ziele delegieren	Mission innerhalb einer aktivierten Work Order
CodeKit	Coding-Agenten kontrollieren	Aufgabe, isolierter Worktree und prüfbarer Diff

Keines dieser Produkte setzt ein Geschwisterprodukt voraus. Wer nur veröffentlichen will, kann ContentKit allein einsetzen. Wer ausschließlich kuratiertes Wissen für Menschen und Agenten benötigt, braucht dafür kein Publishing-System. Die Grenze ist wichtiger als die gemeinsame Namensgebung: Jedes Kit soll allein einsetzbar und über seine Verträge ersetzbar bleiben.

Der Überblick ist kein reales Deployment-Diagramm. Er zeigt die Produktgrenzen und die vorgesehenen Zugänge; welche Produkte eine konkrete Installation kombiniert, ist eine eigene Entscheidung. Die referenzierten Repository-Stände wurden am 16. August 2026 geprüft.

flowchart TB
    H["Menschen"] --> U["eigenes Cockpit je Produkt"]
    M["Dienste und Agenten"] --> A["Maschinenverträge je Produkt<br/>REST · MCP · A2A · Webhooks"]

    U --> CK["ContentKit<br/>Veröffentlichung"]
    U --> WK["WikiKit<br/>Wissen"]
    U --> SK["SubKit<br/>Workflows"]
    U --> VT["WatchKit<br/>Beobachtung"]
    U --> WT["WorkKit<br/>Missionen"]
    U --> DK["CodeKit<br/>Coding-Aufgaben"]

    A --> CK
    A --> WK
    A --> SK
    A --> VT
    A --> WT
    A --> DK

Ein Cockpit pro Produkt

Ein Cockpit ist die menschliche Projektion der jeweiligen Fachdomäne. Es ersetzt die Maschinenverträge nicht und führt kein zweites Fachmodell ein. Die konkrete Anbindung unterscheidet sich je Produkt: ContentKit steuert seine Publishing-Domäne über die bestehende API, WikiKit stellt seine Wissensbasis über REST und MCP bereit, und SubKit hält Chat, Workflows, Connectoren, Freigaben und Audit in seiner eigenen Domäne. WatchKit, WorkKit und CodeKit besitzen entsprechend auf ihre Aufgaben zugeschnittene Oberflächen.

Die Ähnlichkeit zwischen diesen Oberflächen entsteht durch einen kopierten Gestaltungs- und Interaktionsvertrag. Kein Cockpit importiert die Laufzeit eines Geschwisters. Navigation und Arbeitsschritte bleiben fachlich: SubKit zeigt Workflows und Läufe, WikiKit zeigt Spaces und Änderungsvorschläge, WatchKit zeigt Ziele und Evidenz, WorkKit zeigt Missionen und Pläne, CodeKit zeigt Aufgaben und Diffs, ContentKit zeigt Inhalte und Releases.

Diese Trennung verhindert eine zentrale Verwaltungsanwendung, die sämtliche Produkte kennen müsste. Eine neue Funktion in WikiKit verlangt keine Änderung am CodeKit-Cockpit. Gleichzeitig muss ein Mensch vertraute Entscheidungen nicht in sechs völlig verschiedenen Bedienlogiken suchen. Geteilt wird die Grammatik, nicht der Zustand.

Veröffentlichen und Wissen: ContentKit und WikiKit

ContentKit verantwortet den aktiven Veröffentlichungsstand. Markdown wird als portable Quelle eingelesen, jeder Schreibvorgang erzeugt eine unveränderliche Revision, und ein Release rendert daraus einen vollständigen statischen Stand. Die Aktivierung verschiebt atomar einen Zeiger. Eine fehlgeschlagene Verarbeitung kann die öffentliche Seite deshalb nicht teilweise verändern.

Die Vorschau ist dabei eine technische Grenze, keine unverbindliche Ansicht. Sie bindet die ausgewählten Revisionen, den vorherigen Veröffentlichungsstand und einen Digest der gerenderten Dateien. Eine Promotion aktiviert exakt diese bereits geprüften Bytes. Hat sich das Manifest oder der Veröffentlichungsstand seit der Vorschau verändert, wird die Promotion abgelehnt. Das ContentKit-Cockpit macht diese Publishing-Domäne für Menschen bedienbar, ohne einen visuellen Page-Builder oder ein zweites Inhaltsmodell einzuführen.

WikiKit beantwortet eine andere Frage: Was gilt, woher stammt die Aussage, und wer hat die Änderung geprüft? Quellen werden unverändert archiviert. Daraus entstehen einzelne Claims mit wörtlichen Belegen und Konzeptseiten. Eine Änderung bleibt als ChangeProposal außerhalb des sichtbaren Wissens, bis ein Mensch sie freigibt.

Maschinen erreichen WikiKit über REST und MCP. Menschen lesen und bearbeiten dieselbe Wissensdomäne im eingebetteten Cockpit. „Headless“ bezeichnet hier die Trennung zwischen Wissensmodell und Projektion. Es bedeutet nicht, dass Menschen auf eine Weboberfläche verzichten müssen.

Eine Veröffentlichung ist damit keine Wissensfreigabe. WikiKit entscheidet nicht, welcher Artikel live ist, und ContentKit entscheidet nicht, welcher Claim als geprüftes Wissen gilt. Ein freigegebenes Konzept kann als Quelle für einen Artikel dienen. Die Freigabe des Wissens und die Veröffentlichung des Artikels bleiben dennoch zwei getrennte Entscheidungen mit eigenen Revisionen und Nachweisen.

Reproduzierbarer Ablauf oder delegiertes Ziel?

SubKit und WorkKit führen beide Arbeit aus, aber ihre Ausgangslage ist verschieden.

SubKit übersetzt beschriebene Routinen in freigegebene, wiederholbare Workflows. Beim Entwerfen kann ein Modell eine fremde API erschließen, Schritte vorschlagen und Datenpfade prüfen. Nach der Freigabe läuft die gespeicherte Workflow-Version ohne erneute Modellentscheidung durch denselben Ausführungspfad. Jeder Lauf wird als eigene Ausführung protokolliert.

Das passt zu Routinen, deren Weg bekannt ist: Daten lesen, validieren, transformieren, eine Freigabe abwarten und danach einen begrenzten Schreibschritt ausführen. Eine Änderung am Ablauf erzeugt eine neue Workflow-Version. Sie verändert nicht still den bereits freigegebenen Vertrag.

WorkKit beginnt bei einem Ziel, dessen Weg noch nicht festgeschrieben ist. Aus dem Ziel wird eine Mission und daraus ein Plan über Fähigkeiten, welche die gebundenen Gegenstellen tatsächlich melden. Die Mission bindet eine unveränderliche, von einem Menschen aktivierte Work-Order-Revision mit begrenzter Autorität. Der Agent plant innerhalb dieser Grenze; er erweitert sie nicht selbst.

HTTP, MCP, A2A, Webhooks und Chat führen in WorkKit durch dieselbe Planungspipeline. Das Cockpit zeigt Assistenten, Missionen, Pläne und Entscheidungen. Ein API-Schlüssel kann lesen und technische Aufträge übermitteln, gilt aber nicht automatisch als anwesender Mensch für eine Freigabe.

Die Unterscheidung lässt sich knapp festhalten:

bekannter Weg + wiederholbare Ausführung  → SubKit-Workflow
offenes Ziel + ausdrücklich begrenzte Autorität → WorkKit-Mission
Repository-Aufgabe + Plan, Worktree und Diff    → CodeKit-Task

Ein freigegebener SubKit-Workflow soll nicht bei jedem Lauf neu überlegen. Eine WorkKit-Mission muss dagegen planen dürfen, weil ihr Weg gerade nicht vollständig vorgegeben ist. Diese beiden Anforderungen in derselben Ausführungseinheit zu vermischen, würde entweder den Workflow unberechenbar oder die Mission unnötig starr machen.

Kontrollierte Coding-Aufgaben: CodeKit

CodeKit ist die spezialisierte Kontrollschicht für Coding-Agenten. Eine Aufgabe besteht aus einem Prompt gegen genau ein Projekt, wird von einem Agenten-Backend bearbeitet und erhält einen isolierten Git-Worktree. Der Agent plant zuerst. Ein Mensch prüft diesen Plan, bevor Änderungen zugelassen werden. Am Ende steht kein abstrakter Erfolgsstatus, sondern ein Branch mit einem Diff, der gelesen und anschließend gemerged oder abgelehnt werden kann.

CodeKit selbst schreibt keinen Code. Es beaufsichtigt einen über ACP angebundenen Coding-Agenten. Auftrag und Autorisierung verwenden getrennte Berechtigungen; die auftraggebende Maschinenidentität kann ihre eigene Planbestätigung nicht ersetzen. REST, MCP und Cockpit führen durch denselben Aufgabenlebenszyklus und dieselben Entscheidungspunkte.

WorkKit kann allgemein Missionen über gemeldete Fähigkeiten planen. CodeKit ergänzt für Repository-Arbeit die dazugehörigen Worktree-, Plan-, Ereignis- und Diff-Verträge. Die Produkte überschneiden sich daher nicht zufällig, sondern schneiden verschiedene Einheiten von Arbeit.

Beobachten, nicht steuern: WatchKit

Ein erreichbarer Dienst kann trotzdem gegen seine eigene Beschreibung verstoßen. WatchKit prüft deshalb neben Gesundheit und beobachtetem Verhalten auch dokumentierte Zusagen. Ein Ziel beginnt mit einer Basis-URL. WatchKit entdeckt, welche Gesundheits-, Metrik-, OpenAPI- und MCP-Oberflächen tatsächlich erreichbar sind, und behält die Evidenz für seine Urteile.

Erkennung, Korrelation, Alarmierung und Attribution bleiben deterministisch und die grundlegende Überwachung arbeitet ohne Modell. Rohprotokolle werden nicht dauerhaft gespeichert, sondern zu maskierten Mustern und Zählern verdichtet. Das begrenzt die Menge gespeicherter Betriebsdaten.

Cockpit und MCP kommen aus demselben Prozess. WatchKit beobachtet und belegt, steuert die beobachteten Dienste aber nicht. Ein Befund kann einen Menschen oder einen getrennten Ablauf informieren. Die Reparatur bleibt Aufgabe des Produkts, dem der betroffene Dienst gehört.

Zusammenspiel ohne gemeinsame Laufzeit

Die Produkte werden ausschließlich über ihre veröffentlichten Schnittstellen und Artefakte verbunden. Ein Webhook kann eine bestätigte Zustandsänderung melden. Ein SubKit-Workflow kann einen Stand über REST lesen und einen zulässigen Folgeschritt ausführen. Ein Agent kann Werkzeuge über MCP entdecken. WorkKit oder CodeKit können begrenzte Aufgaben über ihre eigenen Verträge annehmen. Markdown kann als portables Artefakt zwischen Wissens- und Publishing-Prozessen übertragen werden.

Diese Beispiele beschreiben mögliche Kompositionen. Sie behaupten nicht, dass jede Installation alle sechs Produkte gemeinsam betreibt. Dadurch kann eine Installation etwa WikiKit ersetzen, ohne SubKit oder ContentKit umzubauen, solange der benötigte Vertrag erhalten bleibt.

Für die Auswahl helfen einige konkrete Fragen:

• Soll ein bekannter Ablauf nach derselben freigegebenen Workflow-Version und ohne erneute Modellentscheidung laufen, gehört er in SubKit.
• Muss ein Ziel erst innerhalb einer begrenzten Autorität geplant werden, gehört es in WorkKit.
• Bearbeitet ein Coding-Agent ein Repository, gehören Plan, Worktree und Diff in CodeKit.
• Muss eine Aussage mit Quelle und Review dauerhaft als Wissen gelten, gehört sie in WikiKit.
• Soll eine geprüfte Inhaltsrevision als vollständiger Stand sichtbar werden, gehört sie in ContentKit.
• Muss geprüft werden, ob das tatsächliche Verhalten eines Dienstes seiner Dokumentation entspricht, gehört die Beobachtung in WatchKit.

Menschliche Entscheidungen sind dabei produktbezogen, nicht pauschal. WikiKit hält Wissensänderungen bis zur Freigabe zurück. WorkKit bindet Missionen an menschlich aktivierte Work Orders. CodeKit trennt Auftrag, Planfreigabe und Merge. ContentKit kann eine unveränderliche Vorschau mit exaktem Manifest zur Promotion vorlegen. WatchKit liefert Evidenz; die Entscheidung über eine Reparatur verbleibt außerhalb seiner Beobachtungsdomäne.

Die Konsequenz

Wer diese Verantwortungen zusammenlegt, koppelt Freigaben, Laufzeiten und Fachzustände unnötig. Eine Verantwortung braucht eine klar benannte Einheit, eine durchgesetzte Invariante und eine erkennbare Entscheidungsgrenze. Die menschliche Oberfläche und die Maschinenverträge müssen auf dieselbe Fachdomäne zeigen. Die Verbindung zu anderen Systemen erfolgt über dokumentierte Verträge, nicht über gemeinsam genutzte Interna.

Der Produktname ist für diese Regel zweitrangig. Entscheidend bleibt, ob ein Werkzeug allein einsetzbar ist, seine Wirkung durch Revision, Audit, Evidenz oder Diff nachweisen kann und sich ersetzen lässt, ohne die übrigen Verantwortungen neu zu bauen. Kann eine Komponente das nicht, braucht sie keine zusätzliche Marke, sondern eine neu geschnittene Grenze.

Weiterführende Quellen

• ContentKit auf GitHub – Markdown, unveränderliche Revisionen, Vorschauen und atomare Releases
• WikiKit auf GitHub – archivierte Quellen, belegte Claims und menschlich geprüfte Wissensrevisionen
• SubKit auf GitHub – versionierte Workflows, Connectoren, Freigaben und protokollierte Ausführungen
• WatchKit auf GitHub – belegte Überwachung von Verhalten und Dokumentationswahrheit
• WorkKit auf GitHub – Missionen innerhalb begrenzter Work Orders
• CodeKit auf GitHub – kontrollierte Coding-Agenten mit Plan, isoliertem Worktree und Diff
• Wissen, das die Session überlebt – Kuration als wiederholbarer Wissensprozess
• Agent, Modell, Fachdomäne – warum Fachgrenzen für Agenten wichtiger sind als ein weiteres Modell

Wie fandest du diesen Beitrag?

Kommentare