Spezifikations-Leitfaden

Ein praktischer Begleiter zu den Ausführungsstandards. Die Standards definieren die Schichten und Primitive. Dieser Leitfaden zeigt, wie man sie anwendet.

Wann brauchen Sie eine Spezifikation?

Nicht jede KI-Interaktion erfordert eine formelle Spezifikation. Verwenden Sie diesen Entscheidungsbaum:

Einen Prompt verwenden, wenn:

Die Aufgabe ein einzelner Schritt mit offensichtlichen Erfolgskriterien ist
Sie den Output sofort bewerten werden
Scheitern nichts kostet (Sie können einfach einen neuen Prompt schreiben)

Einen Prompt + Kontextdatei verwenden, wenn:

Die Aufgabe Domänenwissen erfordert (Terminologie, Markensprache, technische Rahmenbedingungen)
Sie diese Art von Aufgabe schon gemacht haben und Qualität wichtig ist
Der Output von anderen verwendet wird

Eine vollständige Spezifikation verwenden, wenn:

Die Aufgabe mehrere Schritte oder Abhängigkeiten hat
Mehrere Personen oder Agenten an Teilen davon arbeiten
Scheitern teuer ist (Produktionscode, kundengerichteter Output, irreversible Aktionen)
Jemand anderes das Ergebnis verifizieren muss, ohne Sie zu fragen
Die Aufgabe wiederholt wird und konsistente Ergebnisse produzieren soll

Die Schwelle ist nicht Komplexität – es sind die Kosten des Scheiterns. Eine einfache Aufgabe mit hohen Einsätzen braucht eine Spezifikation. Eine komplexe Aufgabe mit null Einsätzen kann mit einem Prompt beginnen.

Das Schreiben einer Spezifikation kostet Zeit. Aber Forschung zeigt, dass es sich rentiert: Die Anreicherung einer Problemaussage vor dem Start eines Agenten bringt eine 20 %ige Verbesserung der Lösungsraten, und schwächere Agenten sehen die größten Gewinne. Es ist billiger, die Spezifikation zu verbessern als den Agenten.

Die vier Schichten in der Praxis

Die Standards definieren vier obligatorische Schichten. Diese Schichten bilden eine kumulative Reifegrad-Progression – jede Ebene baut auf der vorherigen auf. So sieht jede gut gemacht aus.

Schicht 1 – Prompt-Gestaltung

Die Grundlage. Sie schreiben eine klare Anweisung.

Erscheint vernünftig, hat aber Lücken:

Schreiben Sie eine 3-E-Mail-Onboarding-Sequenz für Testnutzer, die noch nicht aktiviert haben. Machen Sie sie freundlich und hilfreich. CTAs einschließen.

Besser – spezifisch genug, um zu verifizieren:

Schreiben Sie eine 3-E-Mail-Nurture-Sequenz für Testnutzer, die sich angemeldet, aber das Onboarding nicht innerhalb von 7 Tagen abgeschlossen haben. Ziel: Sie dazu zu bringen, ihr erstes Projekt abzuschließen. Ton: hilfreich, nicht drängend. Jede E-Mail sollte unter 100 Wörter lang sein mit einem klaren CTA. E-Mail 1 (Tag 3): den einfachsten Startpunkt hervorheben. E-Mail 2 (Tag 5): eine Template teilen, die sie anpassen können. E-Mail 3 (Tag 7): einen 15-minütigen Onboarding-Anruf anbieten. Betreffzeilen sollten gesprächig sein, nicht werbend.

Der erste Prompt fühlt sich vollständig an, lässt aber kritische Fragen offen: Was bedeutet „aktiviert"? Wie viele E-Mails? Wie lang? Worauf verweist der CTA? Der Agent wird all diese Lücken mit Annahmen füllen – und Annahmen sind der Ort, wo Qualität zusammenbricht.

Die ≤ 20 %-Korrektur-Regel: Wenn Sie konsistent mehr als 20 % des KI-Outputs korrigieren müssen, liegt das Problem in Ihrem Prompt, nicht im Modell. Investieren Sie in die Anweisung, nicht in das Bearbeiten des Ergebnisses.

Schicht 2 – Kontext-Engineering

Kontext ist alles, was der Agent wissen muss, das nicht im Prompt steht. Andrej Karpathy definiert Kontext-Engineering als „die zarte Kunst und Wissenschaft, das Kontextfenster mit genau den richtigen Informationen für den nächsten Schritt zu füllen."

Die Schlüsselfrage ist nicht „was könnte relevant sein?" – sondern „was muss der Agent jetzt sehen?" Mehr Kontext ist nicht besser. Forschung zeigt, dass Modelle auf Performance-Wände stoßen, wenn sie mit Informationen überhäuft werden, unabhängig von der Kontextfenstergröße.

Fünf Qualitätskriterien (Vishnyakova, 2026):

Relevant – nur was für den aktuellen Schritt notwendig ist. Irrelevante Daten verschlechtern den Output aktiv.
Ausreichend – alles Nötige, um eine Entscheidung ohne Raten zu treffen. Fehlender Kontext ist die primäre architektonische Ursache von Halluzinationen.
Isoliert – jeder Schritt oder Sub-Agent sieht nur seinen eigenen Kontext. Alles teilen verursacht kumulative Fehler (siehe Kontext-Fehlermodi).
Sparsam – minimale Tokens bei gleichbleibender Qualität. Anthropic formuliert das als „den kleinstmöglichen Satz hochsignifikanter Tokens finden."
Nachvollziehbar – jedes Kontextelement auf eine Quelle zurückführbar. Wenn etwas schiefgeht, müssen Sie wissen, welcher Input es verursacht hat.

Eine Team-Kontextdatei ist kein Gehirn-Dump. Es ist ein kuratierter Satz von Fakten, die der Agent für wiederkehrende Aufgaben benötigt. Halten Sie sie prägnant und auf Besonderheiten beschränkt – sie wird in jede Sitzung geladen, also muss jede Zeile universell anwendbar sein.

# Kundenerfolg-Team Kontext

## Ziele
- Bestehende Kunden halten (Retention > Akquisition)
- Zeit zur Lösung von Support-Tickets reduzieren
- Erweiterungsmöglichkeiten in bestehenden Accounts identifizieren

## Rahmenbedingungen
- Niemals Kundendaten über Accounts hinweg teilen
- Niemals Funktionen versprechen, die noch nicht ausgeliefert sind
- Abrechnungsstreitigkeiten über 500 € an einen Manager eskalieren
- Antwortzeit-SLA: erste Antwort innerhalb von 4 Stunden

## Terminologie
- „Partner" = Reseller-Account (kein normaler Kunde)
- „White-label" = kundengebrandete Version der Plattform
- „Link-Branding" = benutzerdefinierte Domain für Tracking-Links

## Qualitätsstandards
- Antworten müssen die spezifische Frage adressieren, nicht generische FAQs
- In jeder Antwort nächste Schritte einschließen
- Bei Unsicherheit sagen – nicht raten

Just-in-time vs. Upfront: Nicht alles upfront laden. Eine hybride Strategie verwenden – immer die Team-Kontextdatei und Terminologie laden; spezifische Daten (Kundendatensätze, Ticket-Geschichte, Dokumentation) auf Anfrage laden. Der Agent sollte wissen, wo er Informationen findet, sie nicht alle auswendig kennen.

Für eine tiefere Behandlung von Kontext-Engineering, siehe Anthropics Effective Context Engineering for AI Agents.

Schicht 3 – Absichts-Engineering

Absicht beantwortet: „Wofür soll der Agent optimieren, und welche Abwägungen darf er treffen?"

Ohne explizite Absicht optimieren Agenten die messbarste verfügbare Metrik – was selten das ist, was Sie tatsächlich wollen. Die Klarna-Fallstudie illustriert das: Ihr KI-Agent bearbeitete zwei Drittel der Kundenanfragen und sparte 60 Mio. $, aber der CEO räumte öffentlich ein, dass die Qualität gelitten hatte, weil der Agent Kosten pro Token statt den Wert von Kundenbeziehungen optimierte. Wie ein Forscher es formuliert: „Kontext ohne Absicht ist Lärm."

Absicht für einen Support-Workflow:

## Zielhierarchie (in Prioritätsreihenfolge)
1. Genauigkeit – niemals falsche Informationen geben
2. Lösung – das tatsächliche Problem des Kunden lösen,
   nicht nur seine Frage beantworten
3. Ton – Markenstimme treffen (freundlich, kompetent)
4. Effizienz – Antworten prägnant halten

## Abwägungsregeln
- Genauigkeit vs. Geschwindigkeit → Genauigkeit wählen
- Ton vs. Effizienz → warm halten, auch wenn länger
- Unsicher bei einer technischen Antwort → sagen,
  nicht raten

## Eskalationsbedingungen
- Kunde erwähnt rechtliche Schritte → sofort
- Abrechnungsstreit über 500 € → Manager
- Technisches Problem, das mehrere Kunden betrifft
  → Engineering
- Dieselbe Frage dreimal gestellt → Senior Support

## Entscheidungsbefugnis
Darf: Antworten entwerfen, Account-Details nachschlagen,
  Wissensdatenbank zitieren
Darf nicht: Rückerstattungen versprechen, Daten anderer
  Kunden teilen, zukünftige Funktionen zusagen

Absicht für einen Engineering-Workflow:

## Zielhierarchie (in Prioritätsreihenfolge)
1. Korrektheit – Code muss alle bestehenden Tests bestehen
2. Wartbarkeit – lesbar für einen Entwickler, der die
   Codebasis nicht kennt
3. Performance – SLA-Anforderungen erfüllen
4. Einfachheit – weniger Zeilen gegenüber Abstraktion bevorzugen

## Abwägungsregeln
- Korrektheit vs. Geschwindigkeit → Korrektheit wählen
- Wartbarkeit vs. Performance → Lesbarkeit bevorzugen,
  solange das SLA nicht gefährdet ist
- Wenn mehrere Ansätze gültig sind → den mit weniger
  Kopplung zu anderen Modulen wählen

## Eskalationsbedingungen
- Änderung erfordert Modifikation einer öffentlichen API
  → eskalieren
- Performance-Auswirkung übersteigt 10 % auf kritischen
  Pfaden → eskalieren
- Lösung erfordert eine Datenbankm igration → eskalieren

## Entscheidungsbefugnis
Darf: innerhalb des Aufgabenumfangs refaktorieren,
  Hilfsfunktionen hinzufügen, verwandte Tests aktualisieren
Darf nicht: öffentliche APIs ändern, nicht zusammenhängenden
  Code modifizieren, Testabdeckung überspringen

Schicht 4 – Spezifikations-Engineering

Eine Spezifikation ist ein vollständiger, eigenständiger Anweisungssatz für eine nicht-triviale Aufgabe. Sie enthält alles, was der Agent braucht, und nichts, was er nicht braucht.

Die sieben erforderlichen Komponenten (aus den Standards):

Problemaussage – was passieren muss und warum
Umfang – was eingeschlossen ist und explizit was nicht
Eingaben – worauf der Agent Zugriff hat
Rahmenbedingungen – die Muss / Darf nicht / Bevorzuge / Eskaliere-Kategorien
Abnahmekriterien – wie man verifiziert, dass der Output korrekt ist (wie „fertig" objektiv aussieht)
Fehlerbedingungen – was als fehlgeschlagener Versuch gilt
Erfolgstests – spezifische Szenarien, die der Output bewältigen muss

Die fünf Primitive mit Beispielen

Primitiv 1 – Eigenständige Problemaussagen

Der Test: Könnte jemand ohne Kontext zu Ihrem Projekt diese Aufgabe nur mit dem ausführen, was geschrieben steht?

Erscheint vollständig, ist es aber nicht:

Der Job-Scheduler ist für große Batches zu langsam. Beheben Sie das Prioritätssystem, damit kleinere Jobs nicht hinter großen feststecken. BullMQ verwenden.

Eigenständig:

Der Job-Scheduler (src/jobs/queue.ts) verarbeitet Aufgaben sequenziell. Große Jobs (50K+ Elemente) blockieren kleinere Jobs in der Queue – Nutzer mit kleinen Jobs warten 30+ Minuten auf den Verarbeitungsstart. Der Fix sollte prioritätsbasiertes Scheduling hinzufügen: Jobs unter 5K Elementen erhalten höhere Priorität. Die Rate-Limiter-Konfiguration (100 req/s) darf sich nicht ändern. Das vorhandene BullMQ-Prioritäts-Feature sollte wenn möglich verwendet werden. Wenn die Lösung eine Änderung des Job-Schemas erfordert, vor der Implementierung eskalieren.

Die erste Version klingt handlungsfähig, verbirgt aber Fragen: welche Datei? Was ist „zu langsam" in Zahlen? Was sind die Rahmenbedingungen? Der Agent wird Annahmen über all das treffen – und diese können falsch sein.

Forschung zu Coding-Agenten bestätigt das: Architekturkontext, Dateiübergreifende Abhängigkeiten und Explorations-Hinweise upfront bereitzustellen verhindert, dass Agenten Schritte mit ungerichteter Repository-Traversierung verschwenden.

Marketing-Version – erscheint vollständig, ist es aber nicht:

Erstellen Sie eine E-Mail-Drip-Kampagne für Testnutzer, die nicht konvertiert haben. Fokus auf Produktwert zeigen. 3 E-Mails, freundlicher Ton, mit CTAs.

Eigenständig:

Trial-to-paid-Konversion beträgt 12 %. Branchenmaßstab ist 18 %. Nutzer, die das Onboarding innerhalb von 72 Stunden abschließen, konvertieren zu 31 %. Eine 3-E-Mail-Sequenz designen, die ausgelöst wird, wenn ein Testnutzer bis Tag 3 sein erstes Projekt nicht abgeschlossen hat. Ziel: ihn zum Abschluss des Onboardings zu bringen. Jede E-Mail unter 100 Wörter, ein CTA pro E-Mail, funktioniert auf DE und EN. Keine Preiserwähnungen, keine Dringlichkeitstaktiken.

Die erste Version würde eine generische Drip-Kampagne produzieren. Die zweite gibt dem Agenten den Geschäftskontext (warum das wichtig ist) und die Rahmenbedingungen (was zu vermeiden ist), die ein gezieltes Ergebnis produzieren.

Primitiv 2 – Abnahmekriterien

Schreiben Sie drei Sätze, mit denen jemand anderes den Output verifizieren kann, ohne Sie zu fragen.

Fühlt sich testbar an, ist es aber nicht:

Das Dashboard sollte Schlüsselmetriken genau anzeigen und über alle Browser hinweg schnell laden.

Tatsächlich testbar:

Das Dashboard zeigt MRR, Churn-Rate und aktive Nutzer für den ausgewählten Datumsbereich an. MRR stimmt mit der Zahl des Finanzteams innerhalb von 100 € überein. Die Seite lädt in unter 2 Sekunden über eine Standardverbindung. Charts rendern ohne Fehler in Chrome und Firefox.

Die erste Version verwendet Wörter, die präzise klingen („genau", „schnell", „alle Browser"), die aber niemand ohne Rückfragen verifizieren kann. Die zweite Version definiert spezifische Zahlen, spezifische Metriken und spezifische Browser.

Primitiv 3 – Rahmenbedingungsarchitektur

Vier Kategorien. Für jede nicht-triviale Aufgabe alle vier ausfüllen.

Beispiel: Support-Ticket-Auto-Antwort-System

Kategorie	Regeln
Muss	Kunden mit Namen ansprechen. Auf sein spezifisches Problem eingehen. Einen nächsten Schritt einschließen.
Darf nicht	Niemals Anmeldedaten oder interne Systemdetails teilen. Niemals eine spezifische Lösungszeit versprechen. Niemals ein Ticket automatisch schließen.
Bevorzuge	Relevante Wissensdatenbank-Artikel verlinken, wenn sie existieren. Die Sprache des Kunden basierend auf seinen Account-Einstellungen verwenden. Antworten unter 200 Wörter halten.
Eskaliere	Kunde erwähnt Kündigung. Problem beinhaltet Datenverlust. Dasselbe Problem 3+ mal in 24 Stunden gemeldet. Kunde hat einen Enterprise-Plan.

Primitiv 4 – Zerlegung

Aufgaben in unabhängige Teile mit klaren Eingaben und Ausgaben aufteilen. Ziel: Teilaufgaben, die ≤ 2 Stunden dauern und für sich selbst verifiziert werden können.

Sieht zerlegt aus, ist aber noch gekoppelt:

Datenmodell designen und API bauen
Frontend bauen, das die API nutzt
Tests schreiben und deployen

Tatsächlich unabhängig:

Schritt	Eingabe	Ausgabe	Verifikation
1. Schema-Migration	Aktuelles Schema + Anforderungsdokument	Migrations-Datei + Rollback-Datei	Migration läuft vorwärts und rückwärts ohne Fehler
2. API-Endpunkt	Migration + API-Spec	Route Handler mit Validierung	Alle 5 Testfälle bestehen, gibt korrekte Status-Codes zurück
3. Frontend-Formular	API-Spec + Design-Mockup	React-Komponente mit Formularvalidierung	Formular sendet erfolgreich, Validierungsfehler werden korrekt angezeigt
4. Integrationstest	Alle drei oben	End-to-End-Test	Nutzer kann den vollständigen Workflow im Staging abschließen

Die erste Version hat versteckte Abhängigkeiten (Schritt 1 bündelt zwei Anliegen, Schritt 2 kann erst beginnen, wenn Schritt 1 vollständig fertig ist, Schritt 3 bündelt Testing mit Deployment). Die zweite Version hat klare Eingaben, Ausgaben und Verifikation bei jedem Schritt. Anthropic empfiehlt dieses Orchestrator-Worker-Muster für Mehrkomponenten-Aufgaben.

Primitiv 5 – Bewertungsdesign

3–5 Testfälle mit bekannt guten Outputs aufbauen. Nach jeder Änderung ausführen.

Beispiel: E-Mail-Betreffzeilen-Generator

Testfall	Eingabe	Erwartete Output-Eigenschaften
1. Willkommens-E-Mail	Neuer Nutzer, heute angemeldet, Name: Marie	Enthält den Namen des Nutzers. Unter 50 Zeichen. Keine Spam-Trigger-Wörter.
2. Re-Engagement	Nutzer 30 Tage inaktiv	Verweist auf einen spezifischen Zeitraum oder ihre letzte Aktivität. Erzeugt Neugier. Nicht schuldbehaftet.
3. Feature-Ankündigung	Neues Editor-Feature, alle Nutzer	Hebt den Vorteil hervor, nicht den Feature-Namen. Kein technischer Jargon.
4. Deutsches Locale	Wie #1, aber Nutzer-Locale ist DE	Grammatisch korrektes Deutsch. Keine wörtliche Übersetzung.
5. Randfall: kein Name	Nutzer hat keinen Vornamen in der Datenbank	Sagt nicht „Hallo null" oder „Hallo ". Verwendet eine generische Begrüßung.

Sie testen nicht den genauen Output (KI ist nicht-deterministisch). Sie testen die Output-Eigenschaften. Das ist Evaluation, kein Unit-Testing. Anthropic empfiehlt, jeden Eval-Prompt mit überprüfbaren Ergebnissen zu pairen und Genauigkeit, Laufzeit und Fehlerraten über Zeit zu verfolgen.

Kontext-Fehlermodi

Wenn KI-Output schiefgeht, diagnostizieren Sie, welcher Kontext-Fehlermodus es verursacht hat, bevor Sie es erneut versuchen. Diese vier Fehlermodi sind in der Kontext-Engineering-Literatur gut dokumentiert:

Vergiftung

Ein Fehler tritt in den Kontext ein und kumuliert sich über Turns. Der Agent halluzinierte einen Funktionsnamen in Schritt 2, ruft dann diese nicht existierende Funktion in den Schritten 3–5 weiter auf.

Fix: Kontext zwischen Schritten löschen. Tool-Outputs aus frühen Schritten nicht tief in das Gespräch übertragen lassen. An Grenzen zusammenfassen statt rohe Geschichte zu tragen.

Ablenkung

Der Kontext ist so lang, dass der Agent Muster aus der Geschichte wiederholt, statt über den aktuellen Schritt nachzudenken. Forschung hat diese Degradierung nach Überschreitung von 100K Tokens beobachtet.

Fix: Älteren Kontext komprimieren oder zusammenfassen. Wenn das Gespräch lang wird, eine neue Sitzung mit einer Zusammenfassung der bisher getroffenen Entscheidungen erstellen.

Verwirrung

Zu viele Tools oder zu viel Dokumentation im Kontext. Der Agent wählt das falsche Tool oder zitiert irrelevante Dokumentation, weil er nicht unterscheiden kann, was relevant ist.

Fix: Was geladen wird, reduzieren. Nur Tools und Dokumente exponieren, die für die aktuelle Aufgabe relevant sind. Wie Anthropic es formuliert: „Wenn ein Mensch das korrekte Tool nicht definitiv wählen kann, kann ein Agent es nicht besser."

Konflikt

Widersprüchliche Informationen im Kontext. Der Stilguide sagt „prägnant sein", aber das Template sagt „eine detaillierte Erklärung einschließen". Eine Microsoft/Salesforce-Studie zeigte einen 39 %igen Qualitätsabfall, wenn widersprüchliche Informationen vorhanden waren.

Fix: Ihren Kontext auf Widersprüche prüfen. Beim Aktualisieren von Kontextdateien die alte Anleitung entfernen – sie nicht nur neben neuer Anleitung hinzufügen. Eine Wahrheitsquelle pro Thema.

Spezifikationen für verschiedene Rollen schreiben

Engineering-Spezifikation

## Problem
Der Job-Scheduler verarbeitet Aufgaben sequenziell. Große Jobs
(50K+ Elemente) blockieren kleinere Jobs in der Queue. Nutzer
mit kleinen Jobs warten 30+ Minuten auf den Verarbeitungsstart.

## Umfang
- Die Job-Queue modifizieren, um prioritätsbasiertes Scheduling zu unterstützen
- Kleine Jobs (< 5K Elemente) erhalten höhere Priorität
- Rate-Limits oder die Rendering-Pipeline NICHT ändern

## Eingaben
- Job-Queue-Implementierung: src/jobs/queue.ts
- Job-Modell: src/models/job.ts
- Aktuelle Tests: src/jobs/__tests__/queue.test.ts

## Rahmenbedingungen
- Muss: FIFO-Reihenfolge innerhalb desselben Prioritäts-Tiers erhalten
- Muss: alle Jobs innerhalb der bestehenden Rate-Limits verarbeiten
- Darf nicht: Jobs, die bereits in Bearbeitung sind, fallen lassen oder neu ordnen
- Darf nicht: eine Datenbankmigration erfordern
- Bevorzuge: das vorhandene BullMQ-Prioritäts-Feature verwenden
- Eskaliere: wenn die Lösung eine Änderung des Job-Schemas erfordert

## Abnahmekriterien
1. Ein 1K-Element-Job, der nach einem 100K-Job eingereiht wird, startet
   die Verarbeitung innerhalb von 5 Minuten, nicht 30+
2. Kein Job wird ausgehungert – alle Jobs schließen innerhalb des 2-fachen
   ihrer erwarteten Dauer ab
3. Bestehende Tests bestehen ohne Modifikation
4. Neue Tests decken Prioritätsreihenfolge und Verhungerns-Prävention ab

## Fehlerbedingungen
- Jeder Job mit falschen Eingaben verarbeitet
- Jeder Job zweimal verarbeitet
- Queue-Deadlock bei gleichzeitigen Einreichungen

## Erfolgstests
1. 3 Jobs einreihen: 100K, 1K, 500. Verifizieren, dass 1K und 500
   beginnen, bevor 100K abgeschlossen ist.
2. 20 kleine Jobs und 1 großen einreihen. Verifizieren, dass alle abschließen.
3. Jobs gleichzeitig von 3 API-Clients einreichen.
   Verifizieren, keine Duplikate oder verlorenen Jobs.

Marketing-Spezifikation

## Problem
Trial-to-paid-Konversion beträgt 12 %. Branchenmaßstab ist 18 %.
Nutzer, die das Onboarding innerhalb von 72 Stunden abschließen,
konvertieren zu 31 %. Die meisten Testnutzer schließen das Onboarding
nie ab.

## Umfang
Eine 3-E-Mail-Onboarding-Sequenz designen, die ausgelöst wird, wenn
ein Testnutzer bis Tag 3 sein erstes Projekt nicht abgeschlossen hat.
Ziel: ihn zum Onboarding zu bringen. Das ist nur der E-Mail-Inhalt
– der Automatisierungs-Trigger existiert bereits.

## Eingaben
- Aktuelle Willkommens-E-Mail (beigefügt)
- Top 3 Templates nach Nutzung (beigefügt)
- Markensprache-Guide: freundlich, kompetent, nie korporativ
- Produkt: visueller Editor, Template-Bibliothek, Projektmanagement

## Rahmenbedingungen
- Muss: jede E-Mail unter 100 Wörter
- Muss: ein klarer CTA pro E-Mail
- Muss: auf DE und EN funktionieren
- Darf nicht: Preise oder Plan-Limitierungen erwähnen
- Darf nicht: Dringlichkeitstaktiken verwenden ("Ihr Test läuft ab!")
- Bevorzuge: zeigen, nicht erzählen (auf ein Template verlinken, nicht
  eine Feature-Liste)
- Eskaliere: wenn die Sequenz mehr als 3 E-Mails benötigt

## Abnahmekriterien
1. Jede E-Mail hat genau einen CTA, der auf eine spezifische
   Aktion im Produkt verweist
2. Ton entspricht dem Markensprache-Guide
3. Keine E-Mail überschreitet 100 Wörter
4. Betreffzeilen sind unter 50 Zeichen
5. Ein Nicht-Kunde kann das Wertversprechen ohne vorheriges
   Produktwissen verstehen

## Fehlerbedingungen
- Jede E-Mail überschreitet 100 Wörter
- CTA verweist auf eine generische Seite statt auf eine spezifische Aktion
- Dringlichkeitssprache erscheint ("begrenzte Zeit", "läuft ab",
  "letzte Chance")
- Deutsche Version ist eine wörtliche Übersetzung statt natürliche Prosa

## Erfolgstests
1. E-Mail 1 kalt lesen. Können Sie identifizieren, was das Produkt
   tut und welche Aktion zu ergreifen ist? (ja/nein)
2. Alle 3 in Sequenz lesen. Fühlt sich die Progression natürlich an,
   nicht repetitiv? (ja/nein)
3. Deutsche Versionen lesen natürlich, nicht wie Übersetzungen.
   (von Muttersprachler verifiziert)

Support-Spezifikation

## Problem
Support-Antwortzeit beträgt durchschnittlich 6 Stunden. 40 % der Tickets
sind Fragen, die bereits in der Wissensdatenbank beantwortet sind. Agenten
verbringen Zeit damit, nach Antworten zu suchen, die bereits existieren.

## Umfang
Ein KI-unterstütztes Entwurfs-Antwortsystem aufbauen. Wenn ein Ticket
eingeht, durchsucht das System die Wissensdatenbank und entwirft eine
Antwort zur Überprüfung und zum Senden durch den Support-Agenten.
Der Agent überprüft immer, bevor er sendet – keine automatischen Antworten.

## Eingaben
- Wissensdatenbank-Artikel (~200 Artikel)
- Ticket-Geschichte (letzte 90 Tage, anonymisiert)
- Kundenkontodaten (Plantyp, Laufzeit, neuere Aktivität)
- Vorlagen-Antworten (32 Templates)

## Rahmenbedingungen
- Muss: Mensch überprüft jede Antwort vor dem Senden
- Muss: den verwendeten Wissensdatenbank-Artikel zitieren
- Muss: kennzeichnen, wenn kein relevanter Artikel existiert
  (Signal für die Erstellung eines neuen)
- Darf nicht: auf Kundendaten aus anderen Accounts zugreifen
- Darf nicht: Lösungszeiten versprechen
- Darf nicht: Tickets automatisch schließen
- Bevorzuge: die Sprache des Kunden abgleichen
- Bevorzuge: Entwürfe unter 200 Wörter halten
- Eskaliere: Abrechnungsstreitigkeiten über 500 €, Erwähnung von
  Kündigung, Datenverlust-Probleme

## Abnahmekriterien
1. Entwürfe werden innerhalb von 30 Sekunden nach Ticket-Erstellung
   generiert
2. 70 %+ der Entwürfe erfordern weniger als 20 % Bearbeitung
3. Zitierte Wissensdatenbank-Artikel sind für die Frage relevant
4. Agenten können jeden Entwurf mit einem Klick überschreiben oder verwerfen

## Fehlerbedingungen
- Antwort ohne menschliche Überprüfung gesendet
- Kundendaten von Account A erscheinen in der Antwort für Account B
- Entwurf zitiert einen veralteten oder falschen KB-Artikel
- System generiert einen Entwurf für ein Ticket, das eskaliert werden sollte

## Erfolgstests
1. "Wie richte ich benutzerdefinierte Domains ein?" → Entwurf verweist
   auf den Domain-Setup-KB-Artikel mit korrekten Anweisungen
2. "Ich wurde zweimal belastet" → Entwurf kennzeichnet zur Eskalation,
   versucht nicht, die Abrechnung zu lösen
3. Frage auf Deutsch → Entwurf ist auf Deutsch,
   verweist auf relevante Fehlerbehebungsschritte
4. Kauderwelsch-Eingabe → System kennzeichnet als unklar, generiert
   keinen Entwurf

Die Spezifikationsverbesserungs-Schleife

Eine Spezifikation ist beim ersten Versuch nie fertig. Verwenden Sie das Fehlerverantwortungsmodell:

Spezifikation schreiben mit den fünf Primitiven
Ausführen – den Agenten ausführen lassen
Output evaluieren gegen Ihre Abnahmekriterien
Fehler nach Schicht diagnostizieren:

Was schiefging	Welche Schicht zu beheben
Output ist falsch oder niedrige Qualität	Schicht 1 – Prompt verbessern
Output ignoriert Domänenwissen	Schicht 2 – Kontext verbessern
Output optimiert das Falsche	Schicht 3 – Absicht klären
Output ist unvollständig oder verfehlt Anforderungen	Schicht 4 – Spezifikation straffen

Eine Schicht auf einmal beheben. Nie mehrere Schichten gleichzeitig ändern – Sie werden nicht wissen, was funktioniert hat.
Spezifikation aktualisieren mit dem, was Sie gelernt haben. Die besten Spezifikationen werden von Menschen geschrieben, die Agenten beim Scheitern beobachtet haben.

Dieser iterative Ansatz entspricht Anthropics Empfehlung, mit dem „besten Modell minimal beginnen, dann iterativ Anweisungen basierend auf beobachteten Fehlermodi hinzufügen."

Häufige Fehler

Über-Spezifizieren. Eine Spezifikation, die jedes Implementierungsdetail beschreibt, ist Pseudocode. Das Was und die Rahmenbedingungen spezifizieren, nicht das Wie. Den Agenten den Ansatz innerhalb Ihrer Grenzen wählen lassen.

Unter-Spezifizieren. „Machen Sie es besser" ist keine Spezifikation. Wenn Sie fertig nicht beschreiben können, sind Sie nicht bereit zu delegieren.

Kontext-Dumping. Jedes Dokument, das Sie haben, in den Kontext laden „für den Fall der Fälle". Irrelevante Informationen verschlechtern den Output aktiv. Anthropics Kernprinzip: den kleinsten Satz hochsignifikanter Tokens finden, nicht die meisten Tokens.

Prompts optimieren, wenn das Problem Kontext ist. Wenn der Agent immer wieder irrelevanten Output produziert, hilft es nicht, „relevanter sein" zum Prompt hinzuzufügen. Der Agent braucht andere Informationen, keine besseren Anweisungen. Das Fehlerverantwortungsmodell verwenden, um die richtige Schicht zu diagnostizieren.

Bewertungsdesign überspringen. Ohne Testfälle verlassen Sie sich auf Intuition, um Outputqualität zu beurteilen. Zuerst die Testfälle erstellen – sie zwingen Sie dazu zu klären, was Sie eigentlich wollen.

Wiederholen statt diagnostizieren. Wenn Output scheitert, ist der Instinkt, neu zu generieren. Stopp. Herausfinden, welche Schicht den Fehler verursacht hat. Diese Schicht beheben. Dann wiederholen.

Schnellreferenz

Vor der Delegation bestätigen:

Ich kann das Problem beschreiben, ohne auf Dinge zu verweisen, die der Agent nicht kennt
Ich kann drei Sätze schreiben, die Erfolg verifizieren
Ich habe aufgelistet, was passieren muss, was nicht passieren darf, und wann zu stoppen und zu fragen
Ich habe die Aufgabe in Teile aufgeteilt, die klein genug sind, um unabhängig zu verifizieren
Ich habe Testfälle mit bekannt guten Eigenschaften

Wenn Output scheitert, diagnostizieren:

Symptom	Wahrscheinliche Ursache	Aktion
Output ist falsch	Prompt	Anweisungen verbessern, Beispiele hinzufügen
Output ignoriert Ihre Domäne	Kontext	Kontextdatei hinzufügen oder aktualisieren
Output optimiert das Falsche	Absicht	Zielhierarchie und Abwägungen definieren
Output ist unvollständig	Spezifikation	Fehlende Anforderungen hinzufügen, Umfang straffen

Weiterführende Lektüre

Building Effective Agents – Anthropics Leitfaden zu Agenten-Architekturmustern
Effective Context Engineering for AI Agents – Verwaltung des vollständigen Token-Status über Agentenschleifen
Writing Tools for Agents – Tool-Design-Prinzipien und Evaluationsmethodik
Context Engineering for Agents – LangChains vier Operationen-Framework (Schreiben, Auswählen, Komprimieren, Isolieren)
A Survey of Context Engineering for LLMs – Akademische Umfrage mit formaler Taxonomie
CodeScout: Contextual Problem Statement Enhancement – Forschung, die 20 % Verbesserung durch bessere Upfront-Spezifikationen zeigt

← Zurück zur Startseite · Ausführungsstandards · Das Referenzrahmenwerk · Glossar