Kontext, nicht Kontrolle
Jede Regel im Prompt Ihres Agenten begann als ein Bug.
Jemand sah schlechtes Verhalten, schrieb eine Regel, machte weiter. Jemand anderes tat dasselbe. Eine dritte Person fügte ein 'Mach niemals X' hinzu, weil das Modell an einem Dienstag einmal etwas Seltsames tat. Niemand löschte etwas.
Sechs Monate später verbringt der Agent mehr seines Context-Windows damit, durch sein Regelwerk zu navigieren, als über die eigentliche Aufgabe nachzudenken.
Das ist Kontroll-Denken. Und ich denke, es ist einer der größten Design-Fehler, den Teams beim Aufbau von KI-Agenten machen.
Ein kleines Beispiel, das ein größeres Muster offenbart
Wir stießen auf ein Problem, bei dem ein durch eine geplante Aufgabe ausgelöster Agent immer wieder neue geplante Aufgaben innerhalb des Runs erstellte. Unendliche Rekursion, aber mit realen Nebenwirkungen.
Zwei Arten zu reagieren.
Kontroll-Stil: Verbiet es. Schreibe Code, der verhindert, dass Zeitpläne Zeitpläne erstellen. Füge eine Prompt-Regel hinzu: 'Erstelle niemals einen Zeitplan innerhalb eines Zeitplans.' Veröffentliche es.
Kontext-Stil: Teile dem Agenten mit, was tatsächlich passiert.
Du wurdest von einer geplanten Aufgabe um 3:00 Uhr Pacific Time ausgelöst. Zeitplan-ID: sched_29x8f. Ein geplanter Run ist eine isolierte Ausführung mit einem definierten Umfang, den der Benutzer ursprünglich autorisiert hat. Das Erstellen einer neuen geplanten Aufgabe würde diesen Umfang über die ursprüngliche Autorisierung hinaus erweitern.
Der erste Ansatz behebt ein Verhalten. Der zweite gibt dem Agenten ein Modell der Situation.
Jetzt kann er auch über benachbarte Fragen nachdenken: Sollte ich um 3 Uhr morgens eine Benachrichtigung senden? Sollte ich einen Follow-up-Prozess erstellen, den der Benutzer nicht explizit angefordert hat? Sollte ich etwas modifizieren, das über den Umfang des ursprünglichen Runs hinausgeht?
Keine Regel nötig. Der Agent hat es selbst herausgefunden.
Viele Teams greifen zur Kontrolle, wenn sie eigentlich Kontext brauchen.
Die gleiche Unterscheidung zeigt sich auch in Prompts
Das betrifft nicht nur die Systemebene. Die Kontext-vs.-Kontroll-Trennung gibt es auch in Prompts.
Kontext-Stil-Prompting: größtenteils Fakten, minimale Meinung:
Du läufst aufgrund einer geplanten Aufgabe. Ausgelöst um 3:00 Uhr Pekinger Zeit. Aufgaben-ID: sched_29x8f. Der Benutzer hat diesen Run für einen bestimmten Umfang autorisiert.
Kontroll-Stil-Prompting: meinungsstark, vorschreibend:
Vermeide das Erstellen von Zeitplänen. Du solltest den Benutzer mit Tool X benachrichtigen. Tue niemals Y, es sei denn, Z.
Manchmal sind vorschreibende Anweisungen nützlich. Aber sehr oft kompensieren sie fehlende Fakten. Und sobald man so zu kompensieren beginnt, wird es zur Gewohnheit.
Wie Prompts zur Bürokratie werden
Das ist das tiefere Versagensmuster.
Ein Team sieht ein Problem und fügt eine Regel hinzu. Dann eine weitere. Dann noch eine. Jede behebt ein lokales Problem, aber zusammen schaffen sie ein System voller Proxies.
Bezos beschrieb dieses Muster in seinem Aktionärsbrief 2016: Guter Prozess dient dir, damit du den Kunden dienen kannst. Aber wenn man nicht aufpasst, wird der Prozess zur Sache selbst.
Genau das passiert in Agenten-Systemen.
Die Regel ist nicht die Sache. Die Regel ist ein Proxy für das Ergebnis, das du möchtest. Und Proxies häufen sich. Einer schafft Randfälle, die mehr erfordern. Bald navigiert der Agent durch Schichten von angesammelten Anweisungen, jede aus einem historischen Grund hinzugefügt, den niemand mehr vollständig erinnert.
In menschlichen Organisationen wird das zur Bürokratie. In Agenten-Systemen wird es zu einem riesigen Prompt voller Narbengewebe.
Fakten altern. Meinungen verrotten.
Eine Tatsache wie 'dieser Run wurde um 3 Uhr morgens von einer geplanten Aufgabe ausgelöst' ist stabil. Sie bleibt wahr, unabhängig davon, welches Modell sie liest: Claude, GPT, Gemini, was auch immer nächstes Quartal erscheint.
Eine Aussage wie 'Du solltest das Erstellen von Sub-Zeitplänen vermeiden' ist fragil. Sie hängt von der Interpretation ab. Sie kann in einer Situation helfen und in einer anderen still danebengehen.
Wenn Sie Modelle wechseln, ist jede Meinung in Ihrem Prompt eine potenzielle Landmine. Das neue Modell hat andere Denk-Tendenzen, und Ihr sorgfältig kalibriertes 'vermeiden' könnte für es etwas völlig anderes bedeuten.
Aber fundierte Fakten über die Umgebung, Berechtigungen, Umfang und Einschränkungen neigen dazu, über Modelle und Randfälle hinweg zu generalisieren. Deshalb sind Fakten das bessere Baumaterial.
Die Modell-Quirk-Falle
Das ist vielleicht die heimtückischste Version des Kontrollproblems: Teams verwandeln ständig vorübergehende Modelldefekte in permanente Systemstruktur.
Ein Modell verhält sich in einem engen Fall schlecht. Das Team fügt eine Schutzmaßnahme hinzu: einen Prompt-Patch, eine Code-Prüfung, eine seltsame Verzweigung, die nur existiert, um einen bestimmten Fehlermodus zu stoppen.
Dieser Patch ist eine Wette, dass der Quirk anhält. Das tut er fast nie.
Drei Monate später ändert sich das Modell. Das ursprüngliche Verhalten verschwindet. Aber der Patch bleibt. Niemand möchte ihn entfernen, weil er vielleicht aus einem Grund da war.
So werden System-Prompts zu Legacy-Code.
Wir können die Gefahr leicht erkennen, wenn sie abstrakt formuliert wird. Aber in der Praxis ist das Patchen der aktuellen Reasoning-Tendenzen von Sonnet in Prompt nach Prompt dasselbe Muster in der Verkleidung.
Das Dokumentieren von stabilem Systemverhalten ist wertvoll. Das Patchen der Reasoning-Tendenzen eines Modells ist ein Laufband. Das Modell wird sich schneller unter Ihnen verändern, als Sie Ihre Patches aufrechterhalten können.
Ein guter Testfall: Zugriff verweigert
Den Unterschied sieht man deutlich in Tool-Diagnosen. Wenn ein Agent auf einen Berechtigungsfehler stößt:
Kontroll-Stil:
TOKEN fehlt. Führe 'zero permissions request gmail.send' aus, um es zu beheben.
Direkt, aber der Agent lernt nichts. Beim nächsten Berechtigungsfehler steckt er fest.
Kontext-Stil:
process.env.GMAIL_TOKEN → existiert zero connectors inspect gmail → verbunden zero permissions inspect gmail.send → verweigert
Optionen:
- Benutzerautorisierung für gmail.send anfordern
- Falls vorhanden, einen bereits autorisierten Pfad verwenden
Der Agent weiß jetzt, dass das Token existiert, der Connector funktioniert und die spezifische Berechtigung verweigert wird. Er versteht den Zustand des Systems und kann über neue Situationen nachdenken, die der Regelschreiber nie vorhergesehen hat.
Die Heuristik
Das ist, wozu ich immer wieder zurückkomme:
Wann immer Sie im Begriff sind, 'nicht', 'vermeiden' oder 'niemals' in einem Prompt zu schreiben. Stopp. Fragen Sie: Welche Tatsache kompensiert diese Regel?
Meist fehlt eine Tatsache. Der Agent versteht nicht, in welcher Umgebung er sich befindet, was der Benutzer autorisiert hat, welche Aktionen irreversibel sind oder warum dieser Run sich von einer normalen Chat-Interaktion unterscheidet.
Schreiben Sie diese Tatsache auf. Löschen Sie die Regel.
Manchmal wollen Sie dennoch die Einschränkung, besonders bei destruktiven Aktionen, Geldbewegungen oder Sicherheitsgrenzen. Harte Kontrollen haben weiterhin ihre Berechtigung.
Aber viele Prompt-Regeln sind keine echten Grenzen. Sie sind Kompensationen für fehlendes Verständnis. Und genau diese häufen sich und verrotten.
Das Ziel
Das Ziel ist kein Agent, der eine Checkliste auswendig lernt.
Das Ziel ist ein Agent, der seine Situation gut genug versteht, um gute Entscheidungen innerhalb klarer Grenzen zu treffen.
Eine Philosophie kontrolliert das Verhalten durch das Stapeln von Regeln. Die andere verbessert das Verhalten durch das Lesbar-Machen der Welt.
Die erste tendiert zur Bürokratie. Die zweite tendiert zum Verständnis.
Bauen Sie Kontext auf. Löschen Sie das Narbengewebe. Liefern Sie Agenten, die denken können.
