PersonalOS: Gemeinsamer Kontext für KI-Agenten

Wie gemeinsamer Kontext verhindert, dass Codex, Claude und andere KI-Agenten mit veralteten Annahmen arbeiten oder Entscheidungen immer wieder neu treffen.

Veröffentlicht: 2026-09-21. Aktualisiert: 2026-09-22.

Welches Problem löst PersonalOS?

Sobald mehrere KI-Werkzeuge an denselben Projekten arbeiten, entsteht ein unscheinbares Problem: Jedes Werkzeug kennt nur seinen eigenen Ausschnitt. Ein Agent sieht das Repository. Ein anderer kennt ein Gespräch. Ein dritter hat Zugriff auf Rechercheergebnisse. Alle können lokal sinnvoll handeln und trotzdem gemeinsam in unterschiedliche Richtungen laufen.

Typische Folgen sind:

• dieselbe Grundsatzfrage wird in mehreren Sitzungen neu beantwortet,
• eine alte Entscheidung wird überschrieben, weil ihre Begründung fehlt,
• ein offener Vorschlag wird als festgelegter Plan behandelt,
• der nächste Schritt wird aus vorhandenen Aufgaben erraten,
• ein technisch korrektes Ergebnis passt nicht mehr zum eigentlichen Ziel.

Das ist kein Modellproblem. Ein größeres Modell kann fehlenden Kontext besser kaschieren, aber nicht zuverlässig ergänzen. Wenn die Arbeitsgrundlage widersprüchlich oder veraltet ist, skaliert ein leistungsfähiger Agent vor allem die falsche Richtung.

Warum reicht die Erinnerung eines einzelnen Agenten nicht?

Chatverläufe und agenteneigene Erinnerungen sind hilfreich, aber sie bilden keine gemeinsame Quelle der Wahrheit. Sie sind an ein Werkzeug, eine Sitzung oder einen Anbieter gebunden. Außerdem vermischen sie oft Beobachtungen, Vorschläge und Entscheidungen.

Auch eine große Projektdatei löst das Problem nur teilweise. Eine AGENTS.md oder CLAUDE.md eignet sich gut für stabile Regeln: Build-Kommandos, Architekturgrenzen, Namenskonventionen oder Sicherheitsvorgaben. Der aktuelle Stand eines Vorhabens ändert sich dagegen laufend. Wird beides in einer Datei vermischt, wird sie lang, schwer zu pflegen und schnell widersprüchlich.

PersonalOS trennt deshalb zwei Dinge:

1. Die dauerhafte Arbeitsweise bleibt im jeweiligen Projekt.
2. Der veränderliche Kontext wird pro Arbeitsbereich strukturiert verdichtet.

Der Agent liest beides. Er bekommt die Regeln aus dem Projekt und den aktuellen Zusammenhang aus PersonalOS.

Welche Informationen gehören in eine gemeinsame Kontextschicht?

Ich verwende fünf Rollen, die zusammen eine belastbare Arbeitsgrundlage ergeben.

Zweck

Der Zweck beschreibt, wofür ein Arbeitsbereich existiert, welcher Zustand erreicht werden soll und warum das relevant ist. Er verhindert, dass ein Agent nur offene Aufgaben optimiert, ohne zu prüfen, ob sie noch auf das Ziel einzahlen.

Aktueller Stand

Hier steht, was heute tatsächlich gilt: veröffentlichte Angebote, aktive Systeme, technische Grenzen oder bekannte Lücken. Der aktuelle Stand ist beschreibend. Er soll nicht heimlich die gewünschte Zukunft vorwegnehmen.

Entscheidungen

Eine Entscheidung enthält nicht nur das Ergebnis, sondern auch die tragende Begründung. Das ist wichtig, weil spätere Agenten sonst eine bewusst gewählte Einschränkung für einen Fehler halten und wieder entfernen.

Nächste Schritte

Der nächste Schritt muss konkret genug sein, dass eine neue Sitzung sinnvoll beginnen kann. Eine lange Liste ersetzt diese Priorisierung nicht. PersonalOS soll deshalb nicht jedes Ticket spiegeln, sondern sichtbar machen, was als Nächstes zählt.

Belege

Belege verbinden Aussagen mit ihrer Quelle: einer Datei, einem Messergebnis, einem Gespräch oder einer Recherche. Ohne diese Verbindung wird ein verdichteter Kontext schnell zu einer Sammlung plausibler Behauptungen.

Wie verhindert PersonalOS widersprüchliche Agentenarbeit?

Alle Werkzeuge greifen auf denselben definierten Lesepfad zu. Sie erhalten für einen Arbeitsbereich ein sogenanntes Context Pack: eine deterministisch erzeugte Zusammenfassung aus Zweck, Stand, Entscheidungen, nächsten Schritten und Belegen.

Deterministisch bedeutet hier: Gleiche Quellen und derselbe Stichtag ergeben dieselbe Sicht. Das ist weniger spektakulär als ein Agent, der sich seinen Kontext selbst zusammensucht – aber im Alltag deutlich besser prüfbar. Wenn Codex und Claude Code dieselbe Frage bearbeiten, starten sie nicht mit zufällig unterschiedlichen Suchtreffern.

Das Context Pack meldet außerdem seinen Zustand. Fehlt beispielsweise der Zweck oder gibt es keinen belastbaren nächsten Schritt, wird die Sicht nicht als vollständig dargestellt. Der Agent soll diese Lücke benennen, statt sie mit einer eigenen Vermutung zu füllen.

Warum sind Vorschläge keine Entscheidungen?

Diese Grenze ist eine der wichtigsten im System. Agenten produzieren schnell gute Ideen. Genau deshalb ist es gefährlich, jeden Entwurf sofort in den verbindlichen Kontext zu übernehmen.

In PersonalOS landen neue Notizen zunächst als Vorschläge. Sie können einen Befund, eine Erkenntnis oder eine mögliche Entscheidung enthalten. Verbindlich werden sie erst, wenn sie geprüft und in den Bestand übernommen wurden.

Das schützt vor einem häufigen Fehler in automatisierten Arbeitsabläufen: Ein Agent formuliert eine Empfehlung, der nächste liest sie ohne Entstehungskontext und behandelt sie als Auftrag. Durch die Trennung bleibt sichtbar, was gilt und was noch bewertet werden muss.

Wie sieht das in der täglichen Arbeit aus?

Ein Beispiel ist die Weiterentwicklung dieser Website. Im Repository stehen technische Regeln und die aktuelle Positionierung. Suchdaten zeigen, welche Seiten Reichweite und welche Handlungsaufforderungen tatsächlich Interaktion erzeugen. PersonalOS hält fest, welche Schlussfolgerungen daraus geprüft, vorgeschlagen oder entschieden wurden.

Öffne ich später eine neue Sitzung in Codex oder Claude Code, muss das Werkzeug nicht aus einzelnen Commits, alten Chats und Analyse-Exporten rekonstruieren, warum eine Seite so aufgebaut ist. Es sieht den Zweck der Website, die gültigen Entscheidungen und den nächsten sinnvollen Schritt. Die eigentliche Arbeit bleibt im Repository; PersonalOS liefert die Orientierung.

Dasselbe Prinzip nutze ich für Recherche und Betrieb. Hermes kann neue Informationen sammeln, während ein Coding-Agent eine technische Änderung vorbereitet. Beide Ergebnisse werden nicht ungeprüft vermischt. Belege bleiben Belege, Vorschläge bleiben Vorschläge und Entscheidungen bleiben nachvollziehbar.

Was PersonalOS bewusst nicht übernimmt

Eine gemeinsame Kontextschicht sollte nicht zum neuen Monolithen werden. Deshalb bleiben einige Dinge außerhalb:

• Quellcode und technische Dokumentation bleiben im Repository.
• Aufgaben und Prioritäten bleiben im dafür vorgesehenen System.
• Rohdaten und große Dokumente bleiben an ihrer Originalquelle.
• Zugangsdaten und geheime Werte gehören nicht in den Agentenkontext.
• Fachliche oder geschäftliche Entscheidungen bleiben menschliche Verantwortung.

PersonalOS speichert die Einordnung und den belastbaren Zusammenhang. Es ersetzt die Primärquellen nicht.

Wann lohnt sich so ein System?

Für ein kleines Einmalprojekt wäre PersonalOS zu viel. Eine gute README, klare Projektregeln und ein sauberer Ticketstand reichen dort meistens aus.

Eine gemeinsame Kontextschicht wird interessant, wenn mehrere dieser Punkte zutreffen:

• verschiedene Agenten oder Modelle arbeiten am selben Produkt,
• Entscheidungen müssen über Wochen oder Monate stabil bleiben,
• Wissen liegt über Repository, Dokumente, Gespräche und Recherche verteilt,
• neue Sitzungen beginnen regelmäßig mit denselben Rückfragen,
• Fehler entstehen weniger durch fehlenden Code als durch fehlende Einordnung.

Der Einstieg muss trotzdem klein bleiben. Ein Arbeitsbereich mit klar formuliertem Zweck, wenigen gültigen Entscheidungen und genau einem nächsten Schritt ist wertvoller als eine umfangreiche Wissensdatenbank ohne Pflegeprozess.

Wie lässt sich das Prinzip im Unternehmen anwenden?

Unternehmen müssen dafür nicht mein System übernehmen. Die Architekturidee ist wichtiger als die konkrete Implementierung:

1. Definieren Sie pro Produkt oder Prozess eine verantwortliche Kontextquelle.
2. Trennen Sie Regeln, Ist-Stand, Entscheidungen und Vorschläge.
3. Verknüpfen Sie wichtige Aussagen mit prüfbaren Belegen.
4. Geben Sie allen Agenten denselben kontrollierten Lesepfad.
5. Machen Sie fehlenden oder veralteten Kontext sichtbar.

Ein solcher Aufbau passt besonders zu internen Wissensassistenten und agentischen Workflows. Bevor ein Agent Aktionen ausführt, braucht er nicht möglichst viel Text, sondern den richtigen, gültigen und überprüfbaren Kontext.

Wenn Sie einen KI-Agenten oder einen internen Wissensworkflow planen, kläre ich in der Produkt-Discovery zuerst Ziel, Datenquellen, Berechtigungen und den kleinsten belastbaren Scope. Wie sich ein wissensbasierter Assistent technisch einordnen lässt, zeige ich außerdem im Beitrag RAG vs. Fine-Tuning und auf der Seite zum Wissensassistenten für Unternehmen.

Kann ich ein Unternehmens-PersonalOS entwickeln lassen?

Ja, als individuell abgegrenztes KI-Produkt. Ich übertrage dafür nicht einfach mein persönliches Setup auf Ihr Unternehmen. Ausgangspunkt sind Ihre Prozesse, Datenquellen, Zuständigkeiten und Zugriffsregeln. Das Ergebnis soll ein lauffähiges System mit kontrollierter Kontextversorgung, vereinbarten Agent-Workflows, Tests und dokumentierter Übergabe sein.

Ein erster Umfang könnte zum Beispiel einen Arbeitsbereich, ausgewählte Wissensquellen und einen freizugebenden Wochenbericht umfassen. Das ist ein mögliches Umsetzungsszenario, kein belegtes Kundenprojekt oder fertiges Standardpaket. Weitere Quellen und Aktionen kommen erst nach einer überprüfbaren Abnahme hinzu. Claude Code, Codex oder Hermes können Bausteine sein; sie bestimmen nicht den Zweck des Systems.

Zur KI-Produktentwicklung gehören neben der Anbindung auch der Umgang mit veralteten Informationen, getrennte Rollen und die Frage, wer einen Vorschlag zum gültigen Beschluss machen darf. Betrieb und Weiterentwicklung nach der Übergabe vereinbare ich bei Bedarf separat.

Kostenloses Erstgespräch buchen — oder das Vorhaben schriftlich schildern.

Häufige Fragen

Was ist PersonalOS?

PersonalOS ist meine gemeinsame Kontextschicht für verschiedene KI-Agenten und Arbeitsoberflächen. Es bündelt pro Arbeitsbereich den Zweck, den aktuellen Stand, getroffene Entscheidungen, nächste Schritte und Belege, damit Werkzeuge nicht bei jeder Sitzung mit unterschiedlichen Annahmen beginnen.

Ist PersonalOS ein zweites Projektmanagement-Tool?

Nein. Aufgaben bleiben im jeweiligen Projekt- oder Ticketsystem, Quellcode im Repository und Dokumente an ihrem bestehenden Ort. PersonalOS liefert den verdichteten Kontext, der diese Quellen für Menschen und Agenten einordnet.

Warum reicht eine einzelne AGENTS.md- oder CLAUDE.md-Datei nicht aus?

Solche Dateien sind wichtig für stabile Arbeitsregeln, werden aber schnell unübersichtlich, wenn dort zusätzlich Entscheidungen, Tagesstand und offene Schritte landen. PersonalOS trennt dauerhafte Regeln von veränderlichem Arbeitskontext und kann beides gezielt zusammenführen.

Welche KI-Werkzeuge können dieselbe Kontextschicht nutzen?

Das Prinzip ist werkzeugunabhängig. In meinem Setup greifen Codex, Claude Code, Kiro und Hermes auf dieselbe strukturierte Sicht zu. Entscheidend ist nicht das konkrete Modell, sondern ein gemeinsamer, kontrollierter Lesepfad.

Wann lohnt sich eine gemeinsame Kontextschicht?

Sie lohnt sich, wenn mehrere Agenten oder Personen wiederholt am selben Produkt arbeiten, Entscheidungen über Sitzungen hinweg gelten und verstreute Quellen regelmäßig zu Rückfragen oder Fehlannahmen führen. Für ein kleines Einmalprojekt reicht meist eine gute Projektdatei.

• Produkt-Discovery
• RAG vs. Fine-Tuning
• Wissensassistenten für Unternehmen
• KI-Produktentwicklung
• Zur Blog-Uebersicht
• Leistungen & Use Cases