Das Notizen-Setup, das wirklich mit KI funktioniert

Ich war lange Zeit Microsoft OneNote-Nutzer. Mehr als zehn Jahre. Ich kann mir nicht einmal annähernd vorstellen, wie viele Notizen ich in dieser Zeit angesammelt hatte — Besprechungsnotizen, Projektrecherchen, Code-Snippets, zufällige Ideen. Ein Jahrzehnt Denken, festgehalten in einem proprietären Format auf Microsofts Servern.

Als Entwickler kannte ich das Prinzip für gutes Datenmanagement: Inhalt und Konfiguration in derselben Datei halten. Portabel halten. Die Daten nicht von Tools als Geisel nehmen lassen. Ich kannte dieses Prinzip. Ich wendete es im Code an. Und dann ignorierte ich es bei meinen eigenen Notizen vollständig — für über ein Jahrzehnt.

Ich machte schließlich den Wechsel — zu Markdown-Dateien und konkret zu Obsidian. Was mich überraschte, war das Timing. Ich wechselte, bevor die aktuelle KI-Welle aufkam. Ich war kein Trendjäger. Ich handelte endlich nach etwas, das ich bereits glaubte.

Was ich nicht ahnte, war, wie richtig diese Entscheidung sein würde — und aus Gründen, die nichts mit persönlicher Produktivität zu tun hatten, sondern alles damit, wie KI-Agenten tatsächlich funktionieren.

---

Die Cloud-Produktivitätsära hat eine Wette gesetzt, die nicht aufgegangen ist

Notion, Confluence, Evernote, Roam — die Geschichte des letzten Jahrzehnts im Wissensmanagement drehte sich darum, das Dateisystem zu abstrahieren. Deine Notizen lebten in einer Datenbank. Du bekamst eine schöne Oberfläche, Kollaborationsfunktionen und das Gefühl, organisiert zu sein. Was du aufgabst, war die Kontrolle.

Versuch mal, einen Notion-Workspace zu exportieren. Du bekommst eine ZIP-Datei voller HTML mit eingebetteten Metadaten. Versuch, sie mit grep zu durchsuchen. Versuch, einem KI-Agenten Zugang dazu zu geben, ohne Notions API zu nutzen. Versuch, sie in irgendeinem sinnvollen Sinne zu besitzen, wenn Notion seine Preise ändert.

Obsidian ging in die andere Richtung. Deine Notizen sind Dateien, in einem Ordner, auf deinem Rechner. Die Anwendung ist ein Objektiv, kein Behälter. Öffne eine beliebige Notiz in vim, in VS Code, in jedem Texteditor, der je existiert hat. Durchsuche deinen gesamten Vault in Millisekunden. Leite Notizen durch Skripte. Synchronisiere sie, wie du möchtest — iCloud, Syncthing, git, ein USB-Stick. Die Daten gehören dir.

Das erweist sich als enorm wichtig, wenn du möchtest, dass ein KI-Agent mit deinem Wissen arbeitet.

---

Warum Markdown KI-nativ ist

Markdown ist nicht nur für Menschen lesbar. Es befindet sich an einem bestimmten Sweet Spot: strukturiert genug für Maschinen, flexibel genug für Menschen. Hier werde ich ein bisschen nerdig, aber bleib bei mir. Wenn du den Fachjargon nicht verstehst, ist die zugrunde liegende Logik trotzdem nachvollziehbar. Die Prinzipien gelten unabhängig davon. Jede Eigenschaft, die Markdown gut für Menschen macht, macht es auch gut für KI:

Klartext bedeutet, dass jedes Tool es lesen kann. Keine Parser-Bibliotheken, keine API-Aufrufe, keine Formatverhandlung. Ein Sprachmodell kann eine Markdown-Datei genauso lesen wie du.

YAML-Frontmatter bedeutet, dass maschinenlesbare Metadaten in derselben Datei wie der Inhalt leben. Tags, Beziehungen, Daten, benutzerdefinierte Eigenschaften — sie reisen mit der Notiz. Keine separate Datenbank, keine Sync-Probleme, kein "die Metadaten sind hier, aber der Inhalt ist irgendwo anders"-Problem. Das ist die goldene Regel: Daten und Metadaten in derselben Datei. Markdown mit Frontmatter ist genau das.

Wikilinks sind explizite, benannte Beziehungen zwischen Dokumenten. Nicht nur Hyperlinks — semantische Verbindungen. [[Parent Note]], [[Related Concept]]. Ein Wissensgraph kann diese traversieren. Ein KI-Agent kann ihnen folgen. Sie sind mehr als Navigation; sie sind deklarierte Struktur.

Header als Struktur geben KI-Systemen natürliche Chunking-Grenzen. Wenn du eine RAG-Pipeline über deine Notizen aufbaust, werden die ##-Abschnitte zu kohärenten Retrieval-Einheiten. Die Dokumentstruktur, die du für dich selbst geschrieben hast, wird zur Dokumentstruktur, die die KI nutzt, um das Relevante zu finden.

Vergleiche das mit einem Notion-Export (HTML-Suppe), einer Confluence-Seite (proprietäres JSON) oder einem Word-Dokument (XML-ZIP-Datei). Wenn du möchtest, dass ein KI-Agent über dein akkumuliertes Wissen nachdenkt, gewinnt Markdown in jeder Dimension.

---

Das Ökosystem ist ungewöhnlich tief

Obsidian hat rund 1.500 Community-Plugins. Die Zahl ist weniger interessant als das, was diese Plugins zugänglich machen.

Bemerkenswert ist, wie tief Plugins in Obsidian eindringen können. Ein Plugin ist nicht darauf beschränkt, das Aussehen der App zu ändern oder einen Button zur Symbolleiste hinzuzufügen. Es kann alle deine Notizen und die Verbindungen zwischen ihnen lesen und traversieren, die an jede Notiz angehängten Metadaten aufrufen und ändern, benutzerdefinierte Links erstellen, auf die andere Anwendungen reagieren können, und Dateien direkt auf deinem Computer lesen und schreiben. Die meisten Anwendungen geben Entwicklern ein enges Fenster, mit dem sie arbeiten können. Obsidian gibt ihnen die Schlüssel zum Gebäude. Das Ergebnis ist, dass das Plugin-Ökosystem Obsidian wie eine Plattform behandelt, auf der man aufbaut, nicht wie eine Anwendung, die man benutzt.

Und weil alles Dateien sind, komponieren diese Plugins. Ein Plugin, das in Frontmatter schreibt, funktioniert mit einem Plugin, das Frontmatter liest. Ein Plugin, das Links hinzufügt, funktioniert mit einem Plugin, das Links traversiert. Nichts ist in seiner eigenen Datenbank isoliert. Die Datei ist der Vertrag zwischen den Komponenten.

---

Local-first ist der KI-Datenschutz-Move

Wenn du deine Notizen an eine KI weitergibst, gibst du ihr dein tatsächliches Denken weiter. Nicht deine polierte Ausgabe — dein tatsächliches Denken. Unsicherheiten, halbfertige Ideen, persönliche Projekte, Dinge, die du über deinen Arbeitgeber weißt, Meinungen, die du noch nicht veröffentlicht hast.

Local-first bedeutet, dass du kontrollierst, was wohin geht. Deine Notizen trainieren standardmäßig nicht das nächste Modell von OpenAI. Du kannst lokale Modelle gegen deinen gesamten Vault laufen lassen, ohne dass Daten dein Gerät verlassen. Ein KI-Agent, der lokal läuft, hat Zugriff auf das Dateisystem ohne einen Roundtrip durch die Cloud. Du kannst pro Modell und pro Aufgabe entscheiden, welchen Kontext du bereitstellst.

Das ist keine Paranoia. Es ist dasselbe Prinzip der operationellen Sicherheit, das für alle sensiblen Daten gilt. Du triffst bewusste Entscheidungen darüber, was deine Kontrolle verlässt, anstatt dass diese Entscheidung durch ein Update der Nutzungsbedingungen für dich getroffen wird.

---

Das Agenten-Interface-Muster

Etwas Subtiles geschieht in der Art und Weise, wie KI-Agenten ihre Beziehung zum menschlichen Kontext strukturieren — und es lohnt sich, darauf zu achten.

Claude Code speichert seine dauerhaften Anweisungen in CLAUDE.md. Es speichert Erinnerungen über den Nutzer in memory/*.md-Dateien. Wiederverwendbare Agentenverhaltensweisen sind in .claude/skills/*.md definiert. Nichts davon ist eine Datenbank, eine API oder ein proprietäres Format. Es sind alles Markdown-Dateien.

Das ist nicht willkürlich. Markdown ist das richtige Medium für diese Schnittstelle, weil es sowohl für den Menschen als auch für die KI lesbar ist, strukturierte Daten neben Prosa enthalten kann, versionskontrolliert werden kann und keine Infrastruktur zum Lesen oder Schreiben benötigt.

Dein Obsidian-Vault ist bereits so strukturiert — oder kann es sein. Notizen mit Frontmatter-Eigenschaften, Wikilinks, die Beziehungen deklarieren, Tags, die Kategorien kodieren. Wenn du die richtigen Tools darüber legst (MCP-Server, Vektorsuche, RAG), wird deine gesamte Wissensbasis für jeden KI-Agenten, mit dem du arbeitest, abfragbar. Der Vault wird zum Context Window.

---

Aber es gibt eine Lücke

Was Obsidian nativ nicht löst: außerhalb des Vaults zu greifen.

Der Vault kennt deine Notizen. Er kennt nicht deine Projektverzeichnisse, deine Code-Repositories, deinen Downloads-Ordner, deine PDF-Bibliothek. Jedes Tool, das keine Markdown-Datei innerhalb des Vaults ist, ist für ihn unsichtbar. Jedes Mal, wenn du eine Notiz mit einem Projektverzeichnis verbinden möchtest, löst du dieses Koordinationsproblem manuell.

Das ist die Einschränkung, die mich dazu gebracht hat, FolderTether zu bauen — aber das ist das Thema des nächsten Beitrags.

---

Ergänzung: Wie du deine Notizen organisierst

Dieser Abschnitt richtet sich an Leser, die neu bei Obsidian sind oder den organisatorischen Ansatz verstehen möchten, der dem oben beschriebenen System zugrunde liegt. Es ist ein praktischer Ausgangspunkt, keine Voraussetzung für den Hauptartikel. Einfach ein Bonus!

---

Die wichtigste Umstellung bei der guten Nutzung von Obsidian ist, Ordner als primäres Organisationswerkzeug aufzugeben.

Ordner sind die Art, wie die meisten von uns gelernt haben, Dateien zu organisieren. Sie fühlen sich intuitiv an. Aber in einem Wissenssystem schaffen sie Probleme: Eine Notiz kann nur in einem Ordner leben, Ordner erscheinen nicht in der Graphenansicht, und eine Ordnerhierarchie wird zu einer Entscheidung, die du im Voraus treffen und dann damit leben musst.

Obsidian gibt dir bessere Werkzeuge: Tags, Links und Properties.

Die goldene Regel

Speichere deine Daten und deren Metadaten in derselben Datei. Verwende YAML-Frontmatter am Anfang jeder Notiz, um strukturierte Informationen zu erfassen — Tags, Daten, Beziehungen, Quellenverweise. Das macht deine Notizen für dich und für jedes KI-Tool, das du verwendest, abfragbar.

---
tags:
  - knowledge/ai/rag
  - goal/project/my-project
created: 2026-03-13
up: "[[Parent Note]]"
source: "[[Reference Material]]"
---

Tags statt Ordner

Tags sind flexibler als Ordner, weil eine Notiz mehrere Tags haben kann. Verwende hierarchische Tags für die Struktur — knowledge/ai/rag ist präziser als knowledge und flexibler als eine verschachtelte Ordnerstruktur.

Platziere Tags im Frontmatter statt inline im Text. Das hält deinen Notizinhalt sauber und macht Tags einfacher abfragbar.

Links als deklarierte Beziehungen

Wikilinks ([[Note Name]]) sind Obsidians mächtigstes Feature. Verwende sie bewusst:

• Benannte Links in Properties für starke, explizite Beziehungen: up: "[[Parent Note]]", source: "[[Reference]]"
• Inline-Wikilinks für kontextuelle Verbindungen im Körper einer Notiz
• Obsidian verfolgt alle Links und aktualisiert sie automatisch, wenn Notizen umbenannt werden — keine defekten Referenzen

Die Graphenansicht wird nützlich, wenn du echte Links hast, die echte Notizen verbinden. Es ist eine Karte deines Denkens, nicht nur eine Visualisierung deiner Ordnerstruktur.

Properties für Struktur

Properties (Frontmatter-Felder) lassen dich deinen Vault wie eine leichtgewichtige Datenbank behandeln. Über Tags hinaus überlege:

• up — die primäre aufwärts gerichtete Beziehung (wozu diese Notiz gehört)
• sibling — laterale Beziehungen auf derselben Ebene
• source — woher die Information stammt
• archive: true — Notizen als inaktiv markieren, ohne sie zu löschen

Eine Anmerkung zu PARA

PARA (Projects, Areas, Resources, Archives) ist ein beliebtes Organisationsframework, dem du in Obsidian-Inhalten begegnen wirst. Es lässt sich gut auf Tags abbilden: goal/project/..., area/..., knowledge/.... Verwende es, wenn es zu deiner Denkweise passt. Das Entscheidende ist, dass PARA besser als Tagging-System funktioniert als als Ordnerhierarchie.

---

Das Video, das diesen Ansatz geprägt hat: https://www.youtube.com/watch?v=B0yAy2j-9V0