KI-Agenten und ihre Identität — warum die Persona wichtiger ist als der Prompt und was sie an Tokens kostet

Einführung

Im Jahr 2026 ist "schreibe einen guten Prompt" keine Architektur mehr. Die Teams, mit denen ich arbeite, bauen keinen einzigen riesigen Prompt mehr, der alles erledigt. Sie bauen Agenten: spezialisierte Einheiten mit eigenem Verantwortungsbereich, eigenem Werkzeugsatz und eigener Identität.

Klingt nach Kosmetik? Ist es nicht. Die Identität eines Agenten ist gleichzeitig der günstigste Weg zu besserer Antwortqualität und der teuerste Posten auf der Token-Rechnung — wenn man sie baut, ohne zu verstehen, was bei jeder einzelnen Anfrage passiert.

Dieser Artikel behandelt drei Dinge: woraus eine Agenten-Identität tatsächlich besteht, warum sie das Modellverhalten verändert und wie genau sie sich in Tokens und Geld übersetzt.

Was "Identität" bei einem Agenten bedeutet

Identität ist kein Name und keine freundliche Begrüßung. In der Praxis sind es fünf Schichten, und jede davon ist tragend:

Das Interessante daran: diese Schichten sind keine Dokumentation für Menschen. Sie sind der Suchraum, in dem das Modell operiert. Eine enge, explizite Identität eliminiert ganze Klassen falscher Entscheidungen, bevor das Modell sie trifft.

using Anthropic;
using Anthropic.Models.Messages;

// Die Identität ist ein stabiles Artefakt — behandeln Sie sie wie Code, nicht wie
// ein String-Literal, das über die Codebasis verstreut ist. Versionieren, reviewen, testen.
const string ReleaseAuditorIdentity = """
    Du bist ein Release-Auditor für eine .NET MAUI Mobile-Anwendung.

    SCOPE: Du prüfst das Diff eines Release Candidate und berichtest Risiken.
    Du schreibst keine Features, refaktorierst nicht und änderst keine
    CI-Konfiguration.

    METHODE: Klassifiziere für jede geänderte Datei das Risiko als
    niedrig / mittel / hoch und begründe es mit einem konkreten
    Fehlerszenario, nicht mit einem allgemeinen Bedenken.

    OUTPUT: eine nach Schweregrad sortierte Befundtabelle, danach eine
    einzige Go-/No-Go-Empfehlung. Keine Einleitung, keine Zusammenfassung
    der eigenen Arbeitsschritte.

    DONE: jede geänderte Datei des Diffs erscheint genau einmal in der Tabelle.
    """;

AnthropicClient client = new();

var response = await client.Messages.Create(new MessageCreateParams
{
    Model = "claude-opus-5",
    MaxTokens = 16000,
    Thinking = new ThinkingConfigAdaptive(),
    OutputConfig = new OutputConfig { Effort = Effort.High },
    System = new List<TextBlockParam>
    {
        new() { Text = ReleaseAuditorIdentity },
    },
    Messages = [new() { Role = Role.User, Content = releaseDiff }],
});

Warum Identität wichtiger ist als die Formulierung des Prompts

Sie verengt den Entscheidungsraum

Ein Agent ohne deklarierten Scope behandelt jede Anfrage als Einladung, allgemein hilfsbereit zu sein. Genau so bekommt man einen Code-Reviewer, der anfängt zu refaktorieren, oder einen Datenextraktor, der freundliche Kommentare hinzufügt, um die man dann herumparsen muss. "SCOPE / nicht im Scope" leistet mehr als drei Absätze höflicher Anweisungen.

Sie überlebt lange Schleifen

Ein Einzelaufruf merkt eine schwache Identität kaum. Ein Agent mit zwanzig Tool-Aufrufen schon. Jede Iteration ist eine Gelegenheit zum Abdriften — das Framing des letzten Tool-Ergebnisses zu übernehmen statt das der eigentlichen Aufgabe. Eine starke Identität wird bei jeder einzelnen Anfrage neu behauptet, weil der System-Prompt bei jeder einzelnen Anfrage neu gesendet wird. Genau diese Eigenschaft macht Drift beherrschbar — und genau sie hat ihren Preis.

Sie macht den Agenten testbar

Eine Identität mit expliziter Definition of Done ist ein Vertrag, gegen den man Assertions schreiben kann. "Jede geänderte Datei erscheint genau einmal" ist prüfbar. "Sei gründlich" nicht.

In ihr lebt die Sicherheitsgrenze

Claude kennt Ihre Freigabe-Policy nicht. Ihr Harness kennt sie. Identität plus eine absichtlich enge Werkzeugoberfläche ist die Art, diese Grenze auszudrücken: schwer umkehrbare Aktionen bekommen dedizierte, kontrollierbare Tools statt einer generischen Shell.

Der Preis der Identität: Tokens

Das ist die Mechanik, die Umsteiger von Einzelaufrufen auf Agenten überrascht:

Der System-Prompt und die Tool-Definitionen werden bei jeder Anfrage der Schleife erneut gesendet.

Ein Agentenlauf ist kein API-Aufruf. Er sind N Aufrufe — N ist die Anzahl der Tool-Roundtrips — und jeder trägt die vollständige Identität, den vollständigen Tool-Schema-Satz und die gesamte bisherige Konversation.

Ein realistisches Setup:

Ein Agent mit 20 Tool-Aufrufen bezahlt diesen Prefix also 20-mal: 46.000 Input-Tokens, bevor eine einzige Zeile echten Aufgabeninhalts dazukommt. Bei Claude Opus 5 Input-Preisen (5 $ / 1 Mio. Tokens) sind das etwa 0,23 $ pro Lauf, nur um den Agenten sich selbst wieder vorzustellen — bei 10.000 Läufen im Monat 2.300 $.

Das ist die Zahl, die Leute dazu bringt, ihre System-Prompts zu kürzen. Tun Sie das nicht. Cachen Sie sie.

Prompt Caching: wie Identität fast kostenlos wird

Prompt Caching verwandelt diesen festen Prefix von einem Kostenpunkt pro Anfrage in einen nahezu vernachlässigbaren. Eine Invariante bestimmt alles:

Caching ist ein Prefix-Match. Jede Byte-Änderung irgendwo im Prefix invalidiert alles danach.

Die Render-Reihenfolge ist tools → system → messages. Ein Cache-Breakpoint auf dem letzten System-Block deckt daher die Tools und die Identität gemeinsam ab — exakt die 2.300 Tokens von oben.

var response = await client.Messages.Create(new MessageCreateParams
{
    Model = "claude-opus-5",
    MaxTokens = 16000,
    System = new List<TextBlockParam>
    {
        new()
        {
            Text = ReleaseAuditorIdentity,          // bei jeder Anfrage byte-identisch
            CacheControl = new CacheControlEphemeral(),  // standardmäßig 5-Minuten-TTL
        },
    },
    Messages = messages,
});

// Immer verifizieren — Caching scheitert stillschweigend, nie laut
Console.WriteLine($"geschrieben: {response.Usage.CacheCreationInputTokens}");
Console.WriteLine($"gelesen:     {response.Usage.CacheReadInputTokens}");
Console.WriteLine($"Vollpreis:   {response.Usage.InputTokens}");

Die Ökonomie: ein Cache-Read kostet etwa 0,1× des Basis-Input-Preises, ein Cache-Write 1,25× bei der Standard-TTL von 5 Minuten (oder 2× bei einer TTL von 1 Stunde). Angewandt auf denselben Lauf mit 20 Iterationen:

84 % weniger auf dem Identitätsanteil der Rechnung, ohne den Prompt selbst zu ändern. Der Break-even kommt trivial schnell: bei 5-Minuten-TTL zahlen bereits zwei Anfragen den Write-Aufschlag zurück.

Ein Detail lohnt sich zu wissen: der minimal cachebare Prefix ist modellabhängig und über die Generationen nicht monoton — 512 Tokens bei Claude Opus 5, 1.024 bei Sonnet 5, 4.096 bei Haiku 4.5. Eine Identität mit 3.000 Tokens cached auf Opus 5 und stillschweigend nicht auf Haiku 4.5. Kein Fehler, nur cache_creation_input_tokens: 0.

Die stillen Cache-Killer

Hier verschwindet echtes Geld. Jedes dieser Muster sieht im Review harmlos aus:

Die Lösung ist architektonisch, nicht eine Frage der Marker-Platzierung: Identität einfrieren und alles Volatile ans Ende des Prompts schieben.

Wenn eine Operator-Anweisung wirklich mitten in der Konversation eintreffen muss — ein Moduswechsel, ein neu injizierter Zustand — editieren Sie nicht den Top-Level-System-Prompt. Auf Claude Opus 5, Opus 4.8 und Fable 5 können Sie stattdessen eine { "role": "system" }-Nachricht an das messages-Array anhängen. Sie sitzt nach der gecachten Historie, der Prefix bleibt also intakt — und anders als in einen User-Turn geschmuggelter Text ist sie ein nicht fälschbarer Operator-Kanal.

Ein monolithischer Agent oder ein Team von Spezialisten?

Sobald man akzeptiert, dass Identität gecached wird, ändert sich die Rechnung. Ein enger Agent ist nicht mehr teurer als ein breiter — und er ist messbar besser:

Die Zeile zur Kontext-Verschmutzung ist in der Praxis die wichtigste. Eine Teilaufgabe, die zwanzig Dateien liest, muss nicht zwanzig Dateiinhalte für immer im Fenster des Hauptagenten hinterlassen. Delegieren Sie sie, und die Hauptschleife erhält das Ergebnis statt des Rohmaterials.

Die Modellwahl verstärkt den Effekt:

Leseintensive Teilaufgaben mit geringem Urteilsanteil kosten auf Haiku 4.5 ein Fünftel von Opus 5 pro Input-Token. Aber Achtung wegen des vorherigen Abschnitts: wechseln Sie das Modell nicht innerhalb einer Konversation, um diese Ersparnis zu holen — Caches sind modellgebunden, und Sie zahlen mehr, als Sie sparen. Starten Sie stattdessen einen Subagenten mit dem günstigeren Modell und halten Sie die Hauptschleife bei einem Modell.

Zwei weitere Hebel, beide auf den aktuellen Modellen:

• Effort (output_config.effort, von low bis max) steuert Denktiefe und Gesamt-Wortmenge. Weniger Effort bedeutet weniger, dafür stärker konsolidierte Tool-Aufrufe und weniger Vorrede — oft der beste einzelne Kostenhebel für Subagenten und Routinearbeit.

• Context Editing und Compaction verhindern, dass lange Läufe aufblähen: Editing entfernt veraltete Tool-Ergebnisse, Compaction fasst frühere Historie serverseitig zusammen, wenn Sie sich dem Kontextfenster nähern.

Ein praktisches Token-Budget

Für den obigen Release-Auditor mit 20 Tool-Aufrufen auf einem mittelgroßen Diff:

Die Lehre aus dieser Tabelle ist die, mit der niemand rechnet: nach dem Caching ist die Identität das Günstigste im ganzen Lauf. Teuer sind ungefilterte Tool-Ergebnisse und Output-Tokens. Der Instinkt, den System-Prompt zum Sparen zu kürzen, ist also genau verkehrt — eine längere, schärfere Identität, die den Agenten davon abhält, drei unnötige Dateien zu lesen, zahlt sich vielfach aus.

Zusammenfassung

Sechs Regeln, die ich inzwischen bei jedem Agenten anwende:

1. Schreiben Sie die Identität als Artefakt, nicht als String-Literal. Scope, Werkzeuggrenze, Output-Format, Definition of Done. Versionieren, reviewen, testen.

2. Gehen Sie davon aus, dass sie bei jeder Anfrage neu gesendet wird — denn so ist es. Das macht sie wirksam und das macht sie teuer.

3. Cachen Sie den Prefix und verifizieren Sie den Cache. Ist cache_read_input_tokens über wiederholte Anfragen null, invalidiert etwas den Cache. Finden Sie es.

4. Prefix einfrieren, Volatiles ans Ende. Keine Zeitstempel, keine Benutzer-IDs, keine bedingten Abschnitte, keine Tool-Sätze pro Anfrage.

5. Mehrere enge Agenten schlagen einen breiten. Besseres Cache-Verhalten, isolierter Kontext, isolierte Fehler, günstigere Modellwahl pro Teilaufgabe.

6. Optimieren Sie Tool-Ergebnisse, bevor Sie den Prompt optimieren. Dort liegen die Tokens wirklich.

Einem Agenten eine Identität zu geben ist kein Rollenspiel und keine Dekoration. Es ist der Schnittstellenvertrag zwischen Ihrem System und einer nicht-deterministischen Komponente — und sobald sie gecached ist, ist sie auch die günstigste Zuverlässigkeit, die Sie kaufen können.

Hinweis: alle Token-Zahlen und Kosten oben sind Größenordnungs-Schätzungen aus meinen eigenen Läufen. Messen Sie Ihre eigenen mit einem Token-Counting-Endpoint, bevor Sie damit budgetieren.