moritz conjé
Projektmanagement
Kommunikation & Konzeption
T-Shaped Professional

Notizblog

Homelab: Beiträge rund um Aufbau und Betrieb meines eigenen Homelabs:
von Hardware und Netzwerk bis zu selbst gehosteten Diensten und smarter Haussteuerung.
Eigene Lösungen statt fertiger Anbieter, mit allem Basteln und Lernen, das dazugehört.

Eine eigene Statuszeile fürs Terminal: mehr Überblick bei der Arbeit mit Claude Code
Wer täglich mit einer KI im Terminal arbeitet, kennt das Problem: Wie ausgelastet die laufende Sitzung gerade ist, wie nah man an ein Nutzungslimit kommt oder was sie bereits gekostet hat, bleibt normalerweise unsichtbar. Man merkt es meist erst, wen ...
Fähigkeiten ergänzen: passende Skills für die Rollen und Aufgaben finden
Ein KI-Assistent kann schon ohne Erweiterungen erstaunlich viel. Für ein konkretes Projekt reicht „erstaunlich viel" aber selten als Arbeitsweise. Beim Aufbau des Second Brain kamen zuletzt drei sehr unterschiedliche, eigenständige Projekte zusammen: ...
Wie Wissen ins Second Brain kommt: Web-Clipper, YouTube-Transkripte und Bücher
Der letzte Teil dieser Serie endete mit einer offenen Frage: Wie gut ein Redakteur Themen clustern kann, hängt direkt davon ab, was überhaupt an Input hereinkommt – und wie es dort ankommt. Der große Notion-Import hatte den bestehenden Wissensbestand ...
Arbeiten im Second Brain: Claude Remote auf LXC und der Zugriff aufs LLM-Wiki über TrueNAS
Das Rollenmodell aus den letzten Teilen dieser Serie beantwortet, wer im Second Brain mit welchen Rechten arbeitet. Offen blieb bislang eine ganz praktische Frage: Wo findet diese Arbeit eigentlich statt, wenn ich nicht am Schreibtisch-PC sitze? Das ...
Vom Konzept zum ersten echten Testlauf: das Übergabe-Artefakt-Schema in der Praxis
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 de ...
Die fünfte Rolle: wie der Kurator (agt_kur) das Rollenmodell selbst korrigiert
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 Widersp ...
Vier Rollen für ein Second Brain: wie ich Agenten-Verantwortlichkeiten definiert habe
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 ...
Wenn das Kanban-Board bricht: Grenzen des Task-Board-Plugins und der Weg zu Bases
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 eine ...
Vom PARA-Schema zum Prozessmodell: wie mein Second-Brain-Konzept gereift ist
Nach dem Datenimport aus Notion stand die nächste Frage im Raum: Nach welcher Logik sollen die zusammengeführten Daten künftig geordnet werden? Naheliegend war PARA (Projects/Areas/Resources/Archive) / fortelabs.com – das bekannteste Ordnungssystem i ...
Die fünfte Rolle: wie der Kurator (agt_kur) das Rollenmodell selbst korrigiert

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.