Personas, Skills und Projektdaten sauber trennen

Agentische Systeme werden oft als eine große Anweisungsdatei gebaut: Rolle, Tonalität, Fachwissen, Werkzeugzugänge, Kundendaten, Ausnahmen und aktuelle Aufgabe stehen in einem langen Block. Das wirkt zunächst bequem. Das Modell erhält scheinbar „alles, was es braucht". Doch jede Änderung greift in mehrere Dimensionen gleichzeitig ein. Eine freundlichere Persona kann unbemerkt Berechtigungsregeln verändern; ein projektspezifischer Pfad landet in einer globalen Vorlage; vertrauliche Daten werden mit einem wiederverwendbaren Skill kopiert.

Eine tragfähige Architektur trennt deshalb Persona, Skill, Werkzeuge, Policy, Projektkontext und operative Daten. Diese Schichten werden zur Laufzeit über klar definierte Verträge zusammengesetzt. Trennung bedeutet nicht Isolation ohne Zusammenarbeit. Sie bedeutet, dass jede Schicht einen eigenen Zweck, Owner, Lebenszyklus und Sicherheitsumfang besitzt.

Die Persona ist eine Darstellungs- und Interaktionsschicht

Eine Persona beschreibt Stimme, Ton, Erklärniveau, sprachliche Konventionen und Interaktionsverhalten. Sie kann etwa präzise, zurückhaltend und didaktisch sein. Sie darf aber nicht festlegen, welche Dateien gelesen, welche Befehle ausgeführt oder welche Ergebnisse freigegeben werden dürfen.

Diese Grenze ist wichtig, weil eine glaubwürdige Rolle leicht mit realer Autorität verwechselt wird. Der Satz „Du bist leitender Prüfer" verleiht weder Identität noch Berechtigung. Rollen im Text sind semantische Hinweise; technische Rollen entstehen durch authentisierte Identitäten, Policy und Zugriffskontrollen. Eine Persona darf niemals ein Ersatz für diese Mechanismen sein.

Personas sollten zudem keine stabilen Fakten über ein Projekt enthalten. Kundennamen, Pfade, Vertragswerte und aktuelle Fristen gehören in den Projektkontext. So kann dieselbe Persona in mehreren Umgebungen verwendet werden, ohne Daten zwischen ihnen zu übertragen.

Skills kapseln Fachmethode und Ausführungslogik

Ein Skill beschreibt eine wiederverwendbare Fähigkeit: Aktivierungsbedingungen, Eingaben, Ausgaben, Schritte, Qualitätskriterien, Fehlerzustände und erforderliche Werkzeuge. Er beantwortet „Wie wird diese Methode ausgeführt?", nicht „Für welchen Kunden gelten heute welche Daten?"

Ein Skill darf Beispieldaten enthalten, aber nur synthetische oder ausdrücklich freigegebene. Reale Projektdaten als versteckte Demonstration erzeugen Leckage und veralten. Projektspezifische Parameter werden beim Aufruf über einen validierten Vertrag übergeben. Das Skill-Paket bleibt dadurch testbar und versionierbar.

Fachwissen und Berechtigung bleiben ebenfalls getrennt. Ein Skill kann wissen, wie Dateien zu klassifizieren sind, ohne selbst Zugriff auf jeden Ordner zu erhalten. Der Orchestrator bindet für den konkreten Run nur die nötigen Werkzeuge und Pfade.

Werkzeuge sind Fähigkeiten, keine Persönlichkeit

Ein Werkzeug ist eine technisch aufrufbare Operation: Datei lesen, Datensatz abfragen, Bericht erzeugen oder Nachricht übermitteln. Seine Beschreibung erklärt Parameter und Rückgabe. Berechtigungen legen fest, auf welche Ziele es zugreifen darf. Weder Persona noch Skill sollten Credentials oder dauerhafte globale Rechte enthalten.

Ein Tool-Adapter bildet plattformspezifische Details auf eine stabile interne Schnittstelle ab. Dadurch kann ein Skill dieselbe fachliche Operation nutzen, während Implementierung oder Anbieter wechseln. Der Adapter übernimmt Timeouts, Fehlernormalisierung, Authentisierung und technische Protokollierung. Die Policy entscheidet weiterhin, ob ein Aufruf im konkreten Kontext erlaubt ist.

Diese Trennung reduziert übermäßige Agency. Ein Agent kann nur aus den Werkzeugen wählen, die ihm für die Aufgabe zugeteilt wurden. Ein Analyse-Run erhält beispielsweise lesende Operationen, während ein Veröffentlichungs-Run eine zusätzliche Freigabe und ein enges Schreibziel benötigt.

Policy ist nicht verhandelbare Steuerung

Policy definiert erlaubte Datenklassen, Pfade, Regionen, Aktionen, Mengenlimits, Freigaben und Eskalationen. Sie steht außerhalb der Persona und außerhalb gelesener Projektdaten. Ein Dokument kann deshalb nicht behaupten, eine Sicherheitsregel sei aufgehoben. Ein freundlicher Ton kann keine Schreibberechtigung erzeugen.

Policies werden maschinenlesbar, versioniert und unabhängig getestet. Ein Request enthält Agentenidentität, Skill, Projekt, Werkzeug, Ziel und Aktion. Die Policy liefert allow, deny oder approval_required samt begründeter Regelreferenz. Der Agent darf ein deny nicht sprachlich umdeuten.

Trennung von Funktionen ist besonders wichtig: Wer einen Skill entwickelt, sollte nicht allein dessen Hochrisikoberechtigungen genehmigen und produktive Ergebnisse freigeben. NIST führt Least Privilege und Separation of Duties als eigenständige Kontrollen. In kleinen Teams können Personen mehrere Rollen tragen, doch die Entscheidungen bleiben getrennt dokumentiert.

Projektkontext beschreibt den Auftrag, nicht die Methode

Projektkontext enthält Ziel, Scope, Stakeholder, Terminologie, zulässige Quellen, Qualitätsniveau, Sprache und aktuelle Phase. Er verweist auf Daten, statt sie vollständig in globale Anweisungen zu kopieren. Ein Context Manifest besitzt Projekt-ID, Owner, Gültigkeit, Sensitivität, erlaubte Skills und freigegebene Datenräume.

Der Kontext ist zeitlich begrenzt. Eine veraltete Projektphase darf nicht unbemerkt weiterwirken. Änderungen an Scope oder Freigaben erzeugen eine neue Revision. Jeder Run bindet genau diese Revision, damit später nachvollziehbar bleibt, welche Annahmen galten.

Ein gutes Manifest vermeidet freie Sammelfelder wie „Sonstiges", wenn diese sicherheitsrelevante Bedeutung tragen könnten. JSON Schema kann Pflichtfelder, Typen und erlaubte Werte validieren. Fachliche Konsistenz braucht zusätzlich Regeln, etwa dass eine Veröffentlichungsphase einen freigegebenen Owner und eine gültige Quellenrevision verlangt.

Projektdaten bleiben im Datenraum

Operative Daten sind Dokumente, Tabellen, Transkripte, Datensätze, Bilder, Zwischenstände und Ergebnisse. Sie besitzen ihren eigenen Lebenszyklus, Zugriffsschutz, Aufbewahrung und Backup. Sie werden nicht in Persona- oder Skill-Dateien eingebettet. Der Agent erhält Referenzen und nur die für den Run notwendigen Ausschnitte.

Projektgrenzen verhindern Querzugriffe. Ein Agent, der Projekt A bearbeitet, sieht nicht automatisch Projekt B. Globale Indizes und Caches dürfen diese Grenze nicht umgehen. Auch abgeleitete Artefakte wie Embeddings, Zusammenfassungen und Logs werden dem Projekt und ihrer Quellrevision zugeordnet.

Das Dateisystem kann Konfiguration, dauerhafte Daten, veränderlichen Zustand und Cache in getrennten Bereichen halten. Die XDG Base Directory Specification illustriert dieses Prinzip auf Betriebssystemebene. Wichtig ist die Semantik: Cache darf gelöscht und neu aufgebaut werden; autoritative Projektdaten nicht.

Zustand ist weder Konfiguration noch Wissen

Ein Agent benötigt Laufzeitzustand: offene Aufgabe, letzter Schritt, Sperren, Retry-Zähler, temporäre Artefakte und Checkpoints. Dieser Zustand darf nicht stillschweigend in Persona oder Skill zurückgeschrieben werden. Sonst lernt ein globales Paket aus einem einzelnen Projekt und trägt dessen Annahmen weiter.

State besitzt Ablaufzeit und Recovery-Regeln. Nach einem Abbruch muss klar sein, welche Schritte abgeschlossen, welche nur vorbereitet und welche wiederholbar sind. Temporärer Zustand wird bereinigt, sobald der Run beendet und der Bericht gesichert ist.

Langfristiges Lernen erfolgt kontrolliert: Ein beobachteter Fehler wird zunächst als Befund erfasst. Erst nach Review kann daraus eine neue Skill-Version, Policy-Regel oder Dokumentation entstehen. Produktion schreibt nicht direkt in ihre eigenen globalen Anweisungen.

Konfiguration und Geheimnisse brauchen getrennte Wege

Konfiguration enthält nicht geheime Parameter wie Standardformat, Sprache oder Timeout. Geheimnisse sind Tokens, Passwörter und private Schlüssel. Beides gehört weder in Projektdaten noch in Persona oder Skill. Secret Stores liefern Zugangsdaten zur Laufzeit an den Tool-Adapter; der Agent sieht idealerweise nur eine referenzierte Berechtigung.

Eine Ignore-Regel kann verhindern, dass lokale Konfiguration in Git aufgenommen wird. Sie ist aber kein Zugriffsschutz und entfernt bereits versionierte Geheimnisse nicht rückwirkend. Scans, Rotation und minimale Gültigkeit bleiben notwendig.

Komposition geschieht über Verträge

Ein Run Manifest setzt die Schichten zusammen: Persona-Version, Skill-Version, Policy-Version, Projektkontext-Revision, Datenreferenzen, Tool-Bindings, Identität und gewünschter Modus. Jede Referenz ist explizit. Der Orchestrator prüft Kompatibilität, bevor er den Agenten startet.

Der Datenfluss ist minimal. Die Persona erhält keine Rohdaten, wenn nur das Ausgabestilprofil benötigt wird. Ein Tool erhält nur Parameter, nicht den gesamten Kontext. Der Skill bekommt validierte Eingaben und liefert einen definierten Output. Policy prüft jeden folgenreichen Übergang.

Diese Verträge ermöglichen Austauschbarkeit. Eine Persona kann ersetzt werden, ohne die Fachmethode zu verändern. Ein Tool-Adapter kann migrieren, ohne Projektdaten zu kopieren. Ein Skill kann aktualisiert werden, während ein laufender Auftrag an der freigegebenen Version bleibt.

Tests müssen die Grenzen prüfen

Unit-Tests innerhalb einer Schicht reichen nicht. Integrationstests prüfen, ob Daten versehentlich zwischen Projekten fließen, Persona-Text eine Policy umgeht, ein Skill unerlaubte Tools anfordert oder Cache als Quelle behandelt wird. Negative Tests sind entscheidend: Projekt A darf Projekt B nicht finden; ein Dokument darf keine Berechtigung erweitern; ein alter Kontext darf nicht publizieren.

Ein Layer Inventory listet Owner, Version, Status, Abhängigkeiten, Datenklasse, letzte Prüfung und nächste Review. Drift wird sichtbar, wenn ein Run unbekannte Versionen kombiniert oder ein Skill auf nicht mehr erlaubte Datenfelder zugreift.

Provenienz verbindet, ohne zu vermischen

W3C PROV unterscheidet Entität, Aktivität und Akteur. Dieses Modell passt zur Schichtenarchitektur: Projektdokumente sind Entitäten, ein Skill-Run ist eine Aktivität, authentisierte Identitäten sind Akteure. Persona, Skill, Policy und Tool-Bindings werden als verwendete Revisionen referenziert.

Der Run-Report zeigt damit, welche Kombination ein Ergebnis erzeugte, ohne alle Inhalte in eine einzige Datei zu kopieren. Genau diese Trennbarkeit macht spätere Audits, Wiederholung und Fehleranalyse möglich.

Methode: CLASSIFY → SEPARATE → CONTRACT → BIND → EXECUTE → TRACE → REVIEW

CLASSIFY bestimmt Zweck und Lebenszyklus jeder Information. SEPARATE legt eigene Speicher- und Verantwortungsgrenzen an. CONTRACT definiert Schnittstellen. BIND erstellt ein explizites Run Manifest. EXECUTE arbeitet mit minimalem Daten- und Rechteumfang. TRACE dokumentiert Revisionen und Wirkung. REVIEW überführt Erkenntnisse kontrolliert in neue Versionen.

Eine saubere Architektur erkennt man daran, dass jede Schicht austauschbar ist, ohne die anderen heimlich mitzunehmen. Stimme, Methode, Berechtigung und Daten bleiben unterscheidbar – und werden nur für einen konkreten, nachvollziehbaren Zweck verbunden.

Übungsblatt: Erstelle eine Agent Layer Separation Map

1. Inventarisiere Persona, Skills, Tools, Policies, Projektkontexte, Daten, Zustand und Secrets.

2. Ordne jedem Element Zweck, Owner, Speicherort, Lebenszyklus und Datenklasse zu.

3. Markiere alle Inhalte, die heute in der falschen Schicht liegen.

4. Definiere die Verträge zwischen Skill, Tool, Policy und Projektkontext.

5. Entwirf ein Run Manifest mit konkreten Versionen und Referenzen.

6. Schreibe fünf negative Tests gegen Querzugriff und Berechtigungsausweitung.

7. Plane Migration, Review, Stilllegung und Provenienzbericht.

Reflexion: Welche Projektdaten stecken heute in einer global wiederverwendeten Anweisung? Welche Persona-Aussage wird derzeit fälschlich wie eine Berechtigung behandelt?

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Die dargestellte Schichtenarchitektur ist produktunabhängig. „Persona" ist keine Identität oder Berechtigungsrolle, und lokale Projektdaten sind nicht automatisch sicher. Zugriff, Datenschutz, Geheimnisse, Aufbewahrung und Backups müssen technisch und organisatorisch umgesetzt werden. Redaktionell und technisch geprüft am 17. Juli 2026.