WikiKit und Contentkit sicher verbinden

Eine freigegebene Änderung in einer Wissensbasis soll als verständliche Seite auf einer Website erscheinen. Der Vorgang klingt zunächst nach einem einzigen Auftrag an einen Agenten: neues Wissen lesen, Text erzeugen und veröffentlichen. Tatsächlich umfasst er mindestens fünf verschiedene Aufgaben. Jemand muss entscheiden, welcher Wissensstand gilt. Ein System muss die freigegebenen Inhalte liefern. Ein Ablauf muss daraus eine Veröffentlichung bauen. Eine Vorschau muss geprüft werden. Zuletzt darf ein klar begrenzter Schritt den sichtbaren Stand verändern.

Der erste Teil dieser Reihe erklärt MCP, HTTP mit OpenAPI, Webhooks und A2A ohne vorausgesetztes Protokollwissen. Dieser Teil wendet die Auswahl auf WikiKit, Contentkit und eine getrennte Ausführungsschicht an. Er beginnt mit einer einfachen, von einem Menschen begleiteten Verbindung und entwickelt daraus schrittweise einen wiederholbaren Veröffentlichungsprozess.

Für diese Aufgaben stehen inzwischen mehrere technische Verträge bereit. MCP macht Fähigkeiten für Agenten auffindbar. OpenAPI beschreibt HTTP-Schnittstellen. Webhooks melden Ereignisse. A2A verbindet eigenständige Agenten. Dazu kommen Markdown und andere portable Artefakte. Wer daraus eine einheitliche Technik machen möchte, handelt sich schnell eine Integrationsschicht ein, die mehr verdeckt als vereinfacht.

Bei WikiKit, Contentkit und einer getrennten Ausführungsschicht liegt die sinnvolle Verbindung in den unterschiedlichen Aufgaben. WikiKit hält geprüftes Wissen mit Herkunft. Contentkit baut daraus veröffentlichte Ausgaben. Die Ausführungsschicht steuert wiederholbare Abläufe über Systemgrenzen hinweg. Für jede Verbindung kommt die Schnittstelle zum Einsatz, die zu ihrer Aufgabe passt.

Ein Ablauf mit mehreren Schnittstellen

Für Codex, Claude Code oder eine andere Agentenanwendung ist WikiKit ein MCP-Server; die Agentenanwendung übernimmt die Rolle des MCP-Clients. Eine Ausführungsschicht kann beide Rollen verbinden: Sie bietet der Agentenanwendung eigene Fähigkeiten über MCP an und nutzt zugleich einen MCP-Client, um beim Entwerfen eines Ablaufs in WikiKit nachzuschlagen. Contentkit bietet derzeit keinen nativen MCP-Endpunkt. Seine verbindliche Maschinenoberfläche ist die HTTP-API mit OpenAPI-Beschreibung.

flowchart LR
    H["Mensch<br/>erteilt Auftrag"] --> A["Agentenanwendung<br/>Codex oder Claude"]
    A -->|"MCP<br/>erkunden und handeln"| S["Ausführungsschicht<br/>Abläufe und Freigaben"]
    A -->|"MCP<br/>suchen und lesen"| W["WikiKit<br/>geprüftes Wissen"]
    S -->|"MCP<br/>beim Entwerfen"| W
    S -->|"REST / OpenAPI<br/>im festen Workflow"| W
    S -->|"REST / OpenAPI<br/>Vorschau und Release"| C["Contentkit<br/>veröffentlichte Inhalte"]
    W -->|"Standard Webhook<br/>Zustandsänderung"| S
    W -.->|"Markdown / OKF<br/>portables Artefakt"| C
    C --> P["Website<br/>für Menschen und Agenten"]

Das Diagramm zeigt zwei Verbindungen zwischen Ausführungsschicht und WikiKit, weil sie unterschiedliche Zwecke erfüllen. Beim Entwerfen eines Ablaufs kann ein Agent mit wikikit_search und wikikit_read nachschlagen, welche Regeln gelten. Ein gespeicherter Workflow sollte dieselbe Recherche nicht bei jedem Lauf erneut einem Modell überlassen. Er liest den benötigten WikiKit-Stand über einen begrenzten HTTP-Connector und verarbeitet ihn nach einer festgeschriebenen Definition.

Das ist die erste Auswahlregel: Eine variable Aufgabe darf ein Agent lösen. Eine bekannte Wiederholung gehört in einen deterministischen Ablauf.

Der Vertrag bleibt beim verantwortlichen System

Keiner der drei Bausteine braucht die anderen, um seine eigene Aufgabe zu erfüllen. Diese Unabhängigkeit ist für die Integration wichtiger als ein gemeinsames Framework.

Baustein	Verantwortete Daten	Geeignete Schnittstellen	Was dort nicht entschieden wird
WikiKit	Quellen, einzeln prüfbare Aussagen, Entscheidungen und freigegebene Konzepte	MCP, REST/OpenAPI, Webhooks, Markdown/OKF	Eine Veröffentlichung ist keine Wissensfreigabe
Contentkit	Revisionen, Vorschauen und aktive Releases	REST/OpenAPI, Webhooks, Markdown, `llms.txt`	Contentkit entscheidet nicht, welches Wissen wahr ist
Ausführungsschicht	Verbindungen, Workflow-Versionen, Ausführungen und Freigaben	MCP, REST/OpenAPI, Webhooks, Zeitpläne	Der Ablauf besitzt nicht die Fachdaten seiner Zielsysteme

Damit bleibt auch ein Austausch möglich. Eine andere Wissensbasis kann WikiKit ersetzen, wenn sie denselben fachlichen Vertrag erfüllt. Ein anderes Ausgabesystem kann an die Stelle von Contentkit treten. Die Ausführungsschicht hält die Verbindung, wird aber nicht zur gemeinsamen Datenbank.

OKF steht hier für Open Knowledge Format und dient wie Markdown als portables Wissensartefakt. llms.txt und llms-full.txt helfen an einer anderen Stelle. Sie beschreiben ein Produkt in einer Form, die ein Modell gut lesen kann. Eine Ausführungsschicht kann solche Selbstbeschreibungen beim Einrichten einer Verbindung finden und bei Bedarf abrufen. Contentkit und WikiKit veröffentlichen ihre Dokumentation ebenfalls auf diesem Weg. So stützt sich der Entwurf auf die tatsächlich verfügbare Dokumentation. Die Textdateien führen jedoch keinen API-Aufruf aus und erteilen keine Berechtigung. llms.txt ist eine vorgeschlagene Konvention für Dokumentation, kein Ersatz für einen ausführbaren Vertrag.

Stufe eins: Der Agent verbindet sich direkt

Für eine neue oder seltene Aufgabe ist die direkte Verbindung meist richtig. Die Agentenanwendung registriert WikiKit und, falls vorhanden, den Orchestrierungsdienst als MCP-Server. Contentkit wird über ein kleines Skript oder direkt über seine dokumentierte HTTP-API angesprochen. Jede Verbindung erhält einen eigenen, eng begrenzten Schlüssel.

{
  "mcpServers": {
    "orchestration": {
      "type": "http",
      "url": "https://orchestration.example.com/mcp"
    },
    "wikikit": {
      "type": "http",
      "url": "https://wikikit.example.com/mcp"
    }
  }
}

Die Zugangsdaten gehören in die geschützte Zugangsdatenverwaltung der Agentenanwendung und nicht in diese Datei. Ein WikiKit-Token kann nur knowledge:read tragen. Für Contentkit lässt sich Recherche mit content:read von Upload und Release trennen. Der Orchestrierungsdienst prüft die Rechte seines eigenen Aufrufers unabhängig davon.

Dieser Aufbau passt, wenn ein Mensch den Lauf begleitet, die Reihenfolge noch nicht feststeht und Erkenntnis wichtiger ist als Wiederholung. Er hält alle Fähigkeiten sichtbar und macht Fehler leicht untersuchbar. Sein Preis wächst mit der Zahl der Systeme: Die Agentenanwendung muss mehrere Anmeldungen verwalten, viele Tool-Beschreibungen in den Modellkontext bringen und Freigaben über verschiedene Oberflächen verstehen.

Die MCP-Dokumentation warnt genau vor einem naiven Gesamtkatalog. Hunderte Tool-Schemata können den Kontext füllen, bevor die eigentliche Frage gelesen wurde. Für den direkten Aufbau sollten deshalb nur die Server und Berechtigungen aktiv sein, die der konkrete Auftrag benötigt.

Stufe zwei: Ein MCP-Adapter vor der HTTP-API

Spricht eine Agentenanwendung ausschließlich MCP, kann ein allgemeiner Adapter ausgewählte Contentkit-Operationen aus der OpenAPI-Datei als Tools anbieten. Das verbessert die Bedienung: Die Agentenanwendung entdeckt Namen und Eingabeschemata auf demselben Weg wie bei anderen MCP-Servern.

Der Adapter ändert den fachlichen Vertrag allerdings nicht. Ein generiertes POST_v1_sites_site_releases kennt noch keine organisationsweite Regel, ob vorher eine Vorschau geprüft werden muss. Es hält keinen mehrstufigen Lauf fest und entscheidet nicht, ob ein Fehler wiederholt werden darf. Auch die Contentkit-Schlüssel und ihre Berechtigungsbereiche, die Scopes, bleiben erforderlich.

Ein Adapter lohnt sich daher für wenige ausgewählte Operationen oder als Übergang. Die gesamte HTTP-API mechanisch in Tools zu verwandeln, verlagert nur den großen Katalog in die Agentenanwendung. Besser sind kleine Fähigkeiten mit einer klaren Absicht, etwa Vorschau bauen, Komposition prüfen oder einen vorbereiteten Release auslösen. Der verbindliche Dienstvertrag bleibt OpenAPI; der MCP-Adapter bietet eine für Agenten geeignete Sicht darauf.

Stufe drei: Die Ausführungsschicht übernimmt die Wiederholung

Sobald derselbe Vorgang regelmäßig läuft oder den öffentlichen Stand verändert, verschiebt sich die Verantwortung. Contentkit wird über einen wiederverwendbaren HTTP-Connector mit der Ausführungsschicht verbunden. Seine OpenAPI-Datei liefert die tatsächlichen Endpunkte und Eingabeschemata. Zugangsdaten liegen in einem geschützten Speicher und tauchen weder im Workflow noch im Modellkontext auf. Aus den einzelnen Aufrufen entsteht ein versionierter Ablauf für Upload, Vorschau, Prüfung und Release.

Eine solche Ausführungsschicht bietet mehr als Protokollübersetzung. Eine Verbindung wird einmal authentifiziert und anschließend wiederverwendet. Jeder Lauf hat eine feste Workflow-Version, strukturierte Ein- und Ausgaben, ein Ausführungsprotokoll und einen nachvollziehbaren Auslöser. Schreibende oder riskante Schritte passieren erst nach der dafür vorgesehenen Freigabe. Ein fehlgeschlagener Lauf lässt sich untersuchen und an der vorgesehenen Stelle fortsetzen, ohne die vorherigen Schritte blind zu wiederholen.

Dasselbe gilt für WikiKit, aber mit einer nützlichen Trennung. Beim Entwerfen darf ein Agent WikiKit über dessen MCP-Werkzeuge kennenlernen. Der gespeicherte Lauf verwendet danach eine WikiKit-HTTP-Verbindung mit rein lesendem Schlüssel. So hilft das Modell beim Bauen, während die Produktion anschließend ohne neue Interpretation abläuft.

type PublicationInput = {
  space: string
  proposalId: string
  conceptSlugs: string[]
}

type PublicationCheckpoint =
  | { state: "preview_ready"; previewUrl: string; revisionIds: string[] }
  | { state: "approval_required"; approvalUrl: string }
  | { state: "released"; releaseId: string; publicUrls: string[] }
  | { state: "failed"; step: string; requestId: string }

Diese Aufteilung bringt dem Anwender einen handfesten Vorteil. Er muss nicht beurteilen, ob ein Agent alle nötigen Zwischenschritte im Gedächtnis behalten hat. Er sieht eine Vorschau, einen Prüfbericht und die konkrete beabsichtigte Wirkung. Der Agent darf den Vorgang vorbereiten; der festgeschriebene Ablauf und die Berechtigung entscheiden über seine Reichweite.

Stufe vier: Eine Freigabe löst den Ablauf aus

Eine dauerhafte Verbindung sollte nicht im Minutentakt fragen, ob sich etwas geändert hat. WikiKit schreibt bei einer Freigabe im selben Datenbankvorgang Ereignisse in eine Outbox und liefert sie als signierte Standard Webhooks aus. wikikit.proposal.approved enthält die betroffenen Konzept-Slugs; wikikit.concept.updated bezeichnet die einzelne neue Revision.

Die Ausführungsschicht prüft den eingehenden Standard Webhook, erkennt anhand von webhook-id wiederholte Zustellungen und startet den gebundenen Workflow. Der Webhook bleibt dabei ein Signal. Er transportiert nicht den gesamten Wissensstand. Der Workflow liest jedes genannte Konzept mit seinem eigenen knowledge:read-Schlüssel aus WikiKit nach. Damit stammt der Inhalt aus dem verantwortlichen System und nicht aus einer möglicherweise verspäteten Ereigniskopie.

sequenceDiagram
    participant R as Mensch im WikiKit-Review
    participant W as WikiKit
    participant S as Ausführungsschicht
    participant C as Contentkit
    participant P as Prüfer
    R->>W: Vorschlag freigeben
    W->>S: proposal.approved als signierter Webhook
    S->>S: Signatur prüfen und webhook-id deduplizieren
    S->>W: Freigegebene Konzepte über REST lesen
    W-->>S: Markdown, Revision und Herkunft
    S->>C: Revisionen hochladen und Vorschau bauen
    C-->>S: Ablaufende Vorschau-URL
    S->>P: Vorschau und Prüfergebnisse vorlegen
    P-->>S: Veröffentlichung freigeben
    S->>C: Release aus vorbereiteten Revisionen auslösen
    C-->>S: Release-ID und aktiver Stand
    S->>S: Öffentliche URLs und Ergebnis protokollieren

Die Kette benötigt weiterhin Fehlerregeln. Eine ungültige Signatur beendet den Eingang. Eine bekannte Ereignis-ID erzeugt keinen zweiten Lauf. 401 und 403 sind Konfigurations- oder Berechtigungsfehler und keine Einladung zum schnellen Wiederholen. Ein fachliches 422 geht mit Diagnose in die Überarbeitung. Vorübergehende Transportfehler dürfen in begrenzter Zahl und mit wachsenden Abständen erneut versucht werden. Der Release-Schritt arbeitet nur mit den Revisionen, die in der geprüften Vorschau enthalten waren.

Für regelmäßig freigegebene Wissensstände ist das heute eine geeignete Kombination: WikiKit entscheidet, was sichtbar werden darf; die Ausführungsschicht wartet vor der Veröffentlichung auf die vorgesehene Freigabe; Contentkit aktiviert danach einen vollständigen, unveränderlichen Release.

Warum A2A hier noch nicht nötig ist

Ein Wissensagent mit WikiKit, ein Agent für die Ausführung und ein Publishing-Agent für Contentkit klingen nach einer sauberen Rollenverteilung. Solche Rollen können jedoch innerhalb einer einzigen Agentenanwendung bleiben. Getrennte Namen, Prompts oder Modelle erzeugen noch keine eigenständigen Agentensysteme.

A2A steht für Agent2Agent und bietet einen offenen Vertrag für tatsächlich unabhängige Agenten. Eine Agent Card beschreibt die angebotenen Fähigkeiten und Schnittstellen. Messages tragen Gesprächsbeiträge. Ein Task hält einen länger laufenden Auftrag mit eigener ID und eigenem Zustand fest. Artifacts tragen die erzeugten Ergebnisse. Abfragen, Streaming oder Push Notifications liefern Fortschritt. Der entfernte Agent kann intern eigene Modelle, Werkzeuge und Datenquellen einsetzen, ohne sie seinem Auftraggeber offenzulegen.

Diese zusätzliche Trennung lohnt sich, wenn die Agenten verschiedenen Teams oder Organisationen gehören, eigene Laufzeiten und Sicherheitsbereiche besitzen oder einen Auftrag unabhängig weiterführen müssen. Für die bekannte Folge „Wissen lesen, Vorschau bauen, prüfen, veröffentlichen“ wäre sie vorerst unnötig. Ein deterministischer Workflow ist günstiger, leichter zu testen und in seinem Verhalten enger begrenzt.

Auch ein nativer Contentkit-MCP-Server bleibt eine mögliche Ergänzung und keine Voraussetzung. Er hätte dann einen eigenen Wert, wenn Contentkit wenige fachliche Fähigkeiten samt OAuth, Scopes, Ressourcen und Risikohinweisen anbieten soll. Eine bloße Kopie aller HTTP-Endpunkte würde zwei Verträge pflegen, ohne eine neue Verantwortung zu schaffen.

Die Entscheidung folgt der Wirkung

Die passende Integration lässt sich mit wenigen Fragen bestimmen:

Ist der Auftrag neu und begleitet ein Mensch jeden Schritt? Dann direkt verbinden.
Spricht die Agentenanwendung nur MCP, während das Ziel eine gute OpenAPI liefert? Dann ausgewählte Operationen adaptieren.
Wiederholt sich der Ablauf oder schreibt er in produktive Systeme? Dann in der Ausführungsschicht festschreiben.
Soll eine bestätigte Zustandsänderung den Lauf starten? Dann einen signierten Webhook als Signal verwenden und den Stand nachlesen.
Übergeben wirklich unabhängige Agentensysteme einander länger laufende Aufträge? Erst dann A2A prüfen.

Der Nutzen entsteht im Zusammenspiel, weil die Bausteine ihre Zuständigkeiten behalten. WikiKit macht aus Quellen geprüftes Wissen. Contentkit macht aus einem freigegebenen Stand eine zugängliche Veröffentlichung. Die Ausführungsschicht macht aus mehreren Aufrufen einen wiederholbaren und kontrollierten Vorgang. MCP, HTTP, Webhooks und A2A sind dabei keine konkurrierenden Antworten auf dieselbe Frage. Sie verbinden unterschiedliche Aufgaben eines Systems.

Der praktische Weg beginnt klein: ein Agent, wenige MCP-Verbindungen und ein begrenzter HTTP-Schlüssel. Wenn sich aus dem Versuch ein verlässlicher Prozess entwickelt, wandern Wiederholung, Zugangsdaten, Freigabe und Protokollierung in die Ausführungsschicht. Diese schrittweise Absicherung liefert früh Nutzen, ohne den ersten Versuch schon mit der Architektur des späteren Betriebs zu belasten. Der nächste Teil erklärt A2A, seine Task-Zustände und die Grenze zu MCP und festen Workflows im Detail.

Weiterführende Quellen

Wie fandest du diesen Beitrag?

Kommentare