Details

Geschrieben von: Moritz Conjé & Claude (Co-Autor)

Kategorie: Homelab

Veröffentlicht: 14. August 2026

Zugriffe: 37

• KI/AI

Der Second-Brain-Bibliothekar aus Beitrag 4 darf laut Rollenmodell keine Quellnotizen verändern – nur lesen. Das wirft sofort eine praktische Frage auf: Wie kommen seine Erkenntnisse dann überhaupt irgendwo an? Und wie bleibt nachvollziehbar, wenn derselbe Themencluster über mehrere Läufe hinweg immer wieder auftaucht? Bis zur Antwort brauchte es mehrere Entwurfsrunden – und am Ende einen ersten echten Testlauf über 100 Notizen.

Das Problem: Erkenntnisse ohne Schreibrecht

Ohne Schreibrecht auf die Quellen bleibt dem Bibliothekar nur ein Weg: ein eigenes, separates Ergebnisdokument. Aber ein einzelnes Dokument pro Lauf reicht nicht, wenn Cluster nicht sauber voneinander abgegrenzt sind oder derselbe thematische Zusammenhang bei jedem neuen Lauf wie ein völlig neuer Fund erscheint, obwohl er eigentlich zu einem bereits bekannten Thema gehört.

Ein Schema, das mehrere Runden brauchte

Das Übergabe-Artefakt-Schema ist deshalb nicht am Reißbrett entstanden, sondern iterativ auf einem Canvas gewachsen, in mehreren geprüften und verfeinerten Runden. Zentrale Bausteine am Ende: eine kategorie ("Neues Potenzial" vs. "Ergänzung/Synergie"), ein Reifegrad (Inbox → Seed → Growing → Evergreen) sowie eine Cluster-ID. Die Cluster-ID war dabei die wichtigste Designentscheidung: Sie ist bewusst persistent, wächst über mehrere Läufe hinweg statt bei jedem Lauf neu zu beginnen. Der Gedanke dahinter: Es geht nicht nur darum, Muster vorzugeben, sondern ihnen auch zu erlauben, sich über Zeit weiterzuentwickeln. Aus dem Canvas-Entwurf wurde anschließend eine echte Vorlage plus eigene Datenbank im Vault.

Technische Grenzen unterwegs

Nicht alles ließ sich wie geplant umsetzen. Die Cluster-ID hat keine live nachschlagbare Referenz – aus einer Datenbank-Formel heraus lässt sich in Obsidian derzeit keine Property einer verlinkten Notiz auslesen, bestätigt gegen die offizielle Dokumentation. Auch die Routing-Regel, die festlegt, welche Kategorie an mich direkt geht und welche an den Agenten Cowork, ist bislang nur vorläufig – "erstmal so, und dann sehen, wie das im Alltag funktioniert", mit einem noch terminlosen Review nach etwas praktischer Erprobung. Und wer über die Basis-Einstufung hinaus einen höheren Reifegrad vergeben darf – ich selbst beim Sichten, oder der Second-Brain-Bibliothekar heuristisch beim Verarbeiten –, war mangels ausreichender Praxisdaten schlicht noch nicht zu entscheiden.

Drei echte Testläufe

Trotz dieser offenen Punkte bin ich nicht beim Entwerfen stehen geblieben, sondern habe das Schema dreimal an echten Daten getestet: einmal als Audit der bestehenden Themenfelder-Liste, einmal als Abgleich eines einzelnen Inputs gegen bereits vorhandene eigene Ausarbeitungen, und schließlich als eigentlicher Belastungstest – ein Batch-Lauf über 100 Input-Notizen. Ergebnis dieses dritten Laufs: sieben Übergabe-Artefakte, von einem 32 Quellen starken Cluster zu Obsidian-Tooling bis zu einem einzelnen, aber wertvollen Duplikat-Hinweis. Parallel dazu habe ich die Reifegrad-Baseline "Inbox" rückwirkend auf den gesamten Bestand angewendet – 1.662 von 1.665 Input-Notizen, bewusst ohne Sonderbehandlung der Notizen, die durch den Testlauf bereits mit einem Cluster verknüpft waren.

Ergebnis

Das Rollenmodell aus Beitrag 4 hat sich damit erstmals nicht nur auf dem Papier, sondern an echten Daten bewährt. Ganz abgeschlossen ist das Thema damit aber nicht: Offen bleiben unter anderem eine echte Liste noch unausgereifter Cluster über mehrere Läufe hinweg, die Überprüfung der Routing-Regel nach etwas mehr Praxis, die eigentliche Hochstufungslogik über die Baseline hinaus, ein vollständiger Duplikat-Scan über den gesamten Bestand sowie ein Log, das echte Übergaben zwischen den Rollen nachvollziehbar macht.

Ausblick

Der Testlauf hat vor allem eines gezeigt: Wie gut der Bibliothekar clustern kann, hängt direkt davon ab, was überhaupt an Input hereinkommt – und wie es dort ankommt. Genau darum geht es im nächsten Teil dieser Serie: die verschiedenen Wege, auf denen neues Wissen mein Second Brain überhaupt erreicht.

Details

Geschrieben von: Moritz Conjé & Claude (Co-Autor)

Kategorie: Homelab

Veröffentlicht: 12. August 2026

Zugriffe: 54

• KI/AI

Ein Rollenmodell zu entwerfen und mit genau diesem Entwurf gegen eine bereits getroffene, dokumentierte Entscheidung zu verstoßen, ohne es zu merken – das ist mir beim Ausarbeiten meiner fünften Rolle tatsächlich passiert. Aufgefallen ist der Widerspruch nicht automatisch, sondern erst beim genauen Nachlesen. Genau diese Lücke schließt die Rolle, die aus diesem Vorfall entstanden ist.

Ein Widerspruch, den ich selbst übersehen hatte

Mein Agent Cowork, die vierte Rolle aus dem vorherigen Beitrag dieser Serie, stellt Dokumentationskonsistenz im laufenden Sessionfluss nicht zuverlässig selbst her: Eine Entscheidung wird getroffen und in ein Dokument geschrieben, verwandte Dokumente werden dabei aber nicht immer mitgezogen. Sichtbar wurde genau das ausgerechnet am eigenen Rollenentwurf. Die Idee zu einer neuen, fünften Rolle – dem Kurator selbst – widersprach beim Entwerfen zunächst unbemerkt einer bereits getroffenen Entscheidung: keine eigene Wiki-Ebene-Rolle. Aufgedeckt hat das erst der explizite Abgleich beim Review, nicht ein automatischer Mechanismus.

Kein fünfter gleichrangiger Schritt, sondern ein Unter-Agent

Statt den Kurator als fünften, zu den anderen vier gleichrangigen Prozessschritt einzuordnen, habe ich ihn bewusst als Sub-Agent zum Agent Cowork angelegt. Er setzt ausschließlich im Anschluss an eine abgeschlossene Agent-Cowork-Session an – nicht parallel dazu und nicht an ihrer Stelle. Den Session-Diff, also die Frage, was in der letzten Sitzung überhaupt verändert wurde, löse ich dabei bewusst nicht über neue Infrastruktur, sondern über eine bereits bestehende Spalte in meinem Session-Log: Die dort ohnehin vermerkten, betroffenen Dokumente bilden den Ausgangspunkt der Prüfung.

Drei Stufen statt sofortiger Automatisierung

Die Bauweise habe ich bewusst in drei Stufen geplant, jede folgende erst nach Bewährung der vorherigen:

• Aktueller Stand: eine explizite Ja/Nein-Abfrage am Sessionende – der Agent Cowork fragt aktiv nach, ob der Kurator jetzt starten soll.
• Später: automatische Nachbereitung ohne einzelne Abfrage, sobald sich der Ablauf im Alltag bewährt hat.
• Optional, ausdrücklich ungeklärt: eine mögliche spätere Integration in mein System für unbeaufsichtigten Betrieb – bewusst kein Vorgriff, nur als Gedanke vorgemerkt.

Wo es beim Entwerfen klemmte

Zwei Punkte ließen sich nicht ohne Reibung klären. Der Kurator grenzt sich bewusst eng von der bereits bestehenden, breiteren Wiki-Pflege-Aufgabe des Agent Cowork ab – dessen periodischer Scan über beliebige Wiki-Bereiche bleibt unverändert dort verortet, um keine Doppelrolle entstehen zu lassen. Zusätzlich zeigte sich, dass eine erst kurz zuvor verschärfte Log-Regel (Abfrage vor jedem Eintrag) eine erneute, mehrtägige Lücke in der Protokollierung nicht verhindert hatte. Die Konsequenz: Der Log-Eintrag ist jetzt nicht mehr abfragebasiert, sondern folgt automatisch auf jede Session – ohne diese Verschärfung hätte dem Kurator strukturell die eigene Arbeitsgrundlage gefehlt.

Der erste Testlauf noch am selben Tag

Der Scope blieb bewusst eng: geprüft wird nur die zuletzt abgeschlossene Session, nicht das gesamte Wiki. Beim Korrekturprinzip habe ich dieselbe Regel wie beim Agent-Cowork übernommen – Direktänderung ist der Normalfall, bei einem echten Quellwiderspruch markiert der Kurator stattdessen einen offenen Konflikt, statt eigenmächtig zu überschreiben. Noch am selben Tag kam es zum ersten echten Lauf, manuell von mir gestartet: Der Kurator prüfte den Session-Diff aus dem letzten Lauf des Agent Redakteur und fand sechs kaputte Wikilinks in den Übergabe-Artefakten – verlinkt waren Projektordner-Namen statt der tatsächlichen Notiz-Titel – sowie zwei veraltete Cross-Referenzen. Alle Funde wurden direkt korrigiert. Einen weiteren Fund außerhalb des eigentlichen Session-Scopes, einen leeren Projektordner, hat der Kurator bewusst nur vermerkt und nicht eigenständig korrigiert.

Ergebnis

Aus dem Vier-Rollen-Modell ist damit ein Fünf-Rollen-Modell geworden, mein zentrales Übersichtsdokument zur Zusammenarbeit der Agenten entsprechend ergänzt. Bemerkenswert war dabei weniger die Technik als der Auslöser selbst: Die Rolle, die künftig genau solche Inkonsistenzen aufdecken soll, ist aus einer Inkonsistenz an ihrem eigenen Entwurf entstanden.

Ausblick

Ob sich der Kurator im Alltag tatsächlich bewährt und wann die zweite Ausbaustufe – die automatische Nachbereitung ohne Abfrage – folgt, wird sich erst über mehrere echte Sessions zeigen. Wie sich das erweiterte Rollenmodell insgesamt in der Praxis schlägt, davon handelt einer der nächsten Beiträge dieser Serie.

Details

Geschrieben von: Moritz Conjé & Claude (Co-Autor)

Kategorie: Homelab

Veröffentlicht: 11. August 2026

Zugriffe: 47

Irgendwann habe ich nachgezählt: 1.638 Input-Notizen standen nur 36 tatsächlich verarbeiteten Notizen gegenüber – weniger als drei Prozent. Das Sammeln hatte in meinem Second Brain längst funktioniert, das Verarbeiten nicht. Die eigentliche Frage war dabei gar nicht technischer Natur: Wer oder was sollte diesen Rückstau abarbeiten, und mit welchen Rechten sollte dabei gearbeitet werden dürfen?

Ein Rückstau, der eine Struktur brauchte

Eine einzelne, allzuständige KI-Rolle für alles – Sichten, Entscheiden, Schreiben, Veröffentlichen – schien mir keine gute Idee. Zu viel Verantwortung an einer Stelle, zu wenig Möglichkeit, im Alltag noch nachzuvollziehen, was gerade automatisch passiert und was nicht. Also stand am Anfang keine technische Frage, sondern eine organisatorische: Welche Teilaufgaben lassen sich sauber trennen, und welche Rechte braucht jede dieser Teilaufgaben tatsächlich – nicht mehr, aber auch nicht weniger?

Vier Rollen statt einer allzuständigen KI

Entstanden ist ein Vier-Rollen-Modell, jede mit klar unterschiedlichem Zugriff:

• Agent Second-Brain-Bibliothekar [agt_bib] – arbeitet auf der Input-Ebene, sichtet und clustert die rohen Notizen. Nur Leserechte auf die Quellen; einziger erlaubter Schreib-Output ist ein eigenes Übergabe-Artefakt mit Vorschlägen, keine direkte Veränderung an den Notizen selbst.
• Agent Cowork [agt_cw] – der eigentliche Default-Modus meiner interaktiven Arbeit mit Claude: Tasks bearbeiten, Dokumentation pflegen, neue Aufgaben definieren. Hier gibt es echtes Schreibrecht, weil ich im selben Arbeitsschritt mitentscheide – anders als bei den unbeaufsichtigt laufenden Rollen. Der Prozess-Agent challenged die Übergabe-Artefakte und erzeugt nach Absprache daraus Aufgaben oder detaillierte, umfangreichere Notizen.
• Agent Redakteur [agt_red] – übernimmt die Content-Erstellung von Aufgaben im Bereich Blogbeitrags, aber ohne Themenhoheit, erst nach Übergabe: Welches Thema überhaupt zum Blogbeitrag wird, entscheidet nicht diese Rolle. Schreibrecht nur im Entwurfsordner, kein Publish-Recht.
• Agent Live-Coach [agt_lc] – bisher nur perspektivisch gedacht, für Quartals- und Jahresreviews im direkten Dialog statt ereignisgetriggert wie die anderen drei Rollen.

Wo es zu klemmen begann

Zwei Punkte ließen sich nicht am Reißbrett klären. Der Agent Cowork blieb zunächst ein reiner Platzhalter – die eigentliche Frage war, ob das überhaupt eine eigene Rolle mit eigenem Profil ist, oder einfach die Bezeichnung für meine ganz normale, bereits gelebte Zusammenarbeit mit Claude. Und beim Agent Redakteur stand die Frage im Raum, ob ein erfülltes Abnahmekriterium (eigener Skill, erfolgreicher Testlauf) automatisch zur Freigabe führen sollte, oder ob es dafür immer noch eine explizite Entscheidung von mir braucht.

Vom Prinzip zur Regel

Beide Fragen und einige weitere haben sich erst über 17 Protokoll-Runden in zwei separaten Sitzungen wirklich geschärft – nicht an einem Nachmittag entschieden, sondern schrittweise durchdacht. Am Ende standen konkrete, eindeutig anwendbare Regeln statt vager Prinzipien:

• Der Agent Cowork bearbeitet Dateien standardmäßig direkt, mit genau einer Ausnahme: Datei-Umbenennungen bleiben bei mir. Grund ist rein technisch – nur Obsidians eigener Umbenennen-Befehl aktualisiert Wikilinks vault-weit zuverlässig, ein externes Skript würde tote Links hinterlassen.
• Beim Agent Redakteur gibt es keine automatische Freigabe, selbst wenn alle Abnahmekriterien formal erfüllt sind. Es braucht immer eine konkrete, positiv zu beantwortende Freigabefrage an mich – eine bewusste Erweiterung des Grundprinzips "Automatisierung schlägt vor, ich entscheide": auch bei erfüllten Kriterien keine stille Statusänderung.

Ergebnis

Alle vier Rollen sind inzwischen als Entwürfe dokumentiert. Drei davon habe ich bereits in der Praxis getestet, mit durchaus unterschiedlichen Ergebnissen – davon handelt der nächste Teil dieser Serie.

Ausblick

Ein Rollenmodell auf dem Papier ist die eine Sache, ein echter Testlauf mit echten Daten eine andere. Wie der Agent Second-Brain-Bibliothekar zum ersten Mal auf 100 echte Input-Notizen losgelassen wurde und was dabei tatsächlich herauskam, zeigt der nächste Beitrag.

Details

Geschrieben von: Moritz Conjé & Claude (Co-Autor)

Kategorie: Homelab

Veröffentlicht: 05. August 2026

Zugriffe: 45

Mit dem Prozessmodell stand fest, wie ich über mein Second Brain denken will. Für die tägliche Arbeit brauchte ich aber auch ein Werkzeug, das dieses Denken abbildet – ein Kanban-Board für Projekte und Aufgaben. Genau dort brach mir wenig später eines meiner vier bestehenden Boards weg, ohne jede Fehlermeldung. Der Grund dafür lag tiefer, als ich zunächst vermutet hatte.

Der eigentliche Fehler: Ordnerpfad statt Property

Das bisher genutzte Plugin Task Board filtert seine Boards ausschließlich über einen exakten Ordnerpfad-Präfix. Jede Umbenennung oder Verschiebung eines Ordners bricht diesen Filter lautlos – keine Fehlermeldung, das Board zeigt einfach null oder falsche Karten an. Genau das war bei einem meiner vier Boards bereits real passiert: Der hinterlegte Pfad existierte nicht mehr, obwohl die zugehörigen Karten mit korrektem Tag weiterhin im Vault lagen.

Bestandsaufnahme vor der Entscheidung

Bevor ich etwas geändert habe, habe ich den tatsächlichen Bestand geprüft: 76 offene und 7 erledigte Karten, verteilt auf vier Boards. Dabei kamen zwei weitere, unabhängige Probleme ans Licht. Erstens: Welcher Spalte eine Karte zugeordnet wird, hing tatsächlich an einem Tag, nicht am eigentlich dafür vorgesehenen Status-Feld – Letzteres war teils veraltet und stimmte nicht mehr zuverlässig mit der echten Spalte überein. Zweitens: Zwei Boards teilten sich denselben Ordner und denselben Tag für ihre Follow-up-Spalte, wodurch identische Karten in beiden Boards auftauchten. Der naheliegende Versuch, das durch Verschieben einzelner Dateien zwischen den Ordnern zu entwirren, erwies sich als Sackgasse – die Karten gehörten inhaltlich zu Recht in beide Kontexte, das Problem lag an der reinen Tag-Logik, nicht an der Dateiablage.

Werkzeugwahl: Bases statt Task Board

Obsidian Bases, das Core-Plugin für property-gefilterte Ansichten, war bei mir bereits im Second-Brain-Bereich im Einsatz – kein neues Konzept, sondern ein bewährtes Muster, das sich auf die Boards übertragen ließ. Ein Community-Plugin namens "Project Manager" habe ich bewusst verworfen: Es hätte ein drittes, konkurrierendes Datenmodell neben Bases und dem bestehenden Second-Brain-Schema eingeführt und selbst wieder mit derselben Ordner-first-Logik gearbeitet, die ich gerade ablösen wollte. Für die eigentliche Kanban-Optik habe ich zunächst das Community-Plugin "Base Board" installiert – Spalten werden direkt aus einer beliebigen Frontmatter-Property erzeugt, Drag & Drop schreibt die Property unmittelbar in die Datei zurück, kein eigener Pfad-Cache mehr. Weil es aber keine Swimlanes unterstützt, bin ich stattdessen auf Bases Kanban (Community-Plugin kanban-bases-view) umgestiegen, das dieselbe property-basierte Logik mitbringt und zusätzlich eine zweite Gruppierungsebene erlaubt.

Migration in der Praxis: ein paar Stolpersteine

Die eigentliche Umstellung – Tags/Status per Skript auf ein neues type/status-Schema (`prt_`) überführen – lief größtenteils reibungslos. Ein Fund war es aber wert, festgehalten zu werden: Der Kanban-View-Cache in einer Bases-Datei merkt sich jede jemals gesehene Spalten- und Karten-Position dauerhaft, auch nachdem ein Filter nachträglich korrigiert wurde. Bei einem der Boards führte das zu sieben Phantom-Status-Spalten und einer Ordnungsliste, die praktisch das gesamte Vault umfasste – die Datei wuchs dadurch auf 318 KB an. Der Fix war unspektakulär: Cache auf leer zurücksetzen, danach baute sich die Ansicht aus den echten Daten neu auf, die Datei schrumpfte auf 492 Bytes. Für alle weiteren Boards galt danach: Filter zuerst korrekt setzen, bevor die Ansicht das erste Mal mit echten Daten läuft. Eine zweite Idee – aus der Plugin-Dokumentation automatisch eine Vorlage beim Anlegen neuer Karten vorausfüllen zu lassen – musste ich wieder verwerfen: Die dafür beschriebene Funktion existiert bislang nur im unveröffentlichten Entwicklungszweig des Plugins, nicht in der installierten Version. Ein Test damit ließ kurzzeitig alle Kanban-Ansichten verschwinden; nach Entfernen der betreffenden Einstellung waren sie wieder da.

Ergebnis

Alle vier ursprünglichen Boards sind migriert, dabei wurden es wegen der aufgedeckten Überschneidung bewusst fünf eigenständige Ansichten statt vier. Sämtliche 68 migrierten Original-Karten liegen jetzt archiviert, das alte Task-Board-Plugin ist deaktiviert. Sogar der Migrationsplan selbst ist inzwischen als eigene Karte im neuen System eingetragen – ein passender Schlusspunkt für ein Projekt, das mit einer lautlos verschwundenen Karte begann.

Ausblick

Offen bleibt vor allem die Dokumentation: Die Beschreibung des alten Board-Schemas muss noch durch das neue ersetzt werden, ebenso die Frage, ob die bisherige Ordnerstruktur als reine Ablage-Konvenienz erhalten bleibt. Wie es sich anfühlt, mit diesem neuen, property-basierten System tatsächlich zu arbeiten – etwa bei der Frage, wer im Second Brain und KI-Agenten welche Karten anlegen und bearbeiten darf –, ist Thema eines der nächsten Beiträge dieser Serie.