Ein Agent braucht einen Arbeitsraum, nicht nur eine Persona

Eine Persona prägt die Stimme. Ein Arbeitsraum prägt das Verhalten – und macht sichtbar, was ein Agent weiß, darf, verändert und übergibt.

Eine freundlich formulierte Persona kann Zusammenarbeit angenehmer machen. Sie kann eine kritische Gegenposition einnehmen, Fragen aus Sicht einer Fachrolle stellen oder einen wiedererkennbaren Ton halten. Doch sobald ein System Dateien liest, Pläne fortschreibt, Werkzeuge aufruft oder Entscheidungen vorbereitet, reicht Charakterbeschreibung nicht mehr aus.

Ein Agent scheitert selten daran, dass seine Biografie zu kurz ist. Er scheitert, weil Ziel und Abschlusszustand unklar bleiben, Quellen widersprüchlich sind, der aktuelle Projektstand nur im Chat steckt, Berechtigungen zu weit reichen oder niemand weiß, welche Änderung bereits ausgeführt wurde. Die Lösung ist kein hundertseitiges Persönlichkeitsprofil. Sie ist ein expliziter Arbeitsraum.

Persona, Rolle und Agent sind drei verschiedene Schichten

Eine Persona beschreibt Perspektive, Ton und Interaktionsstil. Eine Rolle definiert Verantwortung: beraten, prüfen, extrahieren, freigeben oder ausführen. Ein Agent verbindet ein Modell mit Zustand, Werkzeugen und einer Handlungsschleife. Er beobachtet, plant, handelt, prüft und aktualisiert seinen Arbeitsstand.

Diese Schichten dürfen kombiniert, aber nicht verwechselt werden. „Sei eine erfahrene Strategieberaterin“ erzeugt weder verlässliche Marktdaten noch ein Freigaberecht. „Arbeite proaktiv“ definiert keine zulässigen Tools. „Handle kritisch“ ersetzt keinen Abnahmetest. Eine Persona kann die Kommunikation konsistent machen; operative Zuverlässigkeit entsteht aus überprüfbaren Regeln und technischer Begrenzung.

Das schützt auch vor falschem Vertrauen. Konstante Sprache wirkt schnell wie konstantes Wissen. Ein System kann jedoch im selben souveränen Ton richtige, veraltete und erfundene Aussagen formulieren. Deshalb muss Vertrauen an Evidenz, Provenienz, Tests und kontrollierte Handlungen gebunden werden – nicht an Persönlichkeit.

Der Arbeitsraum ist externalisierter Projektzustand

Ein belastbarer Arbeitsraum beantwortet zu Beginn jeder Sitzung dieselben Fragen: Was ist das Ziel? Was ist bereits erledigt? Welche Quellen gelten? Welche Artefakte sind aktuell? Was ist offen oder blockiert? Welche Änderungen sind erlaubt? Was muss ein Mensch entscheiden?

Diese Informationen gehören nicht ausschließlich in das flüchtige Gespräch. Sie werden als strukturierter Zustand außerhalb des Modells geführt. Ein schlanker Projektraum kann beispielsweise enthalten:

project/
  brief.md             # Ziel, Scope, Nicht-Ziele
  status.md            # Ist-Stand, offene Punkte, Blocker
  sources/             # freigegebene Eingaben mit Herkunft
  decisions.md         # Entscheidungen und Begründungen
  artifacts/           # erzeugte Ergebnisse
  checks/              # Tests und Abnahmekriterien
  handoff.md           # Übergabe für die nächste Sitzung

Die Namen sind austauschbar; die Funktionen nicht. Der Agent benötigt eine Quelle der Wahrheit, eine klare Trennung zwischen Input und Output sowie einen reproduzierbaren Einstieg. Ein Chatprotokoll kann zusätzliche Historie liefern, ist aber kein zuverlässiger Projektindex. Lange Gespräche enthalten überholte Vorschläge, verworfene Varianten und implizite Annahmen. Ein Statusdokument verdichtet nur den gültigen Stand und verweist auf die Evidenz.

Ein Ziel braucht einen prüfbaren Endzustand

„Erstelle eine gute Analyse“ ist eine Absicht, aber kein Abschlusskriterium. Ein Agent braucht einen Zielvertrag: erwartete Artefakte, Qualitätsmerkmale, Grenzen und Definition of Done. Für eine Analyse könnte dies bedeuten: drei benannte Quellenklassen, sichtbare Unsicherheiten, nachvollziehbare Rechenwege, getrennte Fakten und Empfehlungen sowie eine Liste offener Entscheidungen.

Der Vertrag verhindert, dass Aktivität mit Fortschritt verwechselt wird. Der Agent darf eine Aufgabe erst als abgeschlossen markieren, wenn die vereinbarten Nachweise vorliegen. Fehlt eine Quelle, wird nicht sprachlich aufgefüllt, sondern ein Blocker gesetzt. Widerspricht ein Test dem Ergebnis, wird der Status nicht grün formuliert, sondern die Abweichung dokumentiert.

Ein hilfreiches Statusmodell unterscheidet mindestens geplant, in Arbeit, zur Prüfung, blockiert, abgenommen und verworfen. Jeder Übergang benötigt einen Auslöser. So wird aus einer Reihe plausibler Textantworten ein beobachtbarer Prozess.

Quellenhierarchie schlägt Kontextmenge

Mehr Dateien bedeuten nicht automatisch mehr Kontextqualität. Ein Arbeitsraum braucht eine Rangfolge: verbindliche Spezifikation vor informeller Notiz, freigegebene Version vor Entwurf, Primärquelle vor Zusammenfassung, aktueller Stand vor Archiv. Bei Konflikten entscheidet nicht der zufällig zuletzt geladene Absatz, sondern die definierte Priorität.

Jede wichtige Quelle sollte Herkunft, Datum, Geltungsbereich und Status tragen. W3C PROV liefert ein formales Vokabular, um Entitäten, Aktivitäten und Verantwortlichkeit zu beschreiben. Im Alltag reicht häufig eine leichtere Provenienzkarte: Woher stammt das Dokument? Wer hat es freigegeben? Welche Transformation wurde angewandt? Welches Ergebnis leitet sich daraus ab?

Der Agent protokolliert außerdem, welche Quellen tatsächlich verwendet wurden. „Im Projektordner vorhanden“ ist nicht dasselbe wie „für diese Entscheidung herangezogen“. Diese Unterscheidung ermöglicht spätere Prüfung und verhindert, dass ein Ergebnis mit einer großen, aber irrelevanten Wissenssammlung legitimiert wird.

Werkzeuge brauchen Fähigkeiten und Grenzen

Ein Arbeitsraum enthält nicht nur Informationen, sondern auch eine Berechtigungsmatrix. Für jedes Tool werden Zweck, erlaubte Objekte, maximaler Umfang, Vorschaupflicht und Bestätigungsschwelle festgelegt. Ein Rechercheagent darf lesen und Notizen erzeugen, aber keine Originale überschreiben. Ein Dokumentagent darf in einen Ausgabeordner schreiben, aber nicht veröffentlichen. Eine Transaktion wird zunächst simuliert und erst nach expliziter Freigabe ausgeführt.

Diese Trennung folgt dem Prinzip minimaler Befugnis. OWASP weist bei agentischen Systemen auf Risiken wie Tool-Missbrauch, Zielmanipulation und unkontrollierte Handlungsketten hin. Sprachliche Verbote sind dafür notwendig, aber nicht ausreichend. Der Host muss Rechte technisch erzwingen, Eingaben validieren, Ausgaben prüfen, Timeouts setzen und sensible Aktionen sichtbar machen.

Auch der Handlungsspielraum wird begrenzt: maximale Schritte, Kostenbudget, erlaubte Laufzeit, Retry-Zahl und Abbruchbedingungen. Ohne solche Grenzen kann ein Agent Fehler wiederholen, Ressourcen verbrauchen oder Nebenwirkungen vervielfachen.

Planen, handeln, beobachten – aber nicht blind kreisen

Die ReAct-Arbeit zeigt die Nützlichkeit einer Schleife aus Schlussfolgern, Handeln und Beobachten. Für reale Projekte sollte diese Idee um explizite Prüfpunkte ergänzt werden. Vor einer Aktion wird geprüft: Ist die Voraussetzung erfüllt? Ist das Tool erlaubt? Ist die Operation reversibel? Nach der Aktion wird nicht nur die Rückmeldung des Modells betrachtet, sondern der tatsächliche Zustand.

Ein robuster Zyklus lautet: Zustand lesen → nächsten Schritt wählen → Berechtigung prüfen → ausführen → Ergebnis beobachten → gegen Akzeptanzkriterium testen → Status aktualisieren. Schlägt ein Gate fehl, führt der Weg zu Korrektur, Eskalation oder sicherem Abbruch – nicht automatisch zur nächsten Aktion.