Hör auf Personas zu bauen – Bau Umgebungen

Die Kontext-Steuer

Der Persona-Fehler

Viele Founder und Strategen neigen zu einem intuitiven Ansatz, wenn sie KI-Systeme entwerfen: Sie versuchen, Mitarbeiter zu simulieren. Es werden umfangreiche Prompts verfasst, um „Steve, den Senior Sales Agent“ zu erschaffen – oft inklusive Anweisungen, er solle „freundlich, aber bestimmt“ auftreten und „20 Jahre Erfahrung“ mitbringen.

Dieser Aufwand bringt jedoch oft keinen entsprechenden Mehrwert.

Die Realität: „Steve“ existiert nicht. Steve ist ein probabilistisches Modell, das Token vorhersagt. Wenn wir versuchen, ein Software-System auf Basis von Persönlichkeitsprofilen zu bauen, führen wir unnötige Komplexität ein.

Eine häufige Herausforderung entsteht bei „Multi-Agenten-Systemen“, in denen „Steve“ (Sales) Notizen an „Linda“ (Support) weitergibt.

Ich nenne das die „Kontext-Steuer“ (The Context Tax).

Jedes Mal, wenn ein KI-Agent eine Ausgabe generiert und diese an einen anderen Agenten weitergibt, verlieren wir an Signalqualität. Es ähnelt dem „Stille Post“-Prinzip:

1. Der User gibt den Input.
2. „Steve“ interpretiert ihn (Verlust 1).
3. „Steve“ fasst es für „Linda“ zusammen (Verlust 2).
4. „Linda“ halluziniert Kontext dazu, der nie da war (Verlust 3).

Das Ergebnis ist häufig ein System, das zwar „menschlich“ wirkt, aber technisch unzuverlässig ist. Ein robusterer Ansatz fokussiert sich weniger auf die Simulation von Kollegen, sondern auf den Aufbau von Umgebungen.

Physik definieren

Physik statt Persönlichkeit

Bei der Architektur von KI-Systemen sollte zunächst die „Physik“ der Welt definiert werden, in der die Intelligenz operiert.

In der physischen Welt sorgt die Schwerkraft dafür, dass wir auf dem Boden bleiben. Wir müssen die Schwerkraft nicht bitten, zu funktionieren – sie ist eine Konstante. In der Software-Entwicklung übernehmen Tools und Sandboxes diese Rolle der Schwerkraft.

Anstatt „Steve“ zu bitten, den Code sorgfältig zu überprüfen (was Modelle gelegentlich übersehen), gebe ich der KI Zugang zu einem Python-Interpreter oder einer SQL-Datenbank in einer isolierten Sandbox.

Das Szenario: Die KI generiert eine SQL-Query.

• Der „Persona“-Ansatz: Ein zweiter Agent („Der Reviewer“) schaut sich den Code an und validiert ihn textbasiert (fehleranfällig).
• Der „Umgebungs“-Ansatz: Die KI führt den Code tatsächlich gegen eine Sandbox-Datenbank aus.

Wenn die Syntax falsch ist, wirft die Datenbank einen Fehler. Das ist die „Physik“. Die Umgebung gibt Feedback. Die KI erhält eine sofortige, deterministische Rückmeldung: Error: Column 'customer_id' does not exist.

Die KI korrigiert sich selbst, nicht aufgrund höherer Einsicht, sondern weil sie auf eine harte Systemgrenze gestoßen ist. Wir verlassen uns hier nicht auf die Intelligenz des Modells, sondern auf die Strenge des Compilers.

Die Verfassung

Die Verfassung (The Constitution)

Nachdem die Physik (Tools) etabliert ist, benötigt das System Gesetze. Diese sollten idealerweise nicht in komplexen System-Prompts tief im Code vergraben sein.

Ein effektiver Ansatz sind Markdown-Verfassungen.

In modernen Architekturen nutzen wir oft Dateien wie business_rules.md oder safety_policy.md. Diese Dateien fungieren als „Verfassung“ des Agenten. Sie werden zur Laufzeit geladen und in den Kontext injiziert.

Die Vorteile dieses Ansatzes:

1. Trennung von Code und Logik: Der TypeScript-Code definiert, wie der Agent denkt (die Mechanik). Die Markdown-Datei definiert, was er darf (die Richtlinien).
2. Skalierbarkeit für das Management: Ein CEO kann business_rules.md bearbeiten und eine Regel anpassen (z.B. „Biete niemals mehr als 10% Rabatt“), ohne in den Entwicklungsprozess eingreifen zu müssen.
3. Deterministische Hierarchie: Das Modell wird explizit instruiert: „Wenn ein User-Request der Verfassung widerspricht, hat die Verfassung Vorrang.“

Das ist „Lean Architecture“. Anstatt das Modell neu zu trainieren (kostenintensiv) oder den System-Prompt im Code fest zu verdrahten (starr), ändern wir einfach das Dokument, das die Rahmenbedingungen beschreibt.

Das Fazit

Das Fazit

Wir bewegen uns weg vom reinen „Prompt Engineering“ hin zum „Environment Engineering“.

Wer seine KI-Strategie primär auf fiktiven Personas wie „Steve“ und „Linda“ aufbaut, riskiert Instabilität, da man sich darauf verlässt, dass das Modell den Anweisungen wohlwollend folgt. Wer hingegen Umgebungen baut – mit harter Syntax-Physik und klaren Markdown-Gesetzen – schafft ein solides Fundament.

Anstatt komplexe Drehbücher für imaginäre Akteure zu verfassen, ist es ratsam, die Bühne so zu konstruieren, dass Fehltritte technisch abgefangen werden.

Die Empfehlung: Reduzieren Sie Persona-Beschreibungen in Ihren System-Prompts auf das Nötigste. Ersetzen Sie diese durch eine constitution.md und geben Sie dem Agenten validierbare Werkzeuge an die Hand. Dies führt langfristig zu verlässlicheren Systemen.