Artikel
Hör auf, deine SOPs einfach in AI Agents zu kippen: Agent-Verhalten präzise steuern mit RFC 2119 (MUST/SHOULD/MAY)
Kippt man menschliche SOPs 1:1 in ein LLM, läuft der Agent einmal sauber durch und crasht dreimal. Dieser Artikel zeigt, wie man System Prompts und Agent Skills mit RFC 2119 (MUST, SHOULD, MAY) umschreibt – harte Constraints, starke Empfehlungen und Ermessensspielraum sauber trennt – inklusive dreier Best Practices für den Praxiseinsatz.
· 3 Min. Lesezeit
Der häufigste Fehler, den Teams beim Rollout von Agents machen: Sie kippen ein komplettes Word- oder Notion-Dokument mit menschlichen Standard Operating Procedures (SOPs) direkt ins LLM – in der Hoffnung, das Modell regelt das schon von allein. Das Ergebnis gleicht meist einem Lottospiel: Einmal klappt es, dreimal fliegt einem der Run um die Ohren.
Das Problem liegt nicht an mangelnder Modellleistung, sondern daran, dass menschliche SOPs vollgepackt sind mit implizitem Erfahrungswissen (Tacit Knowledge). Ein Mensch weiß intuitiv: „Beträge unter 500 Euro brauchen keine Freigabe“ oder „Wenn hier ein Fehler auftritt, kann ich den Schritt erst mal überspringen“. Für ein LLM hingegen hat unstrukturierter Fließtext keinerlei Verbindlichkeitsgrenzen – es fängt an zu improvisieren.
Wer deterministisches Agent-Verhalten will, braucht im ersten Schritt kein größeres Modell, sondern einen Klassiker aus den Spezifikationen von Netzwerkprotokollen: semantische Abstufungen nach RFC 2119.
Das Fazit vorweg: Nur Compliance, Security und das Kern-Schema als MUST deklarieren, weichere Leitplanken an SHOULD und MAY übergeben und High-Risk-Entscheidungen an einen menschlichen Reviewer koppeln.
Warum ausgerechnet RFC 2119?#
Beim Schreiben von System Prompts, Agent Skills oder Workflow Rules bieten schwammige Floskeln wie „Bitte beachten“, „Am besten wäre“ oder „Nach Möglichkeit“ dem Modell keinerlei feste Entscheidungsgrenzen. Klare, abgestufte Verben erzwingen stattdessen messerscharfe Leitplanken.
MUST / REQUIRED: Harte Constraints, null Kompromisse#
- Semantik: Darf unter keinen Umständen übersprungen werden; absolut ausnahmslos.
- Typische Use Cases: Datenvalidierung, Security-Checks, Schema-Vorgaben für den Output, Absicherung kritischer Pfade.
- Beispiel: „Vor dem Aufruf der Rechnungs-API
MUST geprüft werden, ob die Mitarbeiter-ID existiert; ist der Rückgabewert leer, MUST die Ausführung sofort abgebrochen werden.“
SHOULD / RECOMMENDED: Starke Empfehlung mit begründetem Spielraum#
- Semantik: Ist zwingend einzuhalten, es sei denn, der Kontext liefert triftige Gründe dagegen. Weicht der Agent ab, muss er sein Reasoning explizit darlegen.
- Typische Use Cases: Auswahl von Algorithmen-Strategien, Priorisierung bei der Klassifizierung, Retry-Logik.
- Beispiel: „Bei Support-Anfragen im Ticket
SHOULD die Zuweisung bevorzugt an den First-Level-Support erfolgen; betrifft der Fall jedoch Zahlungsstreitigkeiten, ist eine Weiterleitung an das Finanzprüfungs-Team zulässig.“
MAY / OPTIONAL: Reines Opt-in, volles Ermessen#
- Semantik: Das Modell entscheidet eigenständig je nach Kontextressourcen oder Token-Budget, ob der Schritt ausgeführt wird.
- Typische Use Cases: Ergänzende Erklärungen, weiterführende Vorschläge, optionale Logging-Formate.
- Beispiel: „Beim Erstellen der Zusammenfassung
MAY der Agent 1～2 IDs historischer Referenz-Tickets ähnlicher Fälle anhängen.“
Drei Prinzipien für die Praxis#
1. Nicht alles mit MUST zupflastern – Raum für Reasoning lassen#
Wer jede Regel als MUST formuliert, missbraucht das LLM als Deterministic Compiler. Das führt unweigerlich zu kollidierenden Regeln oder logischen Deadlocks, sobald der Context wächst. Nur Compliance, Security und Kern-Schemas gehören in MUST; weichere Leitplanken gehören in SHOULD.
2. Auf strukturierte Markdown-Blöcke setzen#
Den Prompt in vier saubere Sektionen unterteilen, damit der Scope der semantischen Verbindlichkeit sofort ersichtlich ist:
## Parameters
## Constraints (RFC 2119)
## Execution Steps
## Error Handling
3. High-Risk-Schritte an Human-in-the-loop binden#
Triggert eine Bedingung eine kritische MUST-Grenze (z. B. Einzeltransaktionen > $5,000 oder Änderungen von Admin-Berechtigungen), lautet das einzige MUST-Verhalten für den Agent: „Pipeline anhalten und auf das manuelle OK eines Menschen warten“ – anstatt die Entscheidung eigenmächtig zu treffen.
Fazit: Vom Demo-Spielzeug zu Production-Ready#
Ein Agent ist wie eine industrielle Fertigungsstraße zu behandeln, nicht wie eine eierlegende Wollmilchsau für alles. Erst wer über RFC 2119 klare Verhaltensverträge definiert, holt seinen Agent aus der Demo-Spielzeugecke und macht ihn fit für den produktiven Einsatz: Production-Ready.