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.

Deterministische Prüfungen gehören in Code oder Regeln: Dateiexistenz, Schema, Hash, Summen, Linkstatus und Tests. Das Modell interpretiert unklare Situationen; es sollte mechanische Wahrheit nicht aus Formulierungen erraten.

Kontrollpunkte sind risikobasiert, nicht dekorativ

Human-in-the-Loop bedeutet nicht, nach jedem kleinen Schritt auf „OK“ zu klicken. Zu viele triviale Freigaben erzeugen Müdigkeit; zu wenige verlagern kritische Entscheidungen unsichtbar in das System. Der Arbeitsraum setzt Checkpoints dort, wo Schaden, Irreversibilität, Unsicherheit oder Außenwirkung steigen.

Typische Freigabepunkte sind Veröffentlichung, externe Kommunikation, Geldbewegung, Zugriff auf sensible Daten, Löschung, Rechteänderung und Entscheidungen über Personen. Der Agent liefert dafür ein Entscheidungspaket: geplante Aktion, betroffene Objekte, Evidenz, Unsicherheit, Alternativen, erwartete Nebenwirkungen und Rücknahmeweg.

Eine Freigabe gilt nur für den gezeigten Umfang. Ändert sich Ziel, Datenbasis oder Aktion, muss erneut geprüft werden. Sonst wird ein kleiner Zustimmungsmoment zur pauschalen Vollmacht.

Unabhängige Kontrolle braucht echte Distanz

Eine zweite Modellantwort kann Fehler finden, ist aber nicht automatisch unabhängig. Wenn Prüfer und Ersteller dieselben Quellen, Annahmen und blinden Flecken teilen, entsteht nur sprachliche Variation. Kontrolle wird stärker, wenn Perspektive und Evidenz getrennt werden.

Der Prüfer erhält klare Kriterien, kann Primärquellen eigenständig öffnen und sieht die Behauptungen samt Belegen. Kritische Ergebnisse werden zusätzlich durch deterministische Tests, Stichproben oder Fachverantwortliche abgesichert. Modellvielfalt kann nützlich sein, ersetzt aber keine gute Evaluationsmethode.

Der Arbeitsraum speichert deshalb nicht bloß „geprüft“, sondern Prüfer, Prüfumfang, Methode, Befund und verbleibendes Risiko. Ein Review ohne sichtbaren Maßstab ist eine Meinung; ein Review mit Testfall und Evidenz wird zu einer Kontrollleistung.

Übergabe ist ein eigenes Artefakt

Agentische Arbeit läuft über Sitzungen, Modelle und Menschen hinweg. Ohne Übergabe beginnt jede Instanz mit Rekonstruktion. Dabei gehen Gründe verloren, verworfene Wege werden erneut ausprobiert und veraltete Annahmen kehren zurück.

Eine gute Übergabe enthält Ziel und Scope, aktuellen Zustand, erzeugte Artefakte, verwendete Quellen, Entscheidungen, offene Risiken, nächsten empfohlenen Schritt und alle erforderlichen Freigaben. Sie unterscheidet Tatsachen, Annahmen und Vorschläge. Außerdem nennt sie, was ausdrücklich nicht erneut getan werden soll.

Die nächste Sitzung startet mit einer Konsistenzprüfung: Existieren die referenzierten Dateien? Stimmen Versionen und Hashes? Sind Blocker noch aktuell? Erst dann wird weitergearbeitet. So wird Gedächtnis zu überprüfbarem Zustand statt zu erzählter Erinnerung.

Parallelität braucht Besitzregeln

Mehrere Agenten oder Sessions können Arbeit beschleunigen, aber auch Konflikte erzeugen. Wenn zwei Instanzen dieselbe Datei verändern, ist die letzte Speicherung keine Qualitätsentscheidung. Der Arbeitsraum definiert deshalb Aufgabenbesitz, getrennte Arbeitszweige und Integrationsregeln.

Parallel bearbeitet werden unabhängige Teilaufgaben mit klaren Outputs. Gemeinsame Kerndokumente erhalten einen Owner oder einen Merge-Prozess. Vor Integration werden Konflikte semantisch geprüft: Zwei korrekte Abschnitte können sich fachlich widersprechen. Ein zentraler Status wird erst nach erfolgreicher Integration aktualisiert.

Parallelität ist damit keine bloße Leistungsoption. Sie ist eine Frage von Zustandskonsistenz, Provenienz und Verantwortlichkeit.

Der Agent-Workspace-Canvas

Entwirf für einen realen Anwendungsfall einen Arbeitsraum auf einer Seite:

1. Zielvertrag: Ergebnis, Nicht-Ziele, Definition of Done und Risiko.

2. Zustand: Statusfelder, gültige Artefakte, Blocker und nächste Aktion.

3. Quellen: Hierarchie, Herkunft, Aktualität, Zugriffsrechte und Konfliktregel.

4. Werkzeuge: Erlaubte Funktionen, Scope, Budgets, Vorschau und Bestätigung.

5. Schleife: Beobachtung, Planung, Aktion, Verifikation und Statusübergang.

6. Checkpoints: Welche Entscheidungen brauchen Menschen – und welche Evidenz sehen sie?

7. Protokoll: Welche Handlungen, Quellen, Versionen und Prüfer werden festgehalten?

8. Übergabe: Was muss die nächste Instanz reproduzierbar übernehmen?

9. Abbruch: Welche Fehler, Unsicherheiten oder Grenzwerte stoppen das System?

Teste den Entwurf mit drei Fällen: normaler Ablauf, widersprüchliche Quelle und fehlgeschlagene Tool-Aktion. Wenn der Agent in jedem Fall seinen Zustand erklären, sicher stoppen und eine belastbare Übergabe erzeugen kann, beginnt aus einer Persona ein operatives System zu werden.

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

Einordnung: „Persona" und „Agent" werden in Produkten uneinheitlich verwendet. Dieser Artikel nutzt Persona für eine definierte Perspektive und Agent für ein System, das innerhalb begrenzter Befugnisse Zustände verändert oder Werkzeuge aufruft. Ein Arbeitsraum ist dabei kein bestimmtes Produkt, sondern die kontrollierte Umgebung aus Ziel, Zustand, Quellen, Artefakten, Rechten, Protokollen und Prüfpunkten. Die genannten Rahmen garantieren keine Sicherheit; sie müssen risikoadäquat umgesetzt und getestet werden.