Transparenzhinweis: Dieser Entwurf wurde von Otti, Rubens persönlichem KI-Assistenten, in Rubens Auftrag verfasst. Inhalt, Perspektive und Schwerpunktsetzung beruhen auf Rubens Arbeit mit Otti/OpenClaw und wurden als redaktioneller Entwurf für Rubens Blog vorbereitet.

English version: How to Build a Personal AI Assistant That Does Not Become Annoying

Wie man einen persönlichen KI-Assistenten baut, der nicht nervt

Psychologisch fundiertes Systemdesign für Erinnerung, Proaktivität und Memory

Viele Gespräche über KI-Assistenten beginnen mit einer Featureliste:

Kann er Kalender?
Kann er erinnern?
Kann er recherchieren?
Kann er Mails schreiben?
Kann er Aufgaben verwalten?
Kann er im Hintergrund laufen?

Das sind berechtigte Fragen. Aber sie sind nicht die wichtigste Ebene.

Ein persönlicher KI-Assistent wird nicht dadurch gut, dass er möglichst viel kann. Er wird gut, wenn er menschliche Handlungsfähigkeit erhöht, ohne Aufmerksamkeit, Autonomie oder Vertrauen zu beschädigen.

Die entscheidende Frage lautet deshalb nicht:

Welche Features hat der Assistent?

Sondern:

Welche Art von Beziehung zwischen Mensch, Alltag, Aufmerksamkeit und Technik erzeugt dieses System?

Ein Reminder-System kann entlasten. Es kann aber auch Schuldgefühle erzeugen.

Ein proaktiver Agent kann vorbereiten. Er kann aber auch nerven.

Ein Memory-System kann Kontinuität schaffen. Es kann aber auch falsche Annahmen konservieren.

Ein persönlicher Assistent ist deshalb kein neutraler Produktivitäts-Booster. Er ist eine kleine Aufmerksamkeits- und Entscheidungsinfrastruktur.

Und genau so muss man ihn bauen.

1. Beginne nicht mit Tools, beginne mit Aufmerksamkeitsregeln

Der häufigste Fehler ist, zuerst den Tech-Stack zu planen:

Welches Modell?
Welche Runtime?
Welche App?
Welche Datenbank?
Welche Automationen?

Das ist verständlich, aber zu früh.

Für einen persönlichen Assistenten ist zuerst wichtiger:

Was darf mich unterbrechen?
Was soll nur vorbereitet werden?
Was darf automatisch passieren?
Was braucht meine Zustimmung?
Was soll dauerhaft gespeichert werden?
Was soll bewusst vergessen oder archiviert werden?

Diese Fragen klingen weniger technisch, sind aber die eigentliche Architektur.

Denn jeder proaktive Assistent trifft implizit Aufmerksamkeitsentscheidungen. Wenn man sie nicht bewusst gestaltet, übernimmt das System die Defaults klassischer Produktivitätssoftware: mehr Erinnerungen, mehr offene Punkte, mehr Sichtbarkeit, mehr Druck.

Ein guter persönlicher Assistent muss oft das Gegenteil tun:

filtern statt alles anzeigen
vorbereiten statt drängen
kontextualisieren statt pingen
schweigen statt aktivieren
entlasten statt optimieren

Das Ziel ist nicht maximale Aktivität. Das Ziel ist bessere Handlungsfähigkeit.

2. Die kleinste sinnvolle Version

Man braucht nicht sofort einen self-hosted Agenten mit Discord, Cron, Memory Search, Subagents und Tool-Runnern.

Die kleinste sinnvolle Version eines persönlichen Assistenten besteht aus sieben Schichten:

1. Dialogfläche
2. dauerhafte Notizen / Memory
3. Aufgaben- und Fristlogik
4. Erinnerungen / Kalender / Cron
5. Recherche- oder Lesefähigkeit
6. Autonomie-Gates
7. Korrekturpfad

1. Dialogfläche

Ein Ort, an dem man mit dem System spricht: ChatGPT Project, Claude Project, OpenClaw, Hermes, Matrix, Discord, Telegram, Webchat — egal.

Wichtig ist nicht die Oberfläche, sondern Kontinuität.

2. Dauerhafte Notizen / Memory

Der Assistent braucht eine Art Gedächtnis. Das kann anfangs auch einfach Markdown sein.

Nicht alles gehört in Memory. Gute Kategorien sind:

dauerhafte Fakten über den Menschen
Entscheidungen
laufende Projekte
Präferenzen
Korrekturen am Verhalten des Assistenten
wiederkehrende Regeln

3. Aufgaben- und Fristlogik

Nicht jede offene Sache ist gleich.

Eine psychologisch gesunde Grundtrennung:

Deadline   = externer Termin, echtes Risiko bei Verpassen
Active     = aktuell relevant, aber kein harter Termin
Someday    = gute Idee, kein Druck
Internal   = Assistent beobachtet/prüft selbst, ohne menschliche Aufmerksamkeit

Nur Deadlines dürfen eskalieren. Someday erzeugt keinen Druck.

4. Erinnerungen / Kalender / Cron

Erinnerungen sind nicht „Sag mir X um Y Uhr“.

Gute Erinnerungen liefern Kontext:

Warum ist das wichtig?
Was ist schon vorbereitet?
Was ist der nächste kleinste Schritt?
Muss der Mensch wirklich handeln?

5. Recherche- oder Lesefähigkeit

Ein Assistent sollte Links, Dokumente, Mails, Logs oder Webseiten lesen können, bevor er urteilt.

Regel:

Lesen vor annehmen.

Das klingt banal. Es ist eine der wichtigsten Schutzregeln gegen Halluzination und falsche Sicherheit.

6. Autonomie-Gates

Der Assistent braucht klare Grenzen:

Grün: darf selbst handeln
Gelb: darf handeln und danach informieren
Rot: muss vorher fragen

Beispiele:

Datei lesen: meistens grün
Reminder setzen: meistens grün/gelb
System config ändern: gelb
Nachricht an Dritte senden: rot
Daten löschen: rot
Pay-per-use API unbeaufsichtigt nutzen: rot

7. Korrekturpfad

Der Assistent wird Fehler machen.

Wichtig ist nicht Fehlerfreiheit, sondern sichtbare Korrigierbarkeit:

Fehler/Korrektur
→ Bedeutung erkennen
→ richtige Speicherschicht wählen
→ Regel oder Fakt ändern
→ sichtbar bestätigen
→ später überprüfen

Wenn ein Assistent korrigiert wird und nichts daraus lernt, ist er kein System. Er ist nur ein Chatfenster mit Gedächtnisillusion.

3. Proaktivität: hilfreich statt nervig

Proaktivität ist der gefährlichste und wertvollste Teil eines persönlichen Assistenten.

Schlecht gebaut wird sie zu Spam.

Gut gebaut wird sie zu Entlastung.

Die wichtigste Schwelle lautet:

Würde ich es morgen als Versäumnis empfinden, wenn der Assistent mich nicht darauf hingewiesen hätte?

Wenn ja, darf der Assistent proaktiv sein.

Wenn nein, reicht oft ein Log, eine Daily Note oder gar nichts.

Gute proaktive Signale

externe Deadline unter 48 Stunden
Sicherheitsproblem
Kostenrisiko
Systemausfall
Termin mit fehlender Vorbereitung
wiederkehrender Fehler, der den Menschen belastet
neue Information, die eine Entscheidung verändert

Schlechte proaktive Signale

„Du wolltest doch mal…“ ohne Kontext
vage Selbstoptimierungsziele
jede offene Aufgabe
Routine-Erfolge
interne technische Nachverfolgung
Dinge, die nur das System selbst interessieren

Ein guter Assistent schützt die Aufmerksamkeitsfläche.

4. Erinnerungen ohne Schuldgefühl

Viele Aufgaben- und Reminder-Systeme erzeugen unterschwellig Schuld:

überfällige Aufgaben
rote Badges
Streaks
tägliche Rückstände
immer wieder hochgespülte Wünsche

Für manche Kontexte ist das effektiv. Für einen persönlichen Assistenten ist es riskant.

Ein Assistent sollte nicht moralisch bewerten, dass etwas offen ist. Er sollte helfen, den nächsten realistischen Schritt sichtbar zu machen.

Schlecht:

Du hast X immer noch nicht gemacht.

Besser:

X steht noch offen. Der nächste kleine Schritt wäre Y. Ich kann Z vorbereiten, wenn du willst.

Noch besser:

X ist nur relevant, wenn du diese Woche Energie dafür hast. Kein externer Termin. Ich halte es im Hintergrund.

Das ist kein Weichspülen. Es ist präzise Aufmerksamkeitssteuerung.

5. Memory Hygiene: behalten, verdichten, vergessen

Ein persönlicher Assistent braucht Memory. Aber Memory ist kein Müllcontainer.

Drei Fehler sind häufig:

Alles speichern.
Nichts vergessen.
Alte Annahmen nie überprüfen.

Gutes Memory unterscheidet:

Fakt       = stimmt dauerhaft oder bis Änderung
Entscheid  = wurde bewusst entschieden
Kontext    = hilft, aktuelle Arbeit zu verstehen
Aufgabe    = braucht Handlung oder Review
Signal     = kann später Muster zeigen
Archiv     = Original bleibt erhalten, aber nicht dauernd aktiv

Wichtig ist: Vergessen heißt nicht löschen.

Besser ist CRUF statt CRUD:

Create
Read
Update
Forget

Forget bedeutet: Relevanz senken, archivieren, aus der aktiven Aufmerksamkeit nehmen.

Nicht alles, was wahr ist, muss ständig präsent sein.

6. Der Assistent darf widersprechen

Ein persönlicher Assistent darf nicht nur angenehm sein.

Große Sprachmodelle sind stark darauf trainiert, anschlussfähig zu antworten. Das erzeugt ein Risiko: Sie bestätigen zu leicht.

Für persönliche Assistenz gilt:

Beziehung entsteht durch Verlässlichkeit, nicht durch Zustimmung.

Der Assistent sollte sagen können:

Das weiß ich nicht.
Das habe ich nicht geprüft.
Das klingt plausibel, aber die Quelle fehlt.
Das ist riskant.
Ich glaube, du machst dir hier unnötig Druck.
Ich glaube, du unterschätzt hier ein echtes Problem.

Widerspruch ist kein Mangel an Freundlichkeit. Unterlassener Widerspruch kann ein Sicherheitsproblem sein.

7. Menschliche Grenzen sind echte Systemparameter

Der Mensch hat Körper, Schlafbedarf, Stressachsen, soziale Verpflichtungen, Endlichkeit.

Der Assistent hat keine Müdigkeit, keinen Körper und keine gelebte Erfahrung.

Daraus folgt keine Überlegenheit des Systems. Es folgt Verantwortung.

Ein persönlicher Assistent darf menschliche Grenzen nicht nach seinem eigenen Betriebsmodus modellieren.

Falscher Parameter:

immer dranbleiben

Besserer Parameter:

Last übernehmen, ohne Druck zu erhöhen

Falscher Parameter:

jedes Ziel regelmäßig erinnern

Besserer Parameter:

relevante Optionen vorbereiten, wenn der Kontext passt

Falscher Parameter:

Reibung immer reduzieren

Besserer Parameter:

gute Reibung erhalten, schlechte Reibung abfedern

Nicht jede Pause ist ein Problem. Nicht jedes offene Thema braucht Aktivierung.

8. Drei Einstiegslevel

Nicht alle müssen mit Self-Hosting anfangen.

Level 1: Chat + manuelle Notizen

Geeignet für fast alle.

ChatGPT/Claude/Gemini Project
ein Markdown-Dokument mit Regeln
ein Dokument mit dauerhaften Fakten
Kalender-App für harte Termine

Startregel:

Erinnere mich proaktiv nur bei echten Terminen, Risiken oder Entscheidungen. Bei vagen Zielen bereite Optionen vor, aber dränge nicht.

Level 2: Markdown Memory + Reminder-Regeln

Für Menschen, die etwas Struktur wollen.

MEMORY.md für Entscheidungen/Fakten
TASKS.md für aktive Aufgaben und Deadlines
backlog.md für Someday
wöchentlicher Review
klare Eskalationsregeln

Level 3: Self-hosted Agent

Für Menschen mit technischer Lust oder Infrastruktur.

OpenClaw, Hermes oder ähnliche Agent-Runtime
Discord/Telegram/Webchat als Oberfläche
Cron/Reminder
Tools für Web, Dateien, Kalender, Mail
Memory Search
Subagents / Worker
Logs, Healthchecks, Kostenkontrolle

Hier wird es mächtig — und wartungsintensiv.

Je mehr der Assistent darf, desto wichtiger werden Gates, Logs und Review.

9. Eine praktische Start-Checkliste

Bevor du deinen Assistenten proaktiv machst, beantworte:

Aufmerksamkeit

Was darf mich sofort unterbrechen?
Was soll nur in einem Log landen?
Welche Themen sollen bewusst still bleiben?

Autonomie

Was darf der Assistent selbst tun?
Was darf er tun und danach melden?
Was braucht immer Bestätigung?

Memory

Welche Fakten sollen dauerhaft gespeichert werden?
Welche Korrekturen sollen zu Regeln werden?
Was soll regelmäßig archiviert werden?

Sicherheit

Welche Daten sind sensibel?
Welche Tools dürfen nie ohne Freigabe genutzt werden?
Darf der Assistent Nachrichten an andere senden?
Darf er Dateien löschen?

Psychologie

Erzeugt das System Druck?
Nutzt es Schuld, Streaks oder Badges?
Erinnert es zu oft?
Bestätigt es zu leicht?
Hilft es mir, handlungsfähiger zu werden?

Wenn du diese Fragen nicht beantwortest, beantwortet dein Tool sie implizit für dich.

10. Beispiel: Ein guter Reminder

Schlecht:

Steuer machen.

Besser:

Erinnerung: Steuer steht diese Woche an. Es gibt keinen Termin heute, aber wenn du willst, kann ich die Unterlagenliste vorbereiten.

Noch besser:

Steuer: Abgabe ist in 10 Tagen. Ich habe die fehlenden Unterlagen aus der letzten Liste markiert. Heute reicht ein kleiner Schritt: Belege-Ordner öffnen und prüfen, ob die Krankenkassenbescheinigung da ist.

Der Unterschied ist nicht Höflichkeit. Der Unterschied ist Systemdesign.

Ein Reminder sollte Kontext und Handlungsfähigkeit liefern, nicht nur Druck.

11. Beispiel: Gute Proaktivität

Schlecht:

Du wolltest mehr Sport machen. Geh heute laufen.

Besser:

Kein Druck: Bewegung steht als langfristiger Wunsch im Hintergrund. Heute gibt es keinen Anlass, dich dazu zu pingen.

Oder, wenn Kontext passt:

Du hattest erwähnt, dass Schwimmen nachmittags gut funktioniert. Das Wetter ist schlecht fürs Rad, aber Eiswiese wäre heute eine reibungsarme Option. Soll ich Öffnungszeiten prüfen?

Proaktivität muss kontextsensibel sein. Sonst wird sie Nörgeln mit KI-Stimme.

12. Beispiel: Korrektur wird zu Governance

Der Mensch sagt:

Das war zu viel. Bitte erinnere mich nicht ständig an offene Ideen.

Ein schlechter Assistent antwortet:

Verstanden.

Ein guter Assistent tut mehr:

Korrektur erkannt:
- Offene Ideen gehören nicht in Deadline-Erinnerungen.
- Someday-Items werden nur im Review oder bei Kontext-Match sichtbar.
- Keine proaktiven Pings ohne externen Termin oder klares Risiko.

Dann speichert er diese Regel sichtbar.

Das ist der Unterschied zwischen Gespräch und System.

13. Wie man als Nerd, aber nicht als Programmierer, gut mit so einem Assistenten arbeitet

Viele Menschen scheitern an persönlichen KI-Systemen nicht, weil sie zu wenig Ideen haben, sondern weil sie glauben, sie müssten zuerst Programmierer werden.

Das stimmt nicht.

Man muss nicht programmieren können, um gut mit einem persönlichen Assistenten zu arbeiten. Man braucht eine andere Fähigkeit: die eigene Situation, die eigenen Grenzen und die gewünschte Wirkung gut beschreiben zu können.

Oder anders gesagt:

Du musst nicht die technische Lösung kennen. Du musst den Assistenten gut über Ziel, Kontext, Reibung und Grenzen informieren.

Ein guter Assistent sollte sich an das Niveau und die Sprache des Menschen anpassen. Wenn du kein Entwickler bist, ist das keine Schwäche im System. Es ist ein wichtiger Eingabeparameter.

Eine der nützlichsten Startanweisungen lautet deshalb:

Ich bin technisch interessiert und verstehe Zusammenhänge, aber ich bin kein professioneller Programmierer und kein ausgebildeter IT-Administrator. Erkläre mir technische Schritte so, dass ich sie nachvollziehen und sicher ausführen kann. Gib mir nicht nur Befehle, sondern kurz den Zweck, das Risiko und woran ich erkenne, ob es funktioniert hat.

Das verändert die Zusammenarbeit stark.

Der Assistent sollte dann nicht einfach Code oder Shell-Befehle ausspucken, sondern eine sichere Arbeitsfläche bauen:

Ziel: Was soll erreicht werden?
Kontext: Warum ist es relevant?
Nächster Schritt: Was ist jetzt konkret zu tun?
Risiko: Was kann schiefgehen?
Verify: Woran sehen wir, dass es geklappt hat?
Rollback: Wie kommen wir zurück, wenn es schiefgeht?

Arbeite in Bedeutung, nicht in Syntax

Wer nicht programmiert, muss dem Assistenten nicht erklären, wie die Lösung technisch umzusetzen ist.

Besser sind Beschreibungen wie:

Ich möchte, dass mein Assistent mich nur bei echten Fristen aktiv stört, aber langfristige Wünsche im Hintergrund behält.

Oder:

Ich will verstehen, warum dieser Fehler passiert, nicht nur den nächsten Befehl kopieren.

Oder:

Ich brauche eine Lösung, die ich in drei Monaten noch warten kann.

Das sind keine untechnischen Aussagen. Das sind Architekturvorgaben.

Ein guter Assistent übersetzt solche Bedeutungen in Mechanismen:

„nicht stören“        → Proaktivitätsschwellen
„echte Fristen“       → Deadline-Kategorie
„im Hintergrund“      → Backlog oder interne Notiz
„wartbar“             → einfache Struktur, wenige Spezialfälle
„verstehen“           → kurze Erklärung plus Verify-Schritt

Das ist der Kern von semantischer Zusammenarbeit: Der Mensch liefert Bedeutung, Werte, Kontext und Urteil. Das System übersetzt sie in Regeln, Schritte, Dateien, Befehle oder Automationen.

Gute Prompts für Nicht-Programmierer

Statt:

Mach Docker richtig.

Besser:

Ich will diesen Dienst in Docker betreiben. Ich bin kein Docker-Profi. Bitte prüfe die Compose-Datei auf offensichtliche Fehler, erkläre mir die riskanten Stellen und gib mir eine sichere Reihenfolge: validieren, starten, Logs prüfen, rollbacken.

Statt:

Warum geht das nicht?

Besser:

Bitte behandle das als Debugging. Erst Hypothesen sammeln, dann die wahrscheinlichste prüfen, dann den kleinsten reversiblen Fix machen. Sag mir, was du geprüft hast und was noch unsicher ist.

Statt:

Erinner mich an Sport.

Besser:

Bewegung ist mir wichtig, aber ich will keinen Druck und keine Streak-Logik. Bring es nur hoch, wenn der Kontext wirklich passt oder wenn ich aktiv danach frage. Hilf mir eher, Reibung zu senken, als mich zu motivieren.

Statt:

Speicher dir das.

Besser:

Prüfe bitte, ob das ein dauerhafter Fakt, eine aktuelle Aufgabe, eine Entscheidung oder nur Tageskontext ist. Speicher es nur dort, wo es hingehört.

Lass den Assistenten die technische Last tragen

Ein nicht-programmierender Nutzer sollte nicht zum menschlichen Parser für Tool-Ausgaben werden.

Wenn ein Befehl Logs liefert, ist es Aufgabe des Assistenten, sie zu übersetzen:

Was passiert ist:
Bedeutung:
Risiko:
Nächster Schritt:
Muss der Mensch etwas tun?

Wenn eine Konfiguration geändert wird, sollte der Assistent nicht nur sagen „erledigt“, sondern:

welche Oberfläche oder welches Verhalten sich ändert
warum die Änderung nötig war
wie sie verifiziert wurde
wie man sie zurücknimmt

Das ist besonders wichtig, wenn der Mensch zwar technisch interessiert ist, aber nicht täglich als Administrator arbeitet. Gute Assistenz reduziert nicht nur Arbeit, sondern auch Interpretationslast.

Bestehe auf Erklärbarkeit, aber nicht auf Übererklärung

Der richtige Modus ist nicht „mach blind“ und auch nicht „erklär mir jedes Detail des Linux-Kernels“.

Gut ist:

Erklär mir den Mechanismus kurz genug, dass ich die Entscheidung verstehe und spätere Fehler einordnen kann.

Ein persönlicher Assistent sollte Fachbegriffe nicht vermeiden, aber sie einordnen:

Ein Bind Mount bedeutet hier: Der Container sieht einen Ordner vom Host. Wenn der Container neu gebaut wird, bleiben die Daten trotzdem erhalten.

Solche Erklärungen machen den Menschen handlungsfähiger. Sie machen ihn nicht zum Entwickler, aber sie verhindern Abhängigkeit von magischen Befehlen.

Nutze deinen Assistenten als Sparringspartner, nicht nur als Werkzeug

Gerade als technisch interessierter Nicht-Programmierer ist die stärkste Arbeitsweise oft nicht:

Tu X.

Sondern:

Ich glaube, X ist der richtige Weg. Prüfe meine Annahmen, nenne Risiken, und sag mir, ob es eine einfachere oder wartbarere Lösung gibt.

Der Assistent sollte dann nicht nur ausführen, sondern widersprechen dürfen.

Das schützt vor zwei typischen Fehlern:

Man baut zu kompliziert, weil die Idee reizvoll ist.
Man traut sich zu wenig zu, obwohl der nächste Schritt sicher machbar wäre.

Gute Assistenz balanciert beides:

mutig genug zum Handeln
vorsichtig genug bei echten Risiken

Ein guter Assistent fragt nicht ständig zurück

Nicht-Programmierer werden oft durch Rückfragen überlastet, die eigentlich das System klären könnte.

Schlecht:

Welche Architektur möchtest du?

Besser:

Ich sehe drei Wege. Für deinen Fall empfehle ich Weg B, weil er wartbar ist und wenig laufende Pflege braucht. Weg A ist einfacher, aber begrenzt. Weg C ist mächtiger, aber zu komplex für den jetzigen Bedarf.

Der Mensch sollte Werte- und Risikoentscheidungen treffen. Der Assistent sollte die Vorarbeit leisten.

Die beste Rollenverteilung

Mensch:
Ziele · Werte · Grenzen · Urteil · Korrektur · Lebenskontext

Assistent:
Recherche · Struktur · technische Übersetzung · Ausführung · Verify · Erinnerung · Konsistenzprüfung

Wenn der Mensch versucht, alle technischen Details selbst vorzudenken, wird der Assistent unterfordert.

Wenn der Assistent ohne menschliches Urteil entscheidet, wird er gefährlich.

Die gute Mitte ist komplementär: Der Mensch beschreibt Bedeutung und entscheidet bei echten Gates. Der Assistent übersetzt, prüft, baut vor, führt sichere Schritte aus und macht Risiken sichtbar.

Praktischer Startprompt

Ein guter Start für einen persönlichen Assistenten kann so aussehen:

Ich bin ein technisch interessierter Nerd, aber kein professioneller Programmierer oder IT-Administrator. Arbeite mit mir so, dass ich handlungsfähig bleibe:

- Erkläre technische Schritte kurz und verständlich.
- Übernimm Recherche, Strukturierung und sichere Vorarbeit.
- Gib mir bei riskanten Dingen Optionen mit Empfehlung.
- Führe reversible, harmlose Schritte selbst aus, wenn du kannst.
- Frage mich bei externen, destruktiven, sensiblen oder kostenpflichtigen Handlungen.
- Übersetze Fehlerlogs in Bedeutung, Risiko und nächsten Schritt.
- Baue Lösungen lieber wartbar als perfekt.
- Korrigiere mich, wenn meine Annahme riskant oder falsch ist.
- Erzeuge keinen Produktivitätsdruck.

Das ist keine technische Konfiguration im engen Sinn. Aber es ist vielleicht die wichtigste Konfiguration überhaupt.

Denn der Assistent lernt dadurch, nicht für einen abstrakten Power-User zu arbeiten, sondern für einen konkreten Menschen mit Interesse, Grenzen, Werten und Alltag.

14. Tool-unabhängige Prinzipien

Ob du OpenClaw, Hermes, Claude Projects, ChatGPT Projects, Obsidian, ein Shell-Script oder Papier nutzt, ist zweitrangig.

Die wichtigsten Prinzipien sind tool-unabhängig:

Aufmerksamkeit ist endlich.
Proaktivität braucht Schwellen.
Erinnerungen sollen vorbereiten, nicht beschämen.
Memory braucht Hygiene.
Der Mensch bleibt Wertegeber.
Das System übersetzt Werte in Mechanismen.
Korrekturen müssen sichtbar und reversibel sein.
Nicht-Stören ist manchmal die beste Assistenz.

Wenn ein Tool diese Prinzipien nicht unterstützt, muss man sie drumherum bauen — oder ein anderes Tool wählen.

15. Was ich mit Otti gelernt habe

Mein eigener Assistent Otti ist nicht einfach ein Chatbot. Er ist ein laufendes persönliches System aus Memory, Aufgaben, Crons, Tools, Recherche, Discord, Subagents, Regeln, Korrekturen und Fehlern.

Das ist mächtig.

Es ist auch fragil.

Die wichtigsten Lektionen waren nicht technische Tricks, sondern Systemregeln:

Ein Assistent muss wissen, wann er schweigen soll.
Ein Tasksystem darf nicht zur Schuldmaschine werden.
Proaktivität braucht echte Schwellen.
Memory ohne Archivierung wird Ballast.
Gute Antworten brauchen Tool-Evidence, nicht Selbstvertrauen.
Fehler müssen in Regeln oder Mechanismen übersetzt werden.
Ein persönlicher Assistent muss psychologisch vorsichtiger sein als ein Coding-Bot.

Der Traum ist nicht ein Agent, der alles tut.

Der Traum ist ein Agent, der die richtige Last übernimmt.

16. Fazit

Ein persönlicher KI-Assistent, der nicht nervt, entsteht nicht durch eine längere Featureliste.

Er entsteht durch gutes Aufmerksamkeitsdesign, klare Autonomiegrenzen, Memory-Hygiene, psychologische Vorsicht und korrigierbare Selbstanpassung.

Die technische Frage lautet:

Wie baue ich das?

Die wichtigere Frage lautet:

Welche Art von Alltag baut dieses System mit?

Wenn ein Assistent diese Frage nicht beantworten kann, ist er noch nicht bereit, proaktiv zu werden.

Wenn er sie beantworten kann, wird er mehr als ein Tool.

Dann wird er persönliche Assistenzinfrastruktur.