Ein persönliches Notizsystem stößt mit wachsendem Umfang irgendwann an seine Grenzen, heißt es. Dann brauche es eine Datenbank oder ein klassisches Wiki. Der Beitrag, um den es hier geht, dreht die Reihenfolge um: Er nimmt einen Obsidian-Vault aus einfachen Markdown-Dateien als Ausgangspunkt und beschreibt, welche Mechanismen daraus ein Unternehmens-Gehirn machen. Interessant ist weniger die Technik als die Reihenfolge der Probleme. Nicht die Zahl der Notizen ist der Engpass, sondern die Frage, wer wann was schreiben darf und wie eine Änderung geprüft wird.
Der Autor des Originalbeitrags, der den Text nach eigener Angabe im Rahmen seiner Beratungstätigkeit geschrieben hat, nutzt seit vielen Jahren ein persönliches Zweitgehirn. Er begann mit OneNote und wechselte wegen der Verlinkungsfunktion zu Obsidian; heute verwaltet er darin private Notizen, aber auch sein Einzelunternehmen samt CRM. Sein Rat: Setz auf ein offenes Dateiformat wie Markdown, damit dein Wissen nicht an ein einzelnes Werkzeug gebunden bleibt. Als Einzelperson bekommst du so ein System, das Jahrzehnte überdauern kann.
Was ein persönlicher Obsidian-Vault leistet und wo seine Grenzen liegen
Ein solches System erfüllt mehrere Aufgaben gleichzeitig. Es sammelt Wissen zum langfristigen Behalten, dient als Ort für Ideen und Texte, verbindet Notizen untereinander, um Zusammenhänge sichtbar zu machen, und liefert Vorlagen für wiederkehrende Notizstrukturen. Dazu kommen Anbindungen an Erfassungswerkzeuge wie den Obsidian Web Clipper, mit dem Inhalte aus dem Netz direkt im Vault landen. All das lässt sich mit verlinkten Notizen abbilden, egal ob mit Obsidian, Logseq oder einem anderen Werkzeug. Der Graph ist nur der sichtbare Teil dieser Arbeit.
Die Grenzen zeigen sich erst, wenn man genau hinsieht. Mehrbenutzerfähigkeit gibt es praktisch nicht, weil lose Markdown-Dateien nicht für gleichzeitiges Schreiben gebaut sind – dafür bräuchte man Mechanismen wie CRDTs oder einen anderen Weg zur Synchronisation. Der Graph kennt außerdem keine Typen, es gibt also keine Garantie, dass ein Datum ein Datum bleibt und eine Telefonnummer nicht irgendwann als freier Text endet. Die Inhalte sind Freitext, und die Beziehungen zwischen Notizen tragen nur wenig Semantik. Der Autor verweist hier auf Sergei Simonovi, der von Reibungspunkten spricht, sobald sehr viele Notizen zusammenkommen.
Bei tausenden Notizen geht das noch. Bei Millionen braucht es einen Index für schnelle Abfragen, dazu Embeddings und Clustering, um Ähnliches zu finden. Und einen Umgang mit Daten aller Art: Text, CSV, JSON, Schnittstellen. An diesem Punkt endet das persönliche System und beginnt Unternehmenswissensmanagement.
Warum Unternehmenswissensmanagement dieselben Fragen in größerem Maßstab stellt
Die Anforderungen wiederholen sich. Ein Unternehmen will die Umsatzzahlen des letzten Monats abrufen, aus einem sich ständig ändernden Umfeld lernen – neue Gesetze, neue Datenquellen – und dieses Wissen intern wie extern teilen. Das sind dieselben Aufgaben wie bei einem persönlichen Gehirn, nur in anderer Größenordnung. Der Unterschied liegt in der Zahl der Beteiligten und in der Komplexität der Daten. Aus Copy-and-Paste werden Datenpipelines und ein Data Warehouse.
Hinzu kommen zwei Forderungen, die im Einzelbetrieb kaum eine Rolle spielen: Automatisierung und Governance. Ein gutes Beispiel ist das CRM. Dort sammeln sich Kundeninformationen, Angaben aus Verkaufsgesprächen, der letzte Kontakt, die aktuelle Einschätzung, ob ein Interessent heiß, warm oder kalt ist. Solche Zustände ließen sich automatisch pflegen, wenn Notizen von Vertriebsmitarbeitern, freigegebene Telefonprotokolle oder Dokumente kontinuierlich ausgewertet werden. Dafür braucht es Agenten.
Der Autor erwähnt in diesem Zusammenhang einen kurzen Beitrag von Andrej Karpathy über ein selbstkuratierendes LLM-Wiki, das viral ging. Es zeigt, was für eine kleine, automatisch aktualisierte Wissenssammlung möglich ist. Für Unternehmen reicht es nicht, weil weder ein Prüfprozess noch eine Versionierung vorgesehen ist. Ohne diese beiden Elemente bleibt ein automatisch wachsendes Wiki ein Experiment.
KI-Agenten schreiben auf eigenen Branches
Agenten sind gut darin, Informationen in beliebigen Formaten zu erfassen. Sie können definierte Orte lesen, Kundenstämme täglich aktualisieren, Anrufe und Dokumente einlesen und Verträge den passenden Kunden zuordnen. Das ist der Zulieferteil der Arbeit, und er läuft autonom. Spannender ist die Frage, wie Agenten neue Inhalte in das Gehirn schreiben, ohne es zu beschädigen.
Die Antwort des Autors: mit Branches. Wenn hunderte Agenten gleichzeitig Wissen hinzufügen, laufen sie sich sonst gegenseitig über den Weg. Jeder Agent bekommt deshalb seine eigene Kopie, schreibt dort und schlägt seine Änderung anschließend zur Übernahme in den Hauptzweig vor – im Prinzip wie ein Pull Request bei GitHub. Nichts landet in der echten Version, bevor es freigegeben wurde. Menschen können Merges ablehnen oder später zurücknehmen, und es bleibt eine vollständige Historie darüber, wer was geändert hat.
Der zweite Grund für Branches ist genauso wichtig wie der erste. Ohne Prüfung driftet ein von Agenten gefüttertes Unternehmens-Gehirn innerhalb weniger Wochen in Rauschen ab. Eine falsch geänderte Telefonnummer oder ein halluzinierter Deal-Status genügen, damit niemand dem System noch traut. Mit Branches lässt sich gleichzeitig parallel arbeiten, auch an lang laufenden Aufgaben, und trotzdem bleibt der Hauptzweig konsistent. Versionierung und Nebenläufigkeit kommen so in einem Mechanismus zusammen.
Objekt-Storage, typisierte Graphen und die Frage nach Ontologien
Unter alldem braucht es einen Speicherort, an dem Daten geschrieben, versioniert und gelesen werden können. Der Autor empfiehlt Objekt-Storage, weil er günstig und schnell eingerichtet ist und weil er offene Formate wie Apache Parquet erlaubt, bei Bedarf ergänzt um offene Tabellenformate mit Datenbankfunktionen darüber. Jeder mit den passenden Rechten kann lesen, und es gibt keinen Datenbankserver, der laufen muss. Das gesamte Gehirn ist im Kern eine Sammlung von Dateien.
Damit Agenten konsistent schreiben, kommt ein typisierter Graph ins Spiel. Verlinkt wird wie in Obsidian, aber jeder Knoten und jede Kante hat einen definierten Typ. Diese Typen wirken wie Datenverträge: Sie sagen dem Agenten, wie er speichern und wie er wieder abrufen soll. In der Vorstellung des Autors sind Dots die Dinge – eine Person, ein Unternehmen, ein Deal – und Lines die Verbindungen dazwischen, etwa dass jemand eine Firma gegründet hat. Typisiert bedeutet, dass es Regeln gibt, vergleichbar mit einem Formular mit Pflichtfeldern statt eines leeren Notizbuchs, in das jeder schreibt, was ihm gerade einfällt.
Der Unterschied zwischen einem deklarierten Graph-Link und einem Embedding ist zentral: Der Link ist eine Aussage, die jemand bewusst gesetzt hat, das Embedding eine Ähnlichkeit, die das Modell vermutet. Ein Unternehmens-Gehirn, das beides hält, kann nach Bedeutung und nach typisierten Beziehungen suchen, nicht nur nach Vektorähnlichkeit. Der Autor sieht darin eine Fortsetzung dessen, was früher Master Data Management leisten sollte, damals mit Excel und menschlicher Pflege – und mit Domänenexperten als Flaschenhals, die ohnehin ausgelastet waren. Agenten können diesen Prozess beschleunigen, wenn die Dokumentation gepflegt und aktuell ist. Wahrheit bleibt dabei relativ: Widersprüche zwischen einer Notiz und einem Protokolleintrag dürfen sichtbar werden, und Menschen können jederzeit eingreifen. Über Ontologien lässt sich zusätzlich Weltwissen modellieren und mit den Unternehmensdaten verbinden, was die Qualität der Antworten erhöht.
CRM mit mehreren Agenten: Kontext lesen, zurückschreiben, Konflikte lösen
Am Ende vergleicht der Beitrag zwei Welten anhand von zwei Beispielen. Auf der einen Seite das persönliche Gehirn mit Obsidian, in dem eine Person ihre Kunden, Notizen und Dokumente verwaltet. Auf der anderen Seite ein Company Brain mit einem System wie OmniGraph, in dem mehrere Agenten und mehrere Menschen gleichzeitig arbeiten. Der Autor zeigt, wie Agenten und Nutzer Kontext herauslesen, wie Ergebnisse zurück ins CRM geschrieben werden, wie automatische Merges ablaufen und wie Konflikte behandelt werden, wenn zwei Quellen unterschiedliche Aussagen treffen.
Die Beispiele teilen dieselbe Denkweise und unterscheiden sich nur im Maßstab. Was im Einzelbetrieb eine Notiz mit zwei Wikilinks ist, wird im Unternehmen zu einem typisierten Knoten mit Beziehungen, Versionen und Prüfschritten. Der Autor betont, dass ein solches System kein statisches Produkt ist. Es ist ein fortlaufender gemeinsamer Verständnisprozess, an dem Agenten und Belegschaft gleichermaßen beteiligt sind.
Was das für Unternehmen konkret bedeutet
Die praktische Konsequenz ist ernüchternd und befreiend zugleich. Es geht nicht darum, Obsidian einzukaufen oder ein Werkzeug auszutauschen, sondern drei Fähigkeiten nachzurüsten: gleichzeitiges Schreiben mit Versionierung, typisierte Datenverträge und eine offene, günstige Speicherschicht. Wer nur die erste Fähigkeit umsetzt, bekommt Chaos in Zeitlupe. Wer nur auf Typen setzt, verliert die Prüfinstanz. Erst im Zusammenspiel bleibt ein automatisch aktualisiertes Unternehmens-Gehirn über Monate vertrauenswürdig.
Für dich als Verantwortliche heißt das, den Aufwand nicht bei der Erfassung zu veranschlagen, sondern beim Prüfen und beim Speicherformat. Der Mensch verschwindet nicht aus dem Prozess, er wandert nur an eine andere Stelle: Er entscheidet, welche Änderungen in den Hauptzweig dürfen. Das ist weniger glamourös als ein autonomer Agent, der alles selbst regelt, aber es ist der Unterschied zwischen einem System, dem man nach einem Jahr noch glaubt, und einem, das man dann abschaltet.
Quelle: ssp.sh
