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.