Stand: 15. Mai 2026
KI-Assistenten wie Claude Code und Codex haben ein eingebautes Vergessen. Jede Sitzung beginnt bei null. Was Sie dem Werkzeug gestern erklärt haben, ist heute weg. Was ein Kollege vor zwei Wochen mit ihm abgestimmt hat, weiß es nicht. Für eine einzelne Frage ist das egal. Für einen Betrieb, der ernsthaft mit KI arbeitet, ist es ein Problem. Wir lösen es seit einigen Monaten konsequent mit Obsidian, einem alten Werkzeug, das viele unterschätzen, hier aber zum strukturierten Wissensspeicher zwischen Mensch und KI wird.
Dieser Beitrag beschreibt, wie wir bei der KI-Berater Hamburg Obsidian als zweites Gedächtnis für Claude Code und Codex einsetzen, welche Konventionen sich bewährt haben und warum am Ende sogar die Art, wie eine Notiz abgelegt wird, ein paar Euro pro Monat spart.
Warum ein eigener Wissensspeicher
Es gibt drei wiederkehrende Gründe, weshalb ein zentraler Speicher außerhalb der KI sinnvoll ist.
Erstens Kontinuität. Projekte erstrecken sich über Wochen und Monate. Entscheidungen, offene Punkte, kleine Lernerfahrungen sollen jederzeit wieder auffindbar sein, nicht nur in der Sitzung, in der sie entstanden sind.
Zweitens Mehrere Köpfe. In unserer Arbeit nutzen sowohl Claude Code als auch Codex denselben Wissensstand. Beide Werkzeuge haben unterschiedliche Stärken. Wenn beide dieselben Notizen lesen, müssen wir nichts doppelt erklären.
Drittens Eigentümerschaft am Wissen. Was in einer Chat-Oberfläche entsteht und nirgendwo persistiert wird, ist verloren, sobald der Anbieter etwas an seinen Speicherregeln ändert. Ein Vault auf Ihrem Rechner bleibt Ihnen erhalten, unabhängig vom Anbieter.
Obsidian ist dafür angenehm bescheiden. Es speichert reine Markdown-Dateien in einem Ordner auf dem Dateisystem. Keine Datenbank, kein Cloud-Zwang, kein proprietäres Format. Wer eines Tages wechselt, nimmt seine Dateien einfach mit.
Die Rolle des Vaults im Arbeitsalltag
Unser Vault heißt Mokh2 und liegt unter einem klaren Pfad auf dem Hauptrechner. Er ist nach Themen geordnet, nicht nach Werkzeugen. Es gibt Bereiche für Projekte, für Knowledge, für Tagebuch, für Wartung, für Codex und ai. Die Werkzeuge greifen auf dieselben Inhalte zu, sie haben kein eigenes Revier.
Beim Sitzungsstart wird automatisch eine kleine Startdatei mit dem Namen home.md geladen. Dort stehen die wichtigsten offenen Punkte, Verweise auf Standards, der aktuelle Fokus. Mehr nicht. Unterordner werden nur dann gelesen, wenn ein konkretes Thema das verlangt. Diese Regel hält den Einstieg schnell und vermeidet, dass die KI jedes Mal die halbe Festplatte mitliest.
Während der Arbeit schreiben Claude Code und Codex aktiv in den Vault. Entscheidungen werden mit Vertrauensstufe und Quelle festgehalten. Offene Aufgaben bekommen ein Datum und einen Projektlink. Tageserkenntnisse landen in der Tagebuch-Sektion. Standards und Methodik wachsen im Knowledge-Bereich. Nach drei Monaten konsequenter Pflege liegt dort ein Wissensschatz, der wertvoller ist als jede einzelne Konversation.
Konventionen, die sich bewährt haben
Es lohnt sich, früh ein paar einfache Regeln zu setzen. Ohne sie wuchert ein Vault sehr schnell. Mit ihnen bleibt er auch nach zwei Jahren noch nutzbar.
Frontmatter ist Pflicht. Jede Notiz beginnt mit einem kleinen Kopf, der mindestens Erstellungsdatum, Typ und Tags enthält. Das klingt nach Verwaltungsaufwand, ist aber die Grundlage für jede spätere Auswertung.
Wikilinks statt Pfadnamen. Wer ein Projekt erwähnt, verlinkt es. Wer einen Kunden nennt, verlinkt ihn. Verlinkung kostet nichts und macht den Vault über die Zeit zu einem Graph, durch den man wandern kann.
Tagebuch im Format Jahr, Monat, Tag. Eine Datei pro Tag in einer klaren Ordnerhierarchie. Wochenrückblicke und Monatsrückblicke verweisen automatisch auf die Tage. Diese Disziplin liefert nach einem Jahr eine erstaunlich präzise Chronik der Projektarbeit.
Keine Löschungen ohne Freigabe. Was einmal im Vault steht, bleibt stehen. Erledigte Aufgaben werden abgehakt, nicht entfernt. Diese Regel klingt trivial, sie verhindert aber das Vergessen, das KI-Werkzeuge sonst gern selbst beschleunigen.
README in jedem Ordner. Jede Unterstruktur erklärt sich selbst. Eine README mit Zweck, zentralen Dateien und offenen Pflegepunkten. Wer nach sechs Monaten in einen Ordner zurückkehrt, versteht in einer Minute wieder, was dort vorgeht.
Wo Claude Code und Codex unterschiedlich glänzen
Claude Code und Codex sind beides Coding-Assistenten, aber sie lösen unterschiedliche Probleme besser. In unserer Arbeit hat sich folgende Aufteilung etabliert.
Claude Code ist der Hauptarbeiter. Er führt komplexe Aufgaben aus, plant mehrstufige Vorhaben, schreibt Texte, baut Strukturen, dokumentiert. Sein Stärken sind Tiefenanalyse und ausführliche Arbeit an einer Stelle. Wir nutzen ihn für alles, was länger als zehn Minuten braucht.
Codex ist die Zweitmeinung. Wenn eine Frage strittig ist oder ein Lösungsweg geprüft werden soll, holen wir Codex hinzu. Er hat oft andere Vorlieben in der Lösungsfindung, was bei Architekturentscheidungen wertvoll ist. Wir orchestrieren ihn nicht aus Claude Code heraus, sondern nutzen ihn als bewusst gewählten zweiten Kopf.
Beide schreiben in denselben Vault. Beide lesen aus demselben Vault. Daher ist es unerheblich, in welchem Werkzeug eine Erkenntnis ursprünglich entstanden ist. Sie ist da, sie ist auffindbar, sie ist wiederverwendbar. Wer Obsidian mit Claude Code koppelt, hat damit auch für Codex einen sauberen Einstiegspunkt vorbereitet, ohne doppelte Pflege.
Die Standards-Ebene
Damit das System funktioniert, braucht es eine kleine, aber harte Standards-Ebene. Bei uns liegt sie in einem Ordner unter Knowledge. Dort stehen die verbindlichen Regeln, die für jede Sitzung gelten.
Dazu gehören Frontmatter-Schemata für unterschiedliche Notiztypen, ein Reglement für die Nutzung von MCP-Servern, eine Datenklassen-Matrix mit Modell-Freigaben, ein Release-Phasen-Template mit Go-No-Go-Punkten, eine Hooks-Dokumentation und ein paar Routing-Regeln, die wir gleich noch genauer betrachten.
Diese Standards werden in der globalen Konfiguration der Werkzeuge referenziert. Beim Sitzungsstart sind sie damit automatisch aktiv. Claude Code und Codex verhalten sich folglich konsistent, ohne dass wir die Regeln in jeder Sitzung erneut erklären müssen. Das ist der eigentliche Hebel. Standards in einer einzigen Datei, einmal gepflegt, wirken in jeder Sitzung.
Wann der Vault zu viel Geld kostet
Hier wird es interessant. Wir haben eine Weile gebraucht, um zu bemerken, dass die Art des Schreibens in den Vault selbst Kosten verursacht.
Die KI greift typischerweise über einen sogenannten MCP-Server auf Obsidian zu. MCP steht für Model Context Protocol, ein Standard, der Werkzeugen Zugriff auf externe Systeme erlaubt. Für Obsidian gibt es einen MCP-Server, der per kleiner REST-Schnittstelle Notizen liest und schreibt.
Jeder Aufruf eines solchen Werkzeugs verbraucht Tokens. Tokens sind die Einheit, in der KI-Anbieter abrechnen. Ein Aufruf enthält die Beschreibung des Werkzeugs, die Parameter, das Ergebnis und ein Stück Verwaltungstext. Bei einem einzelnen Aufruf fällt das nicht auf. Wer aber, wie wir, mehrfach am Tag kleine Notizen ablegt, Tagebucheinträge ergänzt, Offene-Punkte-Listen erweitert oder Knowledge-Pages anlegt, merkt es am Ende des Monats.
Die Erkenntnis war einfach. Der Inhalt der Notiz muss von der KI geschrieben werden, das ist der eigentliche Wert. Die mechanische Ablage muss aber nicht durch teure KI-Werkzeuge laufen. Sie kann durch ein simples Skript erledigt werden, das direkt auf das Dateisystem schreibt.
Triage statt Einheitslösung
Wir haben die Lösung als Triage-Skill umgesetzt, also als kleine Routing-Regel, die jede Schreiboperation prüft und an die richtige Stelle weiterleitet.
Triviale Schreibvorgänge wie das Anlegen einer neuen Notiz oder das Anhängen eines kurzen Eintrags an eine bestehende Datei laufen über ein PowerShell-Skript. Das Skript schreibt direkt in den Vault-Ordner, ohne Umweg über die KI-Schnittstellen. Tokens für das Ablegen entfallen vollständig. Der Markdown-Inhalt selbst bleibt unverändert von der KI verfasst.
Komplexere Operationen wie das Patchen einer Notiz an einer bestimmten Überschrift oder das gezielte Aktualisieren eines Frontmatter-Feldes laufen weiterhin über die MCP-Schnittstelle. Sie brauchen Stellengenauigkeit, die ein einfaches Skript nicht leisten würde. Allerdings übernimmt dort kein teures Top-Modell, sondern ein kleiner, schneller Helfer aus der Haiku-Klasse. Auch das senkt die Kosten spürbar, ohne dass die Qualität leidet.
Risikohafte Operationen wie Löschen oder größere Umbauten stoppen die Pipeline und melden sich beim Menschen zurück. Diese Regel ist nicht charmant, aber sie verhindert verlorenes Wissen.
Was die Triage in Zahlen bedeutet
Die Verteilung ist in der Praxis erfreulich eindeutig. Rund siebzig Prozent unserer Schreibvorgänge in den Vault sind triviale Ablagen. Sie laufen ab jetzt am MCP vorbei. Etwa fünfundzwanzig Prozent sind echte Patches, die durch die kleine Haiku-Klasse laufen. Die restlichen Prozente sind Sonderfälle, die wir bewusst manuell entscheiden.
Wir sprechen über Beträge in der Größenordnung weniger Euro pro Monat. Für einen einzelnen Anwender ist das wenig. Hochgerechnet auf ein wachsendes Team und einen wachsenden Vault wird daraus eine Routine, die sich sehr schnell auszahlt. Vor allem aber ist es ein Beispiel für ein Muster, das in vielen anderen Bereichen funktioniert. Trennen Sie das Verfassen vom Ablegen. Das Verfassen ist die wertschöpfende Tätigkeit der KI. Das Ablegen ist Mechanik, die ein Skript besser erledigt.
Was Sie aus dieser Praxis mitnehmen können
Wenn Sie heute beginnen, einen Wissensspeicher für Ihre KI-Arbeit aufzubauen, lohnen sich vier Schritte.
Ein einziger Vault. Nicht drei verschiedene Tools, nicht eine Ablage pro Mitarbeiter. Ein gemeinsamer Speicher mit klarer Ordnerstruktur.
Eine Startdatei. Eine kleine, gepflegte Übersichtsdatei, die in jeder Sitzung als Einstieg dient. Sie ersetzt das ewige neue Erklären desselben Kontextes.
Standards früh festlegen. Frontmatter, Wikilinks, Tagebuch-Format, README-Pflicht. Diese vier Regeln genügen für den Start.
Schreiben triagieren. Trennen Sie das Verfassen vom Ablegen. Triviale Operationen können ohne KI direkt auf das Dateisystem gehen. Komplexe Operationen brauchen die KI, aber nicht zwingend das größte Modell.
Der Aufbau ist eine Investition. Sie kostet ein paar Stunden in der ersten Woche und ein paar Minuten pro Woche danach. Sie zahlt zurück in Form von Kontinuität, Qualität und gelassenem Umgang mit dem ständigen Vergessen, das KI-Werkzeuge sonst mit sich bringen.
Wo unsere Reise weitergeht
Wir bauen den Vault Schritt für Schritt aus. Aktuell arbeiten wir daran, weitere mechanische Operationen aus dem teuren Hauptmodell auszulagern. Die nächste Stufe betrifft das Generieren wiederkehrender Wartungsberichte und das Aggregieren von Wochenkennzahlen. Beide Aufgaben verlangen keine kreative Arbeit, sondern eine zuverlässige Routine. Sie sind also Kandidaten für die kleine Haiku-Klasse oder für ein Skript.
Wir berichten in einem späteren Beitrag, welche Muster sich dort als nützlich erweisen und welche eher nicht. Bis dahin gilt aus unserer Erfahrung in Hamburg ein einfacher Grundsatz. Bauen Sie Wissen auf, das bleibt, und sorgen Sie dafür, dass die Mechanik dahinter so günstig wie möglich läuft. Beides geht erstaunlich gut zusammen, sobald die Werkzeuge eine gemeinsame Heimat haben.
Wenn Sie überlegen, wie Sie KI im eigenen Betrieb so verankern, dass sie nicht in jeder Sitzung neu erklärt werden muss, melden Sie sich gern. Wir zeigen Ihnen in Hamburg, wie ein passender Wissensspeicher für Ihre Arbeitsweise aussieht und welche kleinen Triage-Regeln in Ihrer Umgebung den größten Hebel haben.
