Werkzeuge, die zusammenspielen

Diesen Beitrag anhören (26 Min.)

Der meistgewünschte KI-Use-Case klingt harmlos: ein Agent, dem man eine Aufgabe gibt – „schreib den Migrationsschritt für unser Bestellsystem“, „welchen unserer Dienste darf ich gefahrlos neu starten“, „leg einen neuen Mandanten nach unserem Standard an“ – und der sie einfach erledigt. In der Demo funktioniert das erstaunlich gut. Im eigenen Projekt scheitert es an einer unscheinbaren Stelle: Das Modell erklärt dir mühelos, wie ein B-Baum funktioniert oder wie ein TLS-Handshake abläuft, aber es kennt nicht euer Namensschema für Migrationen, nicht die Reihenfolge, in der eure Dienste hochfahren müssen, nicht die Architektur-Entscheidung, die ihr im März nach langer Diskussion verworfen habt. Dieses Wissen liegt in Repositories, in Runbooks, in Köpfen – überall, nur nicht dort, wo die KI danach greifen könnte.

Die naheliegende Reaktion ist der Wunsch nach dem einen Werkzeug, das über den ganzen Datenwust fährt und schon das Richtige herausfischt. Das ist eine alte Hoffnung, und sie wird zuverlässig enttäuscht. Ein Sprachmodell ist wie ein außergewöhnlich belesener Kollege, den man an seinem ersten Tag ins Team setzt: Er hat mehr gelesen als alle anderen zusammen, nur eben nichts über euch. Das Wissen der Welt steht ihm zur Verfügung, das Wissen eures Hauses nicht. Der Engpass war noch nie, an Information zu kommen, sondern im richtigen Moment die richtige zur Hand zu haben. Und das löst kein Alleskönner, sondern eine Handvoll kleiner Werkzeuge, von denen jedes eine Sache gut macht.

Drei Werkzeuge, drei Fragen – und eine vierte, die noch wartet

Ich baue seit einer Weile an genau dieser Handvoll. Drei davon sind offen und öffentlich, das vierte noch nicht. Die Aufteilung folgt keiner Technik, sondern drei verschiedenen Fragen, die man sauber trennen sollte.

Werkzeug	Aufgabe	Leitfrage
ContentKit	veröffentlichen	Wie bringe ich Inhalte nach draußen?
SlideKit	präsentieren	Wie wird aus demselben Material ein Vortrag?
WikiKit	wissen	Was wissen wir, woher, und wie hängt es zusammen?
coming soon	ausführen und orchestrieren	Wer darf was tun – und was ist beim letzten Lauf passiert?

ContentKit ist ein Markdown-first-Mini-CMS: Text rein, Vorschau, Release, Rollback – die Seite, die du gerade liest, läuft darüber. SlideKit behandelt Präsentationen als Code statt als Folien, die jemand von Hand pflegt. Beide sind bewusst schmal. WikiKit ist das jüngste und noch früh – seit ein paar Tagen offen, noch bei Version 0.1 – und zugleich das, um das sich der Rest gruppiert. Denn es beantwortet nicht „wie zeige ich etwas her“, sondern „was ist überhaupt wahr bei uns, und woher wissen wir das“.

Und dann gibt es ein viertes Werkzeug, das ich hier noch nicht beim Namen nenne. Es beantwortet zwei Fragen, die entstehen, sobald nicht mehr nur Menschen, sondern auch Agenten mit diesem Wissen arbeiten – und sobald aus einer einzelnen Handlung ein wiederkehrender Ablauf wird.

Die erste ist die nach der Ausführung. Die drei anderen tun jeweils genau eine Sache; keines von ihnen ruft das nächste auf. Eine Quelle aufnehmen, die Vorschläge für die Review-Runde bündeln, nach der Freigabe veröffentlichen, danach das Deck neu bauen – das ist ein Ablauf über mehrere Werkzeuge und fremde Systeme hinweg, und der läuft nicht von selbst. Genau das ist die Aufgabe der vierten: solche Abläufe ausführen und orchestrieren, jeden Schritt versioniert, protokolliert und wiederholbar, sodass man einen Lauf nachstellen kann statt ihn zu rekonstruieren.

Die zweite ist die nach der Erlaubnis. Wer darf lesen, wer eine Änderung vorschlagen, welche Agenten dürfen direkt schreiben, wann muss ein Mensch freigeben, und wie weist man hinterher nach, wer wann was entschieden hat? Beides gehört zusammen: Ein Ablauf, der nicht gegen Berechtigungen geprüft wird, ist ein Skript mit Produktionszugriff. Das ist keine Wissensablage, sondern eine Ausführungsschicht mit Governance.

Und noch etwas zieht sich durch, dasselbe Prinzip wie bei WikiKits Kern: Zur Laufzeit läuft auch hier keine KI mit. Ein Ablauf wird entworfen, und beim Entwerfen ist ein Modell ein ausgezeichneter Partner – es kennt die fremde API, es schlägt die Schritte vor, es findet den Fehler im Datenpfad. Was am Ende ausgeführt wird, ist aber ein festgeschriebener, versionierter Ablauf ohne Modell darin. Ein Vorgang, der jede Nacht zwei Systeme abgleicht, soll nicht jede Nacht neu interpretiert werden. Die KI hilft beim Bauen, nicht beim Laufen.

Was sich in der Wirklichkeit trotzdem ändert, sind die Systeme ringsum. Eine API benennt ein Feld um, eine Antwort bekommt eine neue Form. Solche Abweichungen erkennt die Schicht im Lauf und meldet sie – aber sie repariert sie nicht selbst. Aus einer erkannten Abweichung wird ein Vorschlag, kein stiller Fix: Ein Mensch sieht sich an, was sich geändert hat, und entscheidet. Das ist dieselbe Schranke wie beim Wissen, nur an anderer Stelle. Erkennen darf die Maschine, entscheiden der Mensch. Der Anlass, das zu bauen, ist längst da; über die Details schreibe ich, wenn es so weit ist.

flowchart LR
    Q["Quellen<br/>Markdown · Web · PDF · Meetings"] --> W["WikiKit<br/>Wissen kuratieren"]
    W --> C["ContentKit<br/>veröffentlichen"]
    W --> S["SlideKit<br/>präsentieren"]
    W --> A["Agenten<br/>über MCP und API"]
    A --> G["Ausführung und Orchestrierung<br/>geprüft · protokolliert · wiederholbar"]
    G --> W

Warum vier Werkzeuge und nicht ein großes? Weil jede dieser Aufgaben ihre eigene Sorgfalt braucht – und ein Alleskönner, der publiziert, präsentiert, Wissen pflegt und Zugriffe regelt, genau dort nachlässig wird. John Gall, ein amerikanischer Kinderarzt, der nebenbei ein kluges Buch über das Scheitern von Systemen geschrieben hat, formulierte es in den Siebzigern nüchtern: Ein funktionierendes komplexes System ist ausnahmslos aus einem funktionierenden einfachen System hervorgegangen. Kleine Werkzeuge, die sich über stabile Schnittstellen verbinden, sind kein Kompromiss – sie sind der einzige Weg, der über die erste Version hinaus trägt.

Warum die Fachdomäne alles zusammenhält

Der eigentliche Grund, warum ein generischer Assistent am Wissen der eigenen Organisation scheitert, sind nicht die fehlenden Daten. Er kennt die Sprache der Domäne nicht. „Gutschrift“ heißt im Rechnungswesen etwas anderes als im Vertrieb, „Storno“ hat in eurem Haus vielleicht eine Bedeutung, die kein allgemeines Modell erraten kann. Eric Evans hat das vor gut zwanzig Jahren im Domain-Driven Design beschrieben: Ein System soll die ubiquitous language seiner Fachdomäne sprechen, und diese Begriffe sind nur innerhalb eines abgesteckten Zusammenhangs – eines Bounded Context – eindeutig.

Das ist kein akademisches Detail, sondern das Ordnungsprinzip. WikiKit modelliert diesen Bounded Context direkt: Wissen liegt in Spaces, und jeder Space bringt sein eigenes, kontrolliertes Vokabular an Beziehungen mit. In einem Preis-Space bedeutet „hängt ab von“ etwas Präzises; ein Personal-Space würde dieselben Wörter anders belegen. Ohne diese Grenze verwischen die Aussagen, sobald das System größer wird – dasselbe Problem, das ich in „Agent, Modell, Fachdomäne“ und beim eigenen Agenten pro Fachdomäne von der Seite der Agenten her beschrieben habe. Das Wissenssystem ist die andere Hälfte davon: Ein Agent kann eine Fachdomäne nur so verbindlich vertreten, wie das Wissen, auf dem er steht, sauber geschnitten ist.

Das Destillat ist das Produkt, nicht die Sammlung

Der teuerste Irrtum beim Wissensmanagement ist die Annahme, dass mehr Informationen mehr Wissen bedeuten. Man lädt ein PDF herunter, legt es ordentlich ab – und verwechselt das Ablegen mit dem Wissen. Diese Collector's Fallacy hält der Praxis nicht stand: Ein Kontext, in den hundert halb passende Dokumente gekippt wurden, hilft einer Session weniger als drei genau richtige. Was zählt, ist nicht die Menge, sondern das Verdichten – und das Weglassen ist dabei die eigentliche Arbeit.

WikiKit trennt deshalb, was die meisten Ansätze vermengen. Quellen werden unverändert archiviert – sie sind das Rohmaterial, nicht das Produkt. Das Produkt sind destillierte Concepts und einzelne, überprüfbare Aussagen: Claims. Ein Claim ist bewusst klein geschnitten, ein Tripel aus Subjekt, Prädikat und Objekt, mit Herkunft und einem Status.

# a claim is a subject-predicate-object frame with provenance
subject: project/pricing-engine
predicate: uses_algorithm
object: gradient-boosting
status: verified          # proposed | draft | verified | disputed | deprecated
confidence: 0.9
valid_from: 2026-05-01
citations:
  - source_id: meeting/2026-04-30
    quote: "For tender matching we settled on gradient boosting."
    locator: "12:30"

Dieser Zuschnitt hat einen Grund, und jeder, der einmal ein Schema migrieren musste, kennt ihn. Man gießt eine Klassifikation in einen Enum – device: 'phone' | 'tablet' – und ist sicher, alle Fälle erfasst zu haben. Dann kommt das erste Foldable, und die vermeintlich vollständige Einteilung wird zur teuren Migration – samt Datenbestand, der nicht mehr ins Schema passt. Jede starre Klassifikation zerbricht an der Erkenntnis, die nicht vorgesehen war. Deshalb ist bei WikiKit auch die Einordnung selbst nur ein Claim: „X ist ein Y“ ist eine Aussage mit Quelle und Lebenszyklus, keine eingefrorene Taxonomie. Eine spätere Quelle darf ihr widersprechen.

Der zweite Baustein ist eine Schranke. Nichts wird Wissen, nur weil eine KI es vorgeschlagen hat. Ein neu synthetisiertes Concept bleibt unsichtbar, bis ein Mensch den Vorschlag geprüft und freigegeben hat – erst danach hat es eine sichtbare Revision, und die alten Revisionen bleiben als Historie erhalten. Das ist derselbe Kreislauf aus echter Arbeit, Kuration und Freigabe, den ich in „Wissen, das die Session überlebt“ beschrieben habe, nur in ein System gegossen. Und es ist die strukturelle Antwort auf das Problem aus „Sauberes Grounding: Antworten erden“: Eine Session mit falschem Wissen im Kontext rät nicht mehr erkennbar, sie rät mit Quellenangabe. Das Review-Gate ist die Stelle, an der genau das abgefangen wird.

flowchart LR
    I["Ingest<br/>Quelle archivieren"] --> P["Vorschlag<br/>Concepts und Claims"]
    P --> R["Mensch prüft<br/>und gibt frei"]
    R --> K["Wissen<br/>sichtbar und zitierbar"]
    K --> N["Nächste Session<br/>Mensch oder Agent"]
    N --> I

Der Umgang mit so einem System ist am Ende eine kleine Zahl von Verben – ingest, query, lint, wie Andrej Karpathy – Gründungsmitglied von OpenAI, später Leiter der KI-Entwicklung bei Tesla – sie für seine LLM-Wiki skizziert hat, ergänzt um Vorschlag und Freigabe. WikiKit hat dafür bewusst weder eine Kommandozeile noch eine Oberfläche: Menschen arbeiten über eine HTTP-API, Agenten über MCP. Zwei Türen, dieselbe Wissensbasis.

# no CLI, no web UI — humans drive the loop over plain HTTP
# (Authorization: Bearer $KEY on every call, omitted here)
curl -X POST "$WK/v1/spaces/default/ingest" \
  -d '{"markdown":"...","title":"Team meeting","source_kind":"meeting"}'
# 202 Accepted -> poll the ingest until it carries a proposal_id

curl "$WK/v1/proposals/$ID" -H "Accept: text/markdown"          # read the diff
curl -X POST "$WK/v1/proposals/$ID/approve" -d '{"note":"ok"}'  # the deliberate human act
curl "$WK/v1/spaces/default/search?q=gradient+boosting"         # LLM-free full-text

Für Agenten liegt dieselbe Basis als MCP-Server bereit, mit Werkzeugen wie wikikit_search, wikikit_read, wikikit_ingest, wikikit_propose und wikikit_lint. Eines fehlt in dieser Liste mit Absicht: Es gibt kein wikikit_approve. Ein Agent darf lesen, prüfen und vorschlagen – freigeben darf er nicht. Die Freigabe ist damit keine Bitte, die man einem Modell in die Instruktionen schreibt, um dann auf Einsicht zu hoffen – sie steht ihm schlicht nicht zur Verfügung. Genau das ist der Unterschied zwischen einer Regel im Pfad und einer Empfehlung in Prosa.

Lebendig, aber nicht fragil

Ein Wissensspeicher, den man einmal anlegt und dann sich selbst überlässt, verfällt. Die aktuelle Forschung nennt das memory drift: Mit der Zeit sammeln sich veraltete und widersprüchliche Aussagen an, und weil ein Modell sie mit derselben Sicherheit vorträgt wie die richtigen, sinkt die Qualität, ohne dass es jemand bemerkt. Ein statischer Bestand ist deshalb nicht neutral – er wird mit jedem Monat unzuverlässiger. Die Antwort ist nicht, das Wissen einzufrieren, sondern ihm einen Lebenszyklus zu geben – und die Entscheidung, was gilt, nicht dem Modell zu überlassen. Darauf laufen mehrere unabhängige Arbeiten dieses Jahres hinaus: Das Modell soll Konsument kuratierter, konfliktfreier Fakten sein, nicht Schiedsrichter über Widersprüche. Ein Sprachmodell kann nicht zuverlässig und nicht reproduzierbar entscheiden, welche von zwei Aussagen neuer oder verbindlicher ist. Also entscheidet das System – deterministisch, an Zeitstempeln, Versionen und Status. Ein Modell braucht WikiKit deshalb nur an zwei Stellen: beim Verdichten einer neuen Quelle und beim Beantworten einer Frage. Suchen, Lesen, Historie, Lint, Export und Review laufen ganz ohne.

Aufräumen heißt bei WikiKit ein Lint-Lauf, wie man ihn vom Code kennt – GET /v1/spaces/{space}/lint. Er ist bewusst frei von KI, reine Abfragen, die in einer CI-Pipeline laufen können, und er prüft den Stand, den die Leser tatsächlich sehen. Er findet Widersprüche, Aussagen ohne Quelle und ins Leere zeigende Beziehungen als Fehler, veraltete Claims und verwaiste Concepts als Warnungen, dazu leere Seiten und liegengebliebene Vorschläge als Hinweis. Dass Wissen unterschiedlich schnell verfällt – ein Preis in Stunden, eine Architektur-Regel über Monate – ist dabei kein Sonderfall, sondern der Normalzustand, den so ein Lauf sichtbar macht.

{
  "findings": [
    { "rule": "contradictions", "severity": "error", "concept_slug": "pricing-engine",
      "message": "two 'uses_algorithm' values disagree" },
    { "rule": "missing-citations", "severity": "error", "concept_slug": "refund-policy",
      "message": "claim has no source" },
    { "rule": "stale-claims", "severity": "warn", "concept_slug": "payment-gateway",
      "message": "last verified 214 days ago" },
    { "rule": "orphan-concepts", "severity": "warn", "concept_slug": "legacy-import",
      "message": "no relations in or out" }
  ],
  "counts": { "error": 2, "warn": 2, "info": 1 }
}

Verifizieren heißt: Ein Claim trägt einen Status, und nur verified, disputed und deprecated bekommt ein Leser überhaupt zu sehen – alles davor ist Staging und bleibt unsichtbar. Eine Aussage ohne Quelle ist keine Warnung, sondern ein Fehler. Und weil ein Modell auch Zitate erfinden kann, werden sie nachgeprüft: Steht das Zitat eines Claims nicht wörtlich in der Quelle, die das Modell gelesen hat, fliegt der Claim raus, bevor er überhaupt zur Prüfung kommt – mit einem Vermerk im Protokoll. Ein sauber arbeitendes Modell verliert dadurch nichts, ein halluziniertes Zitat kommt gar nicht erst in die Basis.

Das ist die strukturelle Fassung eines Satzes, den man in der Praxis teuer lernt: Veraltetes, aber zitiertes Wissen ist schlimmer als eine Lücke. Eine Lücke bemerkt man; eine falsche Aussage mit Quellenangabe klingt geprüft, und das Vertrauen in die ganze Basis bricht drei bis sechs Monate nach dem Start weg, sobald sich die Ersten zuversichtlich geirrt haben. Dieselbe Strenge gilt beim Antworten: Gibt die Basis nichts her, sagt die Antwort das – statt die Lücke zu überspielen.

Konsolidieren heißt: Neues wird gegen den Bestand gehalten, statt ihn stillschweigend zu überschreiben. Zwei Claims mit gleichem Subjekt und Prädikat, aber unterschiedlichem Objekt sind ein exakter Widerspruch – und WikiKit erkennt ihn deterministisch über das kontrollierte Vokabular eines Space, nicht über unscharfes Raten. Der Konflikt landet nicht in einem stillen Merge, sondern als disputed auf dem Tisch eines Menschen, der eine Seite stilllegt. Läuft dieselbe Quelle zweimal durch den Ingest, konvergiert sie auf denselben offenen Vorschlag, statt die Review-Liste zu verdoppeln.

Der Preis dafür ist klein: Nichts wird hart gelöscht. Ein überholter Wert wird stillgelegt, nicht getilgt, und die alte Revision bleibt. Der Ertrag ist groß – so lässt sich jederzeit fragen, was das Team zu einem Zeitpunkt für wahr hielt und warum sich das geändert hat. Das ist der Unterschied zwischen einem System, das sich verändert, und einem, das dabei zerbricht – dynamisch und trotzdem prüfbar.

Einzeln brauchbar, zusammen stärker

Eine Eigenschaft überliest man dabei leicht: Das hier ist eine Toolbox, keine Suite – und es ist meine, der Stand von heute. Sie ist an dem gewachsen, was meine eigene Arbeit gebraucht hat, nicht an einem Produktplan. Kein Werkzeug setzt ein anderes voraus. Man greift sich eines heraus und fasst die übrigen nie an. WikiKits eigene Dokumentation erwähnt die Geschwister mit Absicht nicht einmal – wer es einsetzt, soll über den Rest nichts wissen müssen. Zusammengesteckt wird über langweilige, stabile Schnittstellen: Markdown, HTTP, MCP, ein OKF-Bundle. Nicht über eine gemeinsame Datenbank, nicht über ein gemeinsames Framework. Kombinierbar statt gekoppelt – der Unterschied zeigt sich an dem Tag, an dem man eines davon austauschen will.

Einzeln sieht das so aus. ContentKit ist die Antwort auf einen Dokumentationsstand, den niemand mehr anfasst, weil das Veröffentlichen wehtut. Das tragende Konzept ist vom Deployment geborgt: Ein Release ist ein unveränderliches Artefakt, live ist nur ein Zeiger darauf. Der Prozess ist entsprechend unspektakulär – schreiben, Vorschau ansehen, Release, und wenn es doch daneben war, zeigt der Zeiger wieder auf gestern. Die Methode dahinter ist die altbekannte: Inhalt wie Code behandeln, mit Branch, Review und Historie. Dieser Blog läuft so, ein Team-Changelog oder eine Produktdoku genauso.

SlideKit löst ein Problem, das jeder kennt: jene eine Präsentation, die vor acht Monaten stimmte, die niemand mehr aufmacht und die trotzdem in jedem zweiten Meeting gezeigt wird. Das Konzept ist, eine Präsentation als Artefakt zu behandeln statt als Handarbeit: Markdown rein, gerendertes Deck raus, unter einer stabilen URL. Der Prozess erlaubt damit dasselbe wie bei Code – ein Deck lässt sich reviewen, diffen und neu bauen, wenn sich der Inhalt ändert. Die Methode ist Wiederverwendung ohne Kopieren: Mehrere Artikel dürfen sich ein Deck teilen, statt dass jeder seine eigene Kopie pflegt.

WikiKit braucht weder das eine noch das andere. Ein Entwickler mit einem Agenten auf einem einzigen Projekt genügt: Incident-Berichte, Architektur-Notizen, das Protokoll der Runde, in der eine Alternative begraben wurde – alles rein. Das Konzept ist der Claim mit Quelle und Status, der Prozess ist ingest, Vorschlag, Freigabe, Abfrage, die Methode ist Kuration statt Anhäufung. Der Ertrag zeigt sich beim nächsten „warum eigentlich gradient boosting und keine Regeltabelle?“ – die Antwort kommt mit Entscheidung, Datum, Alternativen und Quelle, statt als Rekonstruktion aus dem Gedächtnis der Runde.

Zusammen wird es interessanter, und zwar nicht, weil es dann „integriert“ wäre, sondern weil dieselbe geprüfte Aussage mehrfach trägt.

Wissen und Vortrag: Aus den freigegebenen Concepts eines Space entsteht ein Deck, dessen Folien dieselben Claims zitieren, die auch der Agent liest. Ändert sich die Erkenntnis, wird das Deck neu gebaut statt nachgeflickt. Der Gewinn ist nicht die gesparte Stunde, sondern dass Vortrag und Wissensbasis nicht auseinanderlaufen: Was auf der Folie steht, hat dasselbe Review durchlaufen wie der Rest.

Wissen und Veröffentlichung: Ein Concept, das intern gereift ist, wird zur kuratierten öffentlichen Projektion – einem Artikel. Interne Claims, vertrauliche Quellen und die halbfertigen Gedanken bleiben drinnen, nach außen geht die destillierte Fassung. Und weil ein Artikel selbst wieder eine Quelle ist, kann er zurückwandern; dazu weiter unten mehr.

Artikel und Deck: Beide entstehen aus demselben Material, und der Artikel verlinkt das Deck. Das klingt banal – bis man erlebt hat, wie ein Vortrag und der zugehörige Text über ein Jahr auseinanderdriften, weil sie in zwei Werkzeugen gepflegt wurden, die nichts voneinander wissen.

In Organisationen kommt die vierte Schicht dazu, und erst dann zahlt sich die Trennung richtig aus. Zum einen bei den Rechten: Wissen aufbauen darf ein weiter Kreis, vorschlagen dürfen auch Agenten, freigeben nur bestimmte Rollen, veröffentlichen noch einmal andere. Zum anderen beim Ablauf: Die nächtliche Aufnahme neuer Quellen, das Bündeln der Vorschläge für die Review-Runde, das Veröffentlichen nach der Freigabe – jeder dieser Schritte berührt ein anderes Werkzeug, und irgendjemand muss sie in der richtigen Reihenfolge anstoßen und mitschreiben, was dabei herauskam. Jedes Werkzeug macht weiterhin seine eine Sache. Wer was damit tun darf und in welcher Reihenfolge es passiert, entscheidet nicht das Werkzeug, sondern die Schicht darüber.

Damit ist die Liste auch nicht abgeschlossen, und das ist der Punkt. Die vierte Schicht ist genau die Stelle, an der fremde Systeme dazukommen – eine Datenbank, eine Supabase-Instanz, ein bestehendes CMS, ein ERP, irgendeine API, die im Haus längst läuft. Angebunden wird so etwas über einen Connector: eine beschriebene, versionierte Verbindung mit ihren Zugangsdaten und ihren Berechtigungen – nicht ein API-Schlüssel, der in einem Skript klebt. Aus Sicht der Schicht ist WikiKit dann nichts Besonderes, sondern eines von vielen Systemen, die sie ansteuert. Wer schon ein Wiki hat, mit dem er zufrieden ist, hängt eben das an dessen Stelle ein und behält den Rest. Deshalb ist die Orchestrierung eine eigene Schicht und kein Zusatz in einem der drei: Sie darf über die Werkzeuge, die sie verbindet, nichts annehmen – auch nicht, dass sie von mir sind.

Was du davon hast

Das klingt nach Infrastruktur. Was davon ankommt, ist aber sehr konkret – und es wächst mit der Zahl der Beteiligten.

Arbeitest du allein an einem Projekt, ist der Gewinn der unscheinbarste und im Alltag der spürbarste: Dein Agent wiederholt seltener einen Vorschlag, den du vor drei Monaten schon einmal verworfen hast.

Im Team löst sich das Varianzproblem, das ich an anderer Stelle beschrieben habe: Vier Leute erklären „ihrer“ Session dieselbe Konvention auf vier leicht verschiedene Arten. Mit einer geteilten, geprüften Wissensbasis erklärt niemand mehr mündlich und privat – die Erklärung ist eine, für alle, mit Quelle. Ein zweiter Gewinn liegt in Meetings: Wenn eine Entscheidung fällt, kann sie als Decision mit Kontext und Alternativen ins Logbuch wandern, statt in einem Transkript zu versickern. Gerade wo Agenten mitentscheiden, ist so ein Entscheidungslogbuch keine Kür mehr.

In größeren Organisationen steht dahinter ein handfestes Motiv. Erfahrungswissen verlässt das Haus – mit jeder Kollegin, die in den Ruhestand geht, mit jedem Wechsel. Wissen wie Code zu behandeln, versioniert und mit Besitzern, ist der nüchterne Weg, dieses Wissen zu halten. Und es ist das Fundament, auf dem Dashboards, Agenten und interne Apps überhaupt erst sinnvoll aufsetzen können.

Woran du das merkst, lässt sich kurz sagen:

Weniger Doppelrecherche, weil einmal Destilliertes nicht bei jeder Frage neu erschlossen wird.
Anbieterwechsel wird leichter: Markdown und offene Formate binden das Wissen an keinen einzelnen Anbieter und kein SDK.
Änderungen sind nachvollziehbar – wer, wann, auf welcher Quelle, mit welcher Vorgängerversion.
Mensch und Agent sehen denselben Inhalt: dieselben Dateien, keine zweite, geheime Repräsentation.
Wissen wird transportierbar – ein Bundle, das man ausliefern kann wie ein Software-Paket.

Wo sich das abhebt

Von einem Ordner voller Markdown-Dateien mit Grep-Suche unterscheidet WikiKit also zuerst der eben beschriebene Lebenszyklus: revidierbare Claims mit Status statt eingefrorener Dateien. Ein Knowledge Graph, den man einmal aufspannt, hat dasselbe Problem wie der zu früh betonierte Enum – er zerbricht an der ersten Erkenntnis, die nicht ins Schema passt.

Der zweite Unterschied ist die Haltung: headless. Es gibt keine Oberfläche, die man pflegen muss – genau die Arbeit, die an klassischen Wiki-Werkzeugen zermürbt. Der Zugriff läuft über HTTP und über MCP, sodass ein Coding-Agent auf dieselbe Basis greift wie ein Mensch, nur durch eine andere Tür. Und WikiKit versucht gar nicht erst, das eine universelle Retrieval-System zu sein. Für Volltext über große Rohbestände bleibt klassisches RAG das richtige Mittel; WikiKit hält die verdichtete, kuratierte Schicht darüber. Je nach Anwendungsfall braucht es einen anderen Ansatz – die kuratierte Wissensschicht ersetzt die Suche nicht, sie ergänzt sie.

Dass das alles auf offenen Formaten steht, ist kein Zufall. Google hat im Juni ein „Open Knowledge Format“ veröffentlicht, ein bewusst minimales Austauschformat: ein Verzeichnis aus Markdown-Dateien mit YAML-Frontmatter, versionierbar und ohne zentrale Instanz. WikiKit kann so ein Bundle exportieren – eine Konzeptseite sieht dann schlicht aus:

---
type: Project Decision
title: Pricing algorithm for tender matching
tags: [pricing, ml]
timestamp: 2026-05-01T09:00:00Z
---

# Decision

For tender matching we use gradient boosting, not a hand-tuned rule set.
See [pricing-engine](../concepts/pricing-engine.md).

# Citations

[1] [Team meeting, 30 Apr 2026](../sources/meeting-2026-04-30.md)

Wer das lesen kann, braucht kein Tool von mir. Genau das ist der Punkt.

Dogfooding: dieser Text als Testfall

Nichts von alldem wäre glaubwürdig, wenn ich es nicht selbst benutzte. Dieser Blog läuft auf ContentKit, die Folien zu meinen Vorträgen auf SlideKit, und das Wissen, das solche Texte steuert – Schreibregeln, verworfene Formulierungen, Entscheidungen darüber, was rein darf und was nicht – gehört in ein Wissenssystem statt in verstreute Notizen. Daraus wird ein Kreislauf, den ich Public Engineering nenne: Eine interne Erkenntnis wird kuratiertes Wissen, daraus wird ein öffentlicher Artikel, und der Artikel wird wieder eine zitierbare Quelle, die ins Wissen zurückfließt. Ein veröffentlichter Beitrag ist dann nicht automatisch die Wahrheit, sondern ein Snapshot der damaligen Einschätzung – mit Datum, überprüfbar, revidierbar.

Auch der Text, den du gerade liest, ist nicht von Hand herausgegangen. Ein Ablauf hat ihn genommen, die Berechtigung geprüft, ihn veröffentlicht und protokolliert, was dabei passiert ist. Das ist die vierte Schicht bei der Arbeit – unspektakulär, bis zu dem Tag, an dem man wissen muss, welche Fassung wann und durch wen live ging.

Am eigenen Material zu arbeiten hat einen unbequemen Nebeneffekt: Es legt gnadenlos offen, was noch fehlt. Jede Lücke, über die ich beim Schreiben stolpere, ist ein Eintrag für die nächste Iteration von WikiKit. Das ist der Grund, warum es v0.1 ist und nicht v1.0 – und warum diese frühe Version schon nützlich ist, statt auf die perfekte zu warten. Die konzeptionellen, methodischen und prozessualen Hilfsmittel, die so ein System trägt, habe ich in „Hilfsmittel, die tragen“ ausführlicher beschrieben; hier ist WikiKit die Stelle, an der sie zusammenkommen.

Was als Nächstes kommt

Dieser Text ist ein Überblick, kein Handbuch. Jedes der vier Werkzeuge verdient eine eigene Vertiefung: wie ContentKit aus Release und Rollback ein kleines, sicheres Publishing-System macht; warum SlideKit Präsentationen als versionierbare Artefakte behandelt; wie WikiKits Ingest-, Review- und Export-Wege im Detail funktionieren; und irgendwann die vierte Schicht, die solche Abläufe ausführt, orchestriert und dabei mitschreibt, wer mit dem Wissen was tun durfte. Der rote Faden bleibt derselbe: Wissen entsteht durch Verdichten, nicht durch Horten – und lieber vier Werkzeuge, die eine Sache gut machen und sauber zusammenspielen, als einen Alleskönner, der an der ersten ernsten Grenze bricht.

Weiterführende Quellen

WikiKit auf GitHub – headless Wissenssystem für Menschen und Agenten: Claims, Review-Gate, Lint, OKF-Export
ContentKit auf GitHub – Markdown-first-Publishing mit Vorschau, Release und Rollback
SlideKit auf GitHub – Präsentationen als Code
Wissen, das die Session überlebt – der Kuratierungs-Kreislauf, den WikiKit in ein System gießt
Agent, Modell, Fachdomäne und Der eigene Agent pro Fachdomäne – die Agentenseite desselben Themas
Andrej Karpathy: LLM-Wiki (Gist) – ingest, query, lint als Arbeitsmuster
Open Knowledge Format – Ankündigung (Google Cloud) und OKF-v0.1-Spezifikation
Domain-Driven Design Reference (Eric Evans) – ubiquitous language und Bounded Context
Don't Ask the LLM to Track Freshness (arXiv) – warum Widerspruchsauflösung deterministisch ins System gehört, nicht ins Modell
LLM Knowledge Base Staleness (Atlan) – Verfallsraten je Wissenstyp und warum veraltet-aber-zitiert schlimmer ist als eine Lücke

Wie fandest du diesen Beitrag?

Kommentare