Role Contract statt Prompt: Wie AI-Operatoren in Rocket Routine OS gesteuert werden

Du schreibst einen Prompt. Die AI liefert ein Ergebnis. Manchmal genau das, was du brauchst. Manchmal etwas, das in die richtige Richtung geht, aber nachgearbeitet werden muss. Manchmal etwas, das komplett am Ziel vorbeigeht. Du korrigierst, formulierst den Prompt um, versuchst es erneut. Und beim nächsten Mal passiert dasselbe in einer anderen Variante.

Das Problem ist nicht die AI. Das Problem ist, dass ein Prompt kein Steuerungsinstrument ist.

Ein Prompt beschreibt, was du gerade willst. In diesem Moment, für diese eine Aufgabe. Er enthält keine Grenzen. Keine Qualitätskriterien. Keine Entscheidungsrechte. Keine Eskalationsregeln. Keinen Mechanismus, der sicherstellt, dass das Ergebnis einem überprüfbaren Standard entspricht. Ein Prompt ist eine Anweisung. Ein Role Contract ist ein Governance-Artefakt.

Ein Prompt beschreibt, was du gerade willst. Ein Role Contract definiert, was ein Operator dauerhaft darf, muss und nicht darf.

Was passiert, wenn du AI ohne Governance einsetzt

Die meisten Unternehmen, die heute mit AI arbeiten, machen im Grunde dasselbe: Sie geben einem Sprachmodell Anweisungen und hoffen auf brauchbare Ergebnisse. Manche haben ausgefeiltere Prompts als andere. Manche haben Prompt-Templates. Manche haben sogar Prompt-Bibliotheken. Aber die Grundstruktur ist identisch: ein Mensch formuliert eine Anweisung, ein Modell produziert eine Antwort, ein Mensch beurteilt das Ergebnis.

Das funktioniert für Ad-hoc-Aufgaben. Für alles, was einmal gemacht wird und nie wieder. Für die schnelle Zusammenfassung, den einmaligen Entwurf, die spontane Recherche.

Es funktioniert nicht für wiederkehrende Arbeit. Und in einem Unternehmen ist der allergrößte Teil der Arbeit wiederkehrend. Der wöchentliche Report. Die tägliche Qualitätsprüfung. Die monatliche Analyse. Die Routinen, die das Unternehmen am Laufen halten.

Wenn du wiederkehrende Arbeit an eine AI delegierst, ohne explizite Governance, passieren drei Dinge:

1. Die Qualität schwankt. Ohne definierte Qualitätskriterien entscheidet der Mensch bei jeder Prüfung neu, ob das Ergebnis "gut genug" ist. Das ist subjektiv, inkonsistent und nicht skalierbar.

1. Die Grenzen verschwimmen. Ohne expliziten Scope macht die AI mal mehr, mal weniger als gewünscht. Sie trifft Entscheidungen, die sie nicht treffen sollte. Oder sie fragt bei Dingen nach, die sie eigenständig hätte lösen können.

1. Es gibt kein Lernen. Wenn jeder Durchlauf von einem neuen Prompt abhängt, gibt es keinen Mechanismus, der das System verbessert. Fehler wiederholen sich. Gute Lösungen sind Zufallsprodukte, keine Systemeigenschaften.

Der Role Contract: acht Komponenten

Rocket Routine OS löst das mit einem formalen Artefakt: dem Role Contract. Ein Role Contract ist die vollständige Spezifikation dessen, was ein AI-Operator innerhalb des Systems darf, muss und nicht darf. Er besteht aus acht Komponenten.

1. Zweck und Scope-Grenzen

Was ist die Aufgabe dieses Operators? Und, genauso wichtig: Was gehört nicht zu seiner Aufgabe? Ein Content-Operator produziert Inhalte nach definierten Standards. Er entscheidet nicht über die Content-Strategie. Er verändert nicht das Branding. Er kommuniziert nicht direkt mit Kunden. Die Grenze ist genauso wichtig wie der Auftrag.

2. Ergebnisse und Metriken

Welche messbaren Ergebnisse muss der Operator liefern? Nicht "gute Inhalte", sondern: wöchentlicher Blog-Artikel mit definierten Qualitätskriterien, FTT-Rate über 80 Prozent, Terminologie entspricht dem Vokabular im Knowledge Base. Messbar. Überprüfbar. Nicht verhandelbar.

3. Routine-Ownership und Standard-Outputs

Welche wiederkehrenden Routinen gehören zu dieser Rolle? Welche Artefakte produziert der Operator standardmäßig? Ein Content-Operator hat vielleicht drei Routinen: Blog-Produktion (wöchentlich), LinkedIn-Ableitung (dreimal wöchentlich), Qualitätsprüfung bestehender Inhalte (monatlich). Jede Routine hat einen definierten Output und einen definierten Rhythmus.

4. Entscheidungsrechte, Freigaben und Eskalation

Das ist der Kern. Welche Entscheidungen darf der Operator eigenständig treffen? Welche erfordern eine Freigabe? Und bei welchen Situationen muss er eskalieren?

Ein Content-Operator darf eigenständig entscheiden, welches Synonym er verwendet. Er darf nicht eigenständig entscheiden, ob ein neues Thema in den Content-Plan aufgenommen wird. Wenn ein Qualitätskriterium unklar ist, eskaliert er, anstatt eine Interpretation zu wählen.

Entscheidungsrechte definieren nicht, was ein Operator kann. Sie definieren, was er darf. Das ist der Unterschied zwischen einem Tool und einem gesteuerten Akteur.

Diese Abstufung nutzt die Decision Impact Classification aus dem Rocket Routine OS Konzept. Leaf-Entscheidungen (Routine, geringes Risiko) trifft der Operator selbst. Branch-Entscheidungen (operativ, mittleres Risiko) erfordern eine Freigabe. Trunk- und Root-Entscheidungen liegen beim Menschen.

5. Tool-Zugangsrichtlinie

Welche Werkzeuge darf der Operator nutzen? Mit welchen Rechten? Ein Content-Operator hat Lesezugriff auf das Knowledge Base, Schreibzugriff auf den Content-Bereich und keinen Zugriff auf Finanzdaten. Lese- und Schreibrechte werden separat definiert. Kein Operator bekommt mehr Zugriff, als seine Rolle erfordert.

6. Qualitätspflichten und Evidenztypen

Was muss der Operator nachweisen, um ein Ergebnis als fertig zu melden? Welche Art von Evidenz ist erforderlich? Ein Content-Operator muss bei jedem Artikel nachweisen: Vokabular-Check bestanden, Scope-Disziplin eingehalten (nur Themen aus dem Quellartikel), beide Sprachversionen als eigenständige Texte produziert, kein verbotener Begriff verwendet. Das ist keine optionale Checkliste. Das ist eine Pflicht.

7. Schnittstellen

Was konsumiert der Operator von anderen Rollen und Domains? Was produziert er für andere? Ein Content-Operator konsumiert den wöchentlichen Topic aus der Content-Pipeline (Marketing-Domain) und das Vokabular aus dem Knowledge Base (Wissens-Domain). Er produziert fertige Artikel für die Veröffentlichungs-Routine (Marketing-Domain) und Social-Media-Ableitungen für den Social-Operator. Schnittstellen sind explizit. Kein Operator arbeitet in Isolation.

8. Upgrade-Regeln

Wie wird der Role Contract aktualisiert, wenn das System lernt? Jedes Mal, wenn die Impact-Phase eine Abweichung feststellt, wird geprüft: Liegt die Ursache im Role Contract? Fehlt eine Grenze? Ist ein Entscheidungsrecht zu weit oder zu eng? Muss ein Qualitätskriterium geschärft werden?

Ein Role Contract, der sich nie ändert, ist ein Zeichen dafür, dass niemand aus den Ergebnissen lernt.

Upgrade-Regeln definieren, wer den Contract ändern darf, unter welchen Bedingungen und mit welchem Freigabeprozess. Das stellt sicher, dass Contracts sich weiterentwickeln, ohne willkürlich verändert zu werden.

Poka Yoke: Fehler strukturell verhindern

Wenn du aus der Qualitätsmanagement-Welt kommst, kennst du Poka Yoke. Das Prinzip stammt aus dem Toyota-Produktionssystem und bedeutet: Gestalte den Prozess so, dass Fehler nicht passieren können, anstatt sie nachträglich zu finden und zu korrigieren.

Role Contracts sind nach diesem Prinzip gebaut. Die Scope-Grenzen verhindern, dass der Operator Aufgaben übernimmt, die nicht zu seiner Rolle gehören. Die Entscheidungsrechte verhindern, dass er Entscheidungen trifft, die über seine Kompetenz hinausgehen. Die Tool-Zugangsrichtlinie verhindert, dass er auf Daten zugreift, die er nicht braucht. Die Qualitätspflichten verhindern, dass ungeprüfte Ergebnisse als fertig gemeldet werden.

Das ist kein Misstrauen gegenüber der AI. Es ist gutes Systemdesign. Dieselben Prinzipien gelten für menschliche Rollen in gut geführten Organisationen. Der Unterschied: Bei menschlichen Rollen werden diese Grenzen oft implizit gelassen und erst sichtbar, wenn jemand sie überschreitet. Bei AI-Operatoren müssen sie explizit sein, weil ein Sprachmodell Implizites nicht zuverlässig interpretiert.

Drei Stufen der Adoption

Nicht jeder Operator startet mit voller Autonomie. Rocket Routine OS definiert drei Adoption Levels für jeden Operator in jeder Domain:

1. Shadow. Die AI erstellt Entwürfe. Der Mensch führt aus. Jedes Ergebnis wird manuell geprüft, bevor es wirksam wird. Das ist die Einstiegsstufe: Du siehst, was die AI produziert, behältst aber die vollständige Kontrolle.

1. Copilot. Die AI führt aus, aber innerhalb expliziter Freigabe-Gates. Ein Content-Operator im Copilot-Modus produziert den Artikel und liefert die Qualitätsevidenz. Der Mensch gibt frei oder schickt zurück. Die AI arbeitet, der Mensch entscheidet.

1. Autopilot. Die AI führt aus und liefert innerhalb der strengen Grenzen des Role Contracts. Der Mensch steuert durch Ausnahmen und prüft durch Audits. Die Qualitätsbestätigung läuft automatisch gegen die definierten Kriterien. Der Mensch greift ein, wenn die Metriken abweichen, nicht bei jedem einzelnen Ergebnis.

Der Übergang zwischen den Stufen ist nicht willkürlich. Er basiert auf messbarer Performance: Wenn die FTT-Rate eines Operators über mehrere Zyklen konsistent über dem Schwellenwert liegt, kann die nächste Stufe aktiviert werden. Wenn sie sinkt, geht der Operator eine Stufe zurück. Das ist kein manueller Vertrauensbeweis. Das ist eine datenbasierte Entscheidung.

Was in Company 0 passiert

Ich betreibe in Company 0 seit mehreren Wochen einen Content-Operator mit einem Role Contract. Der Operator hat einen klar definierten Zweck: Inhalte für alle Kanäle produzieren, abgeleitet vom wöchentlichen Blog-Artikel, unter Einhaltung der Markenregeln.

Ein konkretes Beispiel. Letzte Woche hat der Operator den Blog-Artikel zur I2I-Loop geschrieben. In der Impact-Phase hat die Qualitätsbestätigung festgestellt, dass eine Formulierung im deutschen Text einen Begriff verwendet hat, der nicht im Vokabular definiert ist. Das Ergebnis: Nicht der Operator wurde korrigiert. Der Role Contract wurde um eine explizite Regel ergänzt, die verlangt, dass jeder fachliche Begriff gegen die Vokabeltabelle geprüft wird, bevor das Ergebnis als fertig gemeldet wird.

Das ist ein kleines Beispiel. Aber es zeigt den Mechanismus. Der Role Contract ist kein statisches Dokument. Er ist ein lebendes Artefakt, das sich mit jedem Durchlauf verbessert. Und weil die Upgrade-Regeln definiert sind, passiert das systematisch, nicht zufällig.

Der Operator läuft aktuell auf Copilot-Level. Ich prüfe jedes Ergebnis, bevor es veröffentlicht wird. Die FTT-Rate liegt bei 75 Prozent nach drei Wochen. Das bedeutet: Drei von vier Ergebnissen bestehen die Qualitätsbestätigung beim ersten Durchlauf. Das ist ein Ausgangspunkt, kein Zielwert. Mit jeder Upgrade-Iteration steigt die Rate.

Warum das kein "besserer Prompt" ist

Vielleicht denkst du: Das klingt aufwändig. Warum nicht einfach einen besseren Prompt schreiben?

Die Antwort liegt im Unterschied zwischen einer Anweisung und einem System.

Ein Prompt ist flüchtig. Er existiert in einem Kontext und verschwindet danach. Er hat keine Erinnerung an frühere Durchläufe. Er hat keine eingebaute Qualitätsprüfung. Er hat keine definierten Grenzen, die über den aktuellen Aufruf hinausgehen. Und er hat keinen Upgrade-Mechanismus.

Ein Role Contract ist persistent. Er überlebt den einzelnen Durchlauf. Er definiert, was über viele Durchläufe hinweg gelten soll. Er enthält die Qualitätskriterien, an denen jedes Ergebnis gemessen wird. Und er hat einen eingebauten Mechanismus, der ihn verbessert, wenn die Ergebnisse das erfordern.

Der Prompt sagt: "Tu das." Der Role Contract sagt: "So arbeitest du. Innerhalb dieser Grenzen. Mit diesen Rechten. Gegen diese Standards. Und wenn etwas nicht stimmt, ändert sich der Contract, nicht nur der nächste Prompt."

Warum das auch kein Skill ist

Wenn du dich mit AI-Agenten beschäftigst, kennst du das Konzept von Skills: wiederverwendbare Anweisungspakete, die einem Agenten beibringen, wie er eine bestimmte Aufgabe ausführt. Ein Skill für Blog-Produktion enthält die Schritte, die Templates, die Formatierungsregeln. Ein Skill für Datenanalyse enthält die Abfragelogik, die Visualisierungsstandards, die Ausgabeformate.

Skills sind Fähigkeiten. Sie beschreiben das Wie.

Ein Role Contract beschreibt etwas anderes. Er beschreibt das Wer, das Was, das Unter-welchen-Bedingungen und das Mit-welchen-Rechten. Ein Skill sagt dem Operator: "So schreibst du einen Blog-Artikel." Der Role Contract sagt: "Du darfst Blog-Artikel schreiben, innerhalb dieses Scopes, mit diesen Entscheidungsrechten, gegen diese Qualitätskriterien, und wenn etwas nicht stimmt, wird der Contract angepasst."

Die beiden Konzepte arbeiten zusammen, sind aber nicht austauschbar:

1. Ein Skill ist eine Fähigkeit. Er definiert eine Prozedur. Er hat kein Konzept von Entscheidungsrechten, Eskalationsregeln oder Qualitätspflichten. Ein Skill weiß nicht, ob der Operator ihn überhaupt ausführen darf.

1. Ein Role Contract ist ein Governance-Artefakt. Er referenziert Skills als Teil der Routine-Ownership (Komponente 3) und der Tool-Zugangsrichtlinie (Komponente 5). Aber er fügt alles hinzu, was ein Skill nicht enthalten kann: Grenzen, Rechte, Pflichten, Upgrade-Mechanismen.

1. Ein Skill ohne Role Contract ist eine ungesteuerte Fähigkeit. Er kann ausgeführt werden, aber niemand hat definiert, wer ihn ausführen darf, welcher Qualitätsstandard gilt oder was passiert, wenn das Ergebnis nicht stimmt.

Die Analogie aus der menschlichen Arbeitswelt: Ein Skill ist wie die Fähigkeit, Code zu schreiben. Ein Role Contract ist die Stellenbeschreibung, die Berechtigungsmatrix und die Qualitätsstandards in einem. Programmieren zu können sagt dir nicht, was du ausliefern darfst.

Ein Skill ohne Role Contract ist eine Fähigkeit ohne Governance. Der Role Contract macht aus einer Fähigkeit eine gesteuerte Verantwortung.

Der Role Contract im I2I-Loop

Der Role Contract existiert nicht in Isolation. Er ist in die I2I-Loop eingebettet, die ich in Blog #3 erklärt habe.

In der Intent-Phase definiert der Role Contract, welche Ergebnisse der Operator liefern muss und unter welchen Bedingungen. In der Insight-Phase bestimmt er, welche Entscheidungen der Operator treffen darf und welche Methoden er anwenden muss. In der Implementation-Phase steuert er, welche Tools der Operator nutzen darf und welche Routinen er ausführt. In der Impact-Phase liefert er die Kriterien, gegen die das Ergebnis geprüft wird, und die Upgrade-Regeln, die bestimmen, wie der Contract sich weiterentwickelt.

Der Role Contract ist damit das Bindeglied zwischen dem universellen Steuerungsprinzip (I2I-Loop) und der konkreten Ausführung. Die Loop definiert den Kreislauf. Der Control Tower macht ihn sichtbar. Der Role Contract macht ihn operativ, indem er festlegt, wer was unter welchen Bedingungen tun darf.

Was als Nächstes kommt

Der Role Contract steuert den einzelnen Operator. Die I2I-Loop steuert den Kreislauf. Aber woher kommen die Strukturen, innerhalb derer Operatoren arbeiten? Nächste Woche erkläre ich, wie Rocket Routine OS die Artefakte definiert, die jede Domain braucht: Outcomes, Metrics, Principles, Routines, Initiatives, Knowledge, Learning. Sieben Artefakttypen, ein kanonisches Modell. OMPRIKL.

Wenn du ein gründergeführtes B2B-Unternehmen mit 15 bis 50 Mitarbeitern führst und AI-Operatoren willst, die innerhalb klarer Governance arbeiten: rocket-routine.com