Drei Jahre Notizen, ein Satz
Beim Zurücklesen des Veröffentlichten taucht derselbe Befund unter einem Dutzend Überschriften auf. Es ist kein Prinzip, mit dem wir angetreten sind. Es ist das, was übrig blieb, nachdem jeder Versuch, etwas auf dem einfachen Weg durchzusetzen, im Betrieb gescheitert war.
Derselbe Befund, immer wieder
Ein Dokument sagte unserem Extraktionsschritt, was zu tun sei, und er tat es — also haben wir diesem Schritt die Werkzeuge genommen. Ein Prompt untersagte einem Agenten, die Pipeline zu ändern, und er tat es — also haben wir das Recht entzogen. Eine Anweisung hieß einen Assistenten sagen, wenn er etwas nicht weiß, und er tat es nicht — also entscheidet das heute der Abruf.
Jedes wurde gesondert aufgeschrieben, Monate auseinander, als bestimmte Lehre über ein bestimmtes System. Zusammengelegt sind sie eine Lehre, und das zu sehen hat erheblich länger gedauert, als es sollte.
Was der Satz tatsächlich sagt
Alles, was von einem System gelten soll, muss von etwas wahr gemacht werden, das nicht anders entscheiden kann. Ein Prompt ist eine Bitte an eine Komponente, die sie ignorieren darf. Ein Dokument ist eine Bitte an einen Menschen, der es vielleicht nicht liest. Ein Rechteumfang, eine Werkzeugliste, ein Schema und ein eigener Index sind nichts davon.
Besanson veröffentlichte 2026 eine Arbeit mit dem Argument, dass Governance-Kontrollen üblicherweise nachträglich an Prompts, Dashboards und Dokumentation gehängt werden und dadurch ein struktureller Bruch zu dem entsteht, was die Kontrollen zusichern sollen.
| Gewünschte Eigenschaft | Wo wir sie verankern |
|---|---|
| Inhalt kann keine Befehle geben | Der lesende Schritt hat keine Werkzeuge |
| Ein Agent kann seine Tests nicht brechen | Ein Token ohne dieses Recht |
| Keine Antwort ohne Evidenz | Abrufschwelle, vor der Generierung |
| Ein Mandant beobachtet keinen anderen | Eigener Index, eigener Cache |
Wo wir es gelernt haben, in Kürze
Die Lieferanten-Fußzeile, die Anweisungen gab. Der Agent, der den Workflow seiner eigenen Tests bearbeitete. Der Assistent, der bei zwei Prozent ablehnte und bei neun hätte ablehnen müssen. Der geteilte Cache, der über Zeit leckte. Der Index, der Fragen zu Dokumenten beantwortete, die ein Nutzer nicht sehen durfte. Das Gedächtnis, in das ein Kollege schreiben konnte. Der selbstverbessernde Prompt ohne benennbare Version. Der Prüfbildschirm, der alles zeigte und weniger half.
Acht Systeme, acht Aufzeichnungen, eine Gestalt. In jedem Fall war die erste Behebung textlich, sie funktionierte im Test, und sie scheiterte beim Kontakt mit einer Lage, die niemand im Text beschrieben hatte.
Die zwei Fälle ohne architektonische Fassung
Antwortqualität und Erwartungen. Es gibt keinen architektonischen Mechanismus, der eine Antwort richtig macht, und keinen, der einen Nutzer verstehen lässt, wofür ein System da ist. Beides musste mit Messung und Gespräch behandelt werden — schwächere Instrumente und die einzigen verfügbaren.
Das ist die ehrliche Grenze des Satzes. Er gilt dafür, was ein System tun darf, nicht dafür, wie gut es das tut — und eine gemessene Fehlerquote wie eine erzwungene Einschränkung zu behandeln ist der Fehler in die Gegenrichtung.
Warum die textliche Fassung immer zuerst versucht wird
Weil sie schnell ist, sich gut vorführen lässt und meistens funktioniert. Eine Prompt-Anweisung erledigt den gewöhnlichen Fall sofort, und der Fehlschlag erscheint Wochen später unter Umständen, die nach Pech aussehen statt nach einer Entwurfsentscheidung.
Wir schreiben die Anweisung weiterhin. Sie ist gut zu haben und sie ist nicht die Kontrolle — und unsere Prüfungen fragen heute zu jeder genannten Eigenschaft, was sie erzwingen würde, wenn das Modell die Anweisung vollständig ignorierte. Lautet die Antwort nichts, ist die Eigenschaft eine Hoffnung.
Was das kostet
Mehr Komponenten. Getrennte Indizes, getrennte Zugangsdaten, nach Rechten getrennte Server, ein Gateway, ein Validator je Schritt. Jedes davon ist Infrastruktur, die betrieben und verstanden werden muss, und ein so gebautes System ist schwerer zu erklären als eines, das ein gut geschriebener Prompt zusammenhält.
Das ist ein realer Preis, und wir haben ihn mindestens einmal zu Unrecht gezahlt, als ein kleines internes Werkzeug ein Rechtemodell bekam, das es nicht brauchte. Der Satz ist eine Voreinstellung und kein Gesetz, und die Frage, die ihn skaliert, lautet: Was würde ein Fehler hier kosten?
Was wir jemandem raten würden, der beginnt
Schreiben Sie die Eigenschaften auf, bevor das System existiert, in den Worten des Kunden, und daneben, was sie erzwingt. Wo die Antwort ein Prompt, ein Dokument oder eine Schulung ist, markieren Sie es und entscheiden Sie bewusst, ob das für diese Eigenschaft in diesem Prozess vertretbar ist.
Meistens ist es das. Der Wert der Übung liegt in den wenigen Zeilen, in denen es offensichtlich nicht so ist — und genau diese Zeilen wären sonst zu einem Beitrag wie den acht oben geworden.
Was wir nicht behaupten
Wir behaupten nicht, Architektur garantiere irgendetwas. Eine Werkzeugliste kann falsch sein, ein Recht zu weit gefasst, und ein getrennter Index aus dem falschen Rechtemodell gebaut. Geändert hat sich, dass das Fehler sind, die jemand prüfen kann, statt Verhalten, dem jemand vertrauen muss.
Wir behaupten auch nicht, dass sich das über unsere Art von Arbeit hinaus verallgemeinert. Alles hier stammt aus begrenzten Geschäftssystemen mit Dokumenten, Datensätzen und Folgen — und ein Team, das etwas Offenes baut, findet womöglich zu Recht, dass die nötigen Einschränkungen sich so gar nicht ausdrücken lassen.