Projekt Cedar: Prüfung, ob KI-Agenten ein Unternehmens-Wiki im Markdown-Format pflegen können.

Obsidian kann Kontext zwischen den Projekten einer Person und ihren Programmier-Assistenten übertragen. Pläne, Entscheidungen, Anforderungen und Einschränkungen überdauern einzelne Sitzungen – Claude, Codex oder jede andere Assistenten-Tool kann dieselben Projektdateien lesen, und ein Mensch kann diese Dateien überprüfen und korrigieren sowie zwischen Modellen wechseln, ohne dass das Projektwissen in der Chat-Geschichte stecken bleibt. Dies funktioniert gut innerhalb der Projekte einer Person, da diese meist die Entscheidungen trifft und weiß, wie alles organisiert ist.

In einem Unternehmen sieht die Situation anders aus. Das Wissen ist über verschiedene Repositorien, Tickets, Meetings, Dokumente sowie zahlreiche Personen verteilt. Die Quellen widersprechen sich oft, und Entscheidungen werden rückgängig gemacht. Eine Sammlung von Meetingnotizen kann eine Idee beschreiben, die das Team später aufgegeben hat, während ein genehmigtes Architekturdokument die tatsächlich gültige Entscheidung festhält. Die offene Frage ist daher, ob eine pro Projekt entwickelte Praxis auf die gesamte Organisation übertragen werden kann und ob gemeinsam genutztes Markdown als Übereinkommen zwischen Mitarbeitern und Agenten dienen könnte.

Die Idee der LLM Wiki

Dieses Konzept stammt von einem kürzlichen Vorschlag von Andrej Karpathy, der es LLM Wiki nannte. Es umfasst drei Ebenen:

• Rohdatenquellen, die niemals geändert werden
• Eine Markdown-Wiki mit Verlinkungen, die von einem Agenten gepflegt wird
• Ein Schema, das dem Agenten zeigt, wie diese Wiki strukturiert und gepflegt werden soll

Drei Operationen wirken auf diese Schichten ein. Durch Ingest werden neue Quellen eingeführt. Über Queries wird auf das gepflegte Wissen zugegriffen. Lint überprüft die Wiki-Seiten auf Lücken, veraltete Inhalte, Konflikte und mangelhafte Organisation.

Zu den möglichen Quellen, die im Vorschlag genannt werden, gehören Slack-Unterhaltungen, Meetings, Projektdokumente und Kundengespräche, die vom Agenten zu Wissen zusammengefasst werden, das von einer Aufgabe zur nächsten weiterbesteht. Das unterscheidet sich von einem Abrufsystem, das jedes Mal nach einigen relevanten Fragmenten sucht, wenn jemand eine Frage stellt. Hier behält der Agent ein Artefakt bei, das sich mit dem Eintreffen neuer Informationen weiterentwickelt.

Eine erste Architektur, die sich als falsch erwies

Die erste natürliche Interpretation der LLM Wiki deutet auf zwei getrennte Wissensschichten hin: eine von dem Agenten generierte Wiki-Seite und darüber liegende Obsidian-Dateien. Das war unnötig, da dadurch Inhalte doppelt vorhanden sind und ein Synchronisierungsproblem entsteht.

Die erzeugte Markdown-Datei kann selbst die Wiki-Funktion übernehmen, und Obsidian ist lediglich ein Fenster dazu – ein Ort, an dem man Seiten durchsuchen, lesen und bearbeiten kann. Markdown ist der gemeinsame Vertrag, während Obsidian die Arbeitsfläche für den Menschen darstellt. Wenn man das Fenster durch ein anderes ersetzt, bleibt das darunterliegende Wissen unverändert – genau so verhält sich eine echte Wiki. Eine Organisation kann genehmigte Seiten über SharePoint, Confluence oder ein internes Portal veröffentlichen, während Ingenieure und Mitarbeiter weiterhin mit der gepflegten Quelle arbeiten.

Der vorgeschlagene Ablauf ist wie folgt. Die Unternehmen liefern unveränderliche Rohdaten als Beweismittel. Ein Wiki-Betreuungsagent verwendet das Schema sowie die Verwaltungsregeln, um Änderungen vorzuschlagen; nach Überprüfung werden die genehmigten Änderungen in ein mit Git unterstütztes Markdown-Wiki eingefügt. Eine Service-Schicht kümmert sich um Authentifizierung, Berechtigungen, Suchfunktionen sowie das Prüfungsprotokoll. Die Nutzer erreichen das Wissen über Obsidian oder ein Unternehmens-Wiki, während die Agenten dieselbe Service-Schicht mit ihren eigenen Identitäten und Berechtigungen nutzen.

Unternehmenswissen benötigt mehr als nur Verlinkungen zwischen Notizen

Ein persönlicher Datensafe funktioniert teilweise deshalb, weil sein Besitzer sich an den Kontext der Dateien erinnert: welche Meeting-Notiz spekulativ war, wann sich eine Anforderung änderte, obwohl nicht jede damit verbundene Seite aktualisiert wurde, und welche beiden Dateien eine Entscheidung unter unterschiedlichen Namen beschreiben. Ein Unternehmen kann sich nicht darauf verlassen, dass eine einzige Person all das im Gedächtnis behält.

Sein Wissenssystem muss folgendes unterscheiden:

• eine bloße Vorschlag gegen eine genehmigte Entscheidung
• was heute gilt gegen das, was nur Geschichte ist
• eine offizielle Richtlinie gegen einen beiläufigen Kommentar in einer Besprechung
• eine bereits gelöste Widersprüchlichkeit gegen eine noch offene
• ein Mangel in den Aufzeichnungen gegen eine Entscheidung, die noch niemand getroffen hat

Daneben gibt es benannte Verantwortliche, Überprüfungsverfahren, Verweise auf Quellen, Regeln zur Aktualität, Zugriffsbeschränkungen sowie einen Überblick darüber, welche Änderungen ein Agent vorgenommen hat. Die Wissensbasis eines Einzelnen kann mit Unklarheiten umgehen, weil der Verantwortliche sich daran erinnert, was fehlt. Eine gemeinsame Unternehmensstruktur darf niemals zulassen, dass ein beiläufiger Kommentar stillschweigend zu einer genehmigten Entscheidung wird.

Deshalb ist das Schema wichtig. Es dient mehr als nur dem Benennen von Ordnern und Dateien. Durch es lernt der Agent, wie das Unternehmen das Wissenswerte kodiert. Metadaten auf einer einzelnen Wiki-Seite könnten wie folgt aussehen:

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

Es ist einfach, einen Agenten dazu zu bringen, Markdown auszugeben. Schwierig ist es, festzulegen, was er als organisatorische Wahrheit betrachten soll.

Eine fiktive Firma als Testumgebung

Ein öffentliches Software-Repository bietet nicht genügend organisatorische Komplexität für diese Frage. Ein ordentlich strukturiertes Repository kann die Aufnahme von Inhalten, das Verknüpfen sowie grundlegende Anfragen bewältigen, enthält aber nicht von Natur aus wechselnde Kundenanforderungen, Meinungsverschiedenheiten zwischen Beteiligten, informelle Notizen, überholte Architekturen oder Quellen mit ungleicher Autorität.

Um das zu umgehen, entwickelte das Experiment das Projekt Cedar: eine fiktive Zusammenarbeit, bei der Northstar AI Consulting für Prairie Health Network tätig ist. Alles daran ist erfunden. Die Beratungsfirma baut ein System, das Richtliniedokumente sowie Aufzeichnungen von Qualitätsprüfungen in Entwurfszusammenfassungen umwandelt, die mit ihren Quellen verknüpft sind, sowie eine interne Suchfunktion bietet. Dieses Szenario spiegelt reale Bedenken wider, wie beispielsweise vertrauliche Daten, lokale versus Cloud-Berechnungen, menschliche Überprüfung, Modellbewertung, Architekturauswahl, Nachvollziehbarkeit der Quellen sowie ständig wechselnde Anforderungen.

Das synthetische Korpus enthält 25 anfängliche Markdown-Dokumente. Im wirklichen Leben würden diese in vielen Formaten vorliegen, doch der Test akzeptiert diesen Kompromiss. Zu den Inhalten gehören Hintergrundinformationen zu den Unternehmen, die Richtlinien und Anforderungen des Kunden, Architekturentscheidungen, Protokolle von Besprechungen, Bewertungen der Modelle, Aufzeichnungen der Implementierungsarbeiten, Statusberichte sowie Risikoeinträge.

Eine zweite Gruppe von acht späteren Dokumenten verändert das Projekt. Die Sicherheitsanforderungen verschärfen sich, eine Bewertung des Modells widerlegt eine frühere Annahme, die Akzeptanzkriterien ändern sich, und eine neue Architekturentscheidung ersetzt das ursprüngliche Design, während ein informelles Besprechungsprotokoll weiterhin Teile des alten Designs beschreibt. Diese Änderungen prüfen, ob eine Anwendung das gespeicherte Wissen weiterentwickeln kann.

Zwei weitere Dateien existieren ausschließlich für den Evaluator. Eine ist eine Wissenskarte, die die in dem Korpus absichtlich eingefügten Fakten, Entscheidungen, Konflikte und Beziehungen aufzeichnet – sie dient als Quelle der Wahrheit. Die andere ist eine Sammlung von Bewertungsfragen mit erwarteten Antworten und erforderlichen Quellenbelegen, die dazu dienen, herauszufinden, ob das Wissen korrekt aktualisiert wurde. Der Wiki-Wartungsagent darf sie während des Aufbaus auf keinen Fall sehen, weshalb der Test zeigt, ob er tatsächlich das Wissen des fiktiven Unternehmens rekonstruiert hat und nicht lediglich eine überzeugend klingende Wiki-Seite erstellt hat.

Ein Experiment, das fehlschlagen kann

Das geplante Protokoll hat zwei Phasen.

In Phase A erhält der Agent den initialen Korpus und erstellt die erste Markdown-Wiki. Er muss angeben, was das Unternehmen entwickelt, welche Einschränkungen das System betreffen, die Begründung für die ursprüngliche Architektur, welche Risiken weiterhin bestehen, welche Entscheidungen noch ungetroffen sind und welche Quellen jede Antwort stützen. Die Wiki-Seiten sowie deren Antworten werden gespeichert, bevor weitere Belege auftauchen.

In Phase B wird der aktualisierte Korpus freigegeben. Nun muss der Agent jede betroffene Seite überarbeiten, ersetzte Entscheidungen als Historie beibehalten, offene Meinungsverschiedenheiten sichtbar machen und der Versuchung widerstehen, das neueste Dokument als endgültige Entscheidung zu betrachten. Der Git-Diff wird anschließend ebenfalls zu einem Beweismittel: Er zeigt an, ob das vorhandene Wissen kohärent erhalten blieb oder lediglich durch eine weitere Zusammenfassung ersetzt wurde.

Das war das vollständige Protokoll. Die erste eigentliche Umsetzung wählte einen anderen Weg, da sie im Rahmen eines anderen Experiments entwickelt wurde, bei dem ein KI-Agent während einer langen Autofahrt ein Softwareprojekt erstellte.

Die erste Version

Die erste Cedar-Version entstand aus diesem Fahrexperiment, deren Details hier unerheblich sind. Entscheidend ist das, was der Agent lieferte. Seine Eingaben stammten aus dem Cedar-Korpus, Anweisungen für das Projekt sowie ein Bewertungssatz, der vor seinen Augen verborgen blieb. Das verwendete ChatGPT-Projekt beschränkte die Hochläader auf 25 Dateien, sodass nur acht der ursprünglichen Artefakte beim Agenten anlangten. Der Korpus mit den Änderungen wurde zurückgehalten, um später als Test dafür bereitgestellt zu werden, ob der Agent Änderungen in die Dokumente übernehmen konnte.

Was zurückkam, war ein lokales Kommandozeilenprogramm, das in Python geschrieben war. Es las Markdown-Quellen sowie deren Frontmatter, extrahierte Beweise, die mit den genauen Zeilen markiert waren, aus denen sie stammten, und bewertete die Glaubwürdigkeit einer Quelle unabhängig vom Veröffentlichungsdatum. Dokumente mit expliziten Versionen wurden als aktuell oder historisch gekennzeichnet. Das Tool konnte außerdem einen Markdown-basierten Wissensbericht erstellen, Beweise zu einer Frage abrufen sowie die Struktur des Wikis auf Fehler überprüfen. Die Quelldokumente lagen getrennt von dem erzeugten wiki/-Ordner, und das Repository speicherte die Wartungsanleitungen, Ausführungsprotokolle, Bewertungsmaterialien sowie Ausgaben an eigenen Stellen. Alle 26 Tests bestanden. Es handelte sich um eine funktionsfähige Erstversion, obwohl das verkleinerte Korpus nur einen Teil des Cedar-Protokolls testen ließ.

Kann es das Wissen des Unternehmens bewahren?

In der eingeschränkten Bewertung erzielte das System 50 Prozent. Es war gut darin, Beweise zu speichern: Quellenangaben sowie Angaben zum Herkunftsort auf Zeileebene zeigten genau an, wo die extrahierten Fakten stammten. Die Schwierigkeit lag darin, den richtigen Beweis zu finden und zu lesen, wenn eine realistische Frage gestellt wurde.

Eine echte unternehmerische Frage kann erfordern, Fakten aus mehreren Dateien zusammenzufügen, eine genehmigte Entscheidung einer beiläufigen Notiz vorzuziehen, zu erkennen, dass ein neueres Dokument möglicherweise weniger Autorität hat, eine offene Frage von einer Lücke in den Aufzeichnungen zu unterscheiden sowie Unsicherheit beizubehalten, solange keine endgültige Entscheidung getroffen wurde. Die Beweissicherung erwies sich als wichtiger als die Auswahl von Beweismitteln. Die strukturelle Prüfung erkannte mechanische Mängel wie fehlende Metadaten oder ein fehlerhaftes Layout, doch semantische Konflikte entgingen leichter, da zwei Dokumente in unzusammenhängenden Formulierungen widersprüchliche Ansichten enthalten konnten und das System den Konflikt nicht immer erkannte.

Kurz gesagt wurden Zitate übernommen, ohne zu erkennen, welche von ihnen Gewicht haben. Für das Unternehmenswissen ist das eine echte Schwäche, denn eine gut zitierte Antwort kann dennoch falsch sein, wenn sie auf einer Quelle mit geringer Autorität beruht, eine später genehmigte Entscheidung ignoriert oder Fakten zusammenfügt, die nicht zueinander passen.

Auch das unvollständige Korpus beschränkt die Schlussfolgerungen. Der Agent erhielt niemals das aktualisierte Korpus, wodurch in diesem Test nicht der schwierigste Teil des ursprünglichen Designs überprüft werden konnte: die Aktualisierung des aktuellen Wissens nach Änderungen autoritativer Quellen, während der alte Zustand als Historie beibehalten wird. Die vorläufige Antwort lautet, dass ein Agent eine strukturierte, mit Quellen verknüpfte Darstellung des Unternehmenswissens erstellen kann, es aber bisher noch nicht ausreichend Belege dafür gibt, dass er dieses Wissen im Laufe der Veränderungen des Unternehmens zuverlässig aufrechterhalten kann.

Die Wiki benötigt eine Unternehmensoberfläche

Das Experiment hat außerdem einen Punkt zur Architektur verdeutlicht. Obsidian eignet sich gut zum Überprüfen von generiertem Markdown, zum Verfolgen von Links, zum Prüfen von Metadaten und zur manuellen Korrektur einer Seite. Das reicht aus für eine persönliche Einrichtung oder ein Prototyp, doch kein Unternehmen kann jedem Mitarbeiter und Agenten direkten Zugriff auf einen einzigen Datenspeicher gewähren. Zwischen der Markdown-Wiki und ihren Nutzern benötigt ein echtes System eine Zwischenschicht, die Folgendes abdecken sollte:

• Die Anmeldung wird vom Identitätsanbieter des Unternehmens gesteuert
• Zugriffsregeln, die an Nutzer, Teams, Projekte und Rollen gebunden sind
• Unterschiedliche Identitäten mit eigenen Rechten für jeden Agenten
• Ein Überprüfungs- und Freigabeschritt für jede von einem Agenten vorgeschlagene Änderung
• Suchergebnisse, die danach gefiltert werden, was der Anfragende sehen darf
• Kommentare, Benachrichtigungen und Eigentumsverhältnisse
• Gleichzeitige Änderungen und Versionskonflikte
• Ein Audit-Trail, der angeben kann, wer oder was jede Seite geändert hat

Retentions- und Löschrichtlinien

Eine Benutzeroberfläche, die auch nicht-technisches Personal tatsächlich nutzen kann

Die Authentifizierung bestimmt, wer die Anfrage stellt, während die Autorisierung entscheidet, auf welche Ressourcen – wie Quellen, Seiten und Aktionen – diese Identität Zugriff hat. Auch Agenten unterliegen dieser Einteilung. Der Agent eines Finanzteams sollte nicht einfach auf klinische Unterlagen zugreifen können, nur weil beide Datensätze in derselben Wiki gespeichert sind; daher benötigen Agenten eigene Service-Identitäten, eingeschränkte Berechtigungen sowie die gleichen Prüfpflichten wie Menschen. Die Berechtigungen müssen außerdem dem Informationsfluss folgen, wenn ein Agent diese verändert: Eine aus einem öffentlichen Architekturdokument erstellte Projektübersicht sowie eine eingeschränkte Sicherheitsprüfung könnten sogar dann sensible Details offenbaren, wenn die Seite unbedenklich erscheint.

Obsidian kann weiterhin als Arbeitsplattform für Wartungsmitarbeiter und technische Prüfer dienen, während die meisten Mitarbeiter über eine Wiki-Website oder ein internes Portal auf dieses Wissen zugreifen. Dabei wird dasselbe Wissen über einen kontrollierten Dienst abgerufen, ohne eine weitere Kopie anzufertigen. Die Architektur besteht somit aus vier Teilen:

1. Evidenzschicht: unveränderliche Unternehmensquellen mit ihren ursprünglichen Berechtigungen
2. Wissensschicht: die durch Git unterstützte Markdown-Wiki sowie ihre Quellbeziehungen
3. Kontrollschicht: Identitätsmanagement, Berechtigungen, Überprüfungsprozesse, Prüfungsprotokolle und Suchfunktionen
4. Schnittstellenschicht: Obsidian für die Personen, die die Wiki pflegen, eine Unternehmens-Wiki-Website für Mitarbeiter sowie eingeschränkte APIs für Agenten

Eine Unternehmensschnittstelle dupliziert das Wissen nicht. Sie steuert vielmehr, wie Menschen und Agenten damit interagieren.

Was als Nächstes getestet werden soll

Der nächste Durchlauf sollte das gesamte Cedar-Korpus verwenden: Alle 25 anfänglichen Artefakte einlesen, die ursprüngliche Wiki-Seite bewerten und sie speichern, anschließend die acht Änderungsartefakte einfügen und überprüfen, ob der Agent jede betroffene Seite aktualisiert, alte Entscheidungen als überholt markiert, die aufzubewahrende Historie beibehält, die Regeln der Quellenautorität einhält, ungelöste Meinungsverschiedenheiten sichtbar macht, darauf verzichtet, Entscheidungen vorzunehmen, und einen Git-Diff erstellt, den eine Person überprüfen kann.

Die Abrufleistung sollte auch getrennt von der Wartung bewertet werden. Ein System kann über das richtige Wissen verfügen, aber für eine Frage falsche Informationen abrufen, oder zwar durch Suche in Rohquellen richtig antworten, während seine gewartete Wiki-Datenbank veraltet ist – solche Fälle erfordern unterschiedliche Bewertungen. In einer späteren Phase sollten Benutzer- und Agentenidentitäten zum Korpus hinzugefügt werden, damit Fragen überprüfen können, ob ein autorisierter Prüfer die richtige Antwort erhält, während einem anderen Benutzer Zugang zu eingeschränkten Informationen verwehrt wird. Dadurch rückt das Experiment näher an eine tatsächliche Unternehmensimplementierung heran.

Können Agenten das Wissen eines Unternehmens aufrechterhalten?

Die erste Cedar-Version unterstützt nur eine qualifizierte Antwort. Der Agent lieferte ein funktionsfähiges System, das Dokumente im Stil eines Unternehmens verarbeitete, Quellenangaben speicherte, Dokumentversionen kennzeichnete, eine Markdown-Wiki erstellte und deren Struktur überprüfte. Die Bewertung zeigte anschließend, dass diese Fähigkeiten unzureichend sind, da die Aufrechterhaltung des Unternehmenswissens auch eine sorgfältige Auswahl von Belegen, das Abwägen von Autoritäten, das Erkennen von Konflikten, das Umgang mit Unsicherheiten sowie Kontrollmechanismen für Überprüfung und Zugriff erfordert.

Markdown kann als gemeinsames Format dienen, doch ein Unternehmen benötigt dennoch eine regulierte Schnittstelle dazu. Sowohl Menschen als auch Agenten benötigen Identitäten, Berechtigungen müssen von der ursprünglichen Quelle zu den generierten Seiten übertragen werden, Änderungen durch Agenten müssen geprüft werden und jede angenommene Änderung benötigt eine Historie. Die Erstellung der Wiki-Seiten war der einfachere Teil. Was echte Anstrengungen erfordert, ist die Entscheidung darüber, was das Unternehmen als Wissen anerkennt, wer es einsehen darf und wie Agenten dazu autorisiert sind, es zu ändern.