Kurz gesagt: Rolle zwei folgt nicht denselben vier Kriterien wie Rolle eins. Entscheidend sind zwei neue Fakten: was dein erster Review über deine eigene Prüfkompetenz zeigt, und wie klar die Übergabe zwischen beiden Rollen über Domains und Routines definiert ist.

Deine zweite Rolle

Rolle eins, deine erste AI-Operator-Routine, läuft. Rolle zwei, die nächste, wählst du nach anderen Kriterien, und das ist kein Nachteil.

Rolle eins läuft seit ein paar Wochen. Der Operator ist eingerichtet, die FTT (First Time Through) wird wöchentlich geprüft, und vielleicht ist die Rolle sogar schon eine Stufe auf den Adoption Levels hochgestuft. Der nächste Gedanke kommt fast von selbst: Wenn das funktioniert hat, mach es noch einmal. Suche eine weitere Aufgabe, bei der sich "fertig" beschreiben lässt, die sich wiederholt, bei der ein Fehler billig ist und der Zugriff eng bleibt. Richte den nächsten Operator nach demselben Muster ein, und starte auch diese Rolle auf der Stufe Shadow.

Das ist verständlich. Es ist auch der falsche Hebel für diesen Schritt.

Die vier Kriterien für die erste Rolle beantworten eine Frage, die für Rolle zwei schon beantwortet ist: ob du überhaupt in der Lage bist, einen Standard zu formulieren und dagegen zu prüfen. Das war das eigentliche Risiko bei Rolle eins, nicht die Aufgabe selbst. Rolle eins hat dieses Risiko getragen, damit du die Mechanik lernst, ohne dass gleich ein teurer Fehler passiert. Diese Mechanik hast du jetzt. Offen sind zwei andere Dinge, und nur Rolle eins konnte sie dir zeigen, weil es vorher keine zweite Rolle gab, an der sie sich zeigen ließen.

Was Rolle eins wirklich über deine Prüfung zeigt

Das Erste ist der Zustand deiner eigenen Prüfung, nicht der Fähigkeiten des Operators. Über die Wochen im wöchentlichen Review hat sich ein Muster gezeigt, das sich in zwei Gruppen sortieren lässt.

Die eine Gruppe sind Prüfungen, die verlässlich waren: eine feste Länge, ein Format, eine konkrete Zahl, ein Abgleich gegen eine Vorlage. Hier hast du "fertig" schon vorher in etwas Prüfbares übersetzt, und die Prüfung dauert Sekunden, weil sie kein Urteil braucht, nur einen Abgleich.

Die andere Gruppe sind Prüfungen, die immer wieder geschliffen wurden: Ton, Priorisierung, "fühlt sich richtig an". Genau dort ist am ehesten etwas durchgerutscht, weil der Standard dahinter nie ganz explizit wurde. Du hattest ihn im Kopf, nicht schriftlich festgehalten, und das merkst du erst, wenn du unter Zeitdruck einmal durchwinkst statt zu prüfen.

Rolle eins hat nicht gezeigt, was der Operator kann. Sie hat gezeigt, wo deine Prüfung selbst schon ein Standard ist, und wo sie noch ein Bauchgefühl ist.

Diese Aufteilung ist keine Kritik an dir. Sie ist eine Landkarte, und zwar eine für eine Domäne, nicht für eine allgemeine Fähigkeit. Du prüfst Zahlen vielleicht präzise und Text vage, oder umgekehrt. Genau diese Landkarte, nicht die vier alten Kriterien, entscheidet ab jetzt mit, wo Rolle zwei hingehört.

Die Schnittstelle wird real

Es gibt einen zweiten Punkt, den Rolle eins nicht zeigen konnte, solange sie allein war. Im Tools-Tab hat jeder Operator ein Feld namens Routines: "Routines, oder ganze Domänen, die dieser Operator berühren darf. Das ist aktuell die einzige Kontrolle im Produkt, die Routinenzugriff vergibt." Das ist keine Nebenbemerkung, sondern eine reale Grenze. Nichts sonst im Produkt entscheidet heute, wer welche Routine anfassen darf.

Bei einer einzigen Rolle ist dieser Grant, was er sein muss, und sonst interagiert nichts damit. Es gibt keine zweite Domänen-Zuweisung, mit der sich ihr Zugriff überschneiden könnte, und deshalb wird eine schlecht abgegrenzte oder vage Übergabe nie auf die Probe gestellt. Der häufigste Fehler dabei ist, die Rolle isoliert zu denken, und bei einer einzigen Rolle bleibt dieser Fehler unsichtbar. Ein Mensch am anderen Ende einer Übergabe füllt die Lücke automatisch, ohne dass irgendwer merkt, dass da eine Lücke war.

Sobald eine zweite Rolle dazukommt, liegen ihre Routines- und Domains-Grants direkt neben denen der ersten, zusammen mit ihren eigenen Tools und Connections. Genau an dieser Stelle wird eine undefinierte Übergabe, was zählt als "fertig" bei Rolle eins, in welcher Form, geprüft von wem, entweder zu einem echten Blocker oder zu einer still veraltenden Übergabe, die niemand bemerkt.

Ein Beispiel, rein zur Illustration und keine Aussage über eine echte Rolle: Eine Content-Rolle hat in ihren Domains den Bereich Content, ihre Routines decken das Schreiben und Freigeben ab. Eine Distributions-Rolle hat eigene Domains und Routines für die Kanäle, in die Texte ausgespielt werden. Beide Zugriffsrechte sehen für sich genommen sauber aus. Das Problem taucht erst auf, wenn "freigegeben" nirgendwo als Ausgabe der Content-Rolle definiert wurde, weil "fertig" bisher nur bedeutete, dass ein Mensch es liest. Für Rolle zwei reicht das nicht. Sie braucht einen Zustand, den sie zuverlässig erkennt, kein Gefühl. Ohne diese Definition startet Rolle zwei entweder auf einer alten Version, oder sie wartet auf ein Signal, das nie kommt, weil Rolle eins es nie ausgesendet hat.

Dieselbe Lücke entscheidet auch, was passiert, wenn Rolle zwei von etwas abhängt, das Rolle eins noch nicht fertig hat. Ohne eine explizite Antwort darauf blockiert Rolle zwei still, oder schlimmer, sie arbeitet mit dem, was gerade da ist, und niemand merkt es, bis das Ergebnis schon draußen ist.

Wie du Rolle zwei tatsächlich auswählst

Die vier Kriterien von letzter Woche, beschreibbares "fertig", wöchentliche Wiederholung, billiger Fehler, enger Zugriff, gelten für Rolle zwei nicht mehr unverändert. Sie waren dafür gebaut, die erste Wette abzusichern, während du die Mechanik gelernt hast. Diese Wette ist entschieden. Rolle zwei braucht keinen Beweis mehr, dass du einen Standard schreiben kannst. Sie braucht die Antwort auf eine andere Frage: In welcher Domäne ist dieser Standard bei dir bereits am stärksten, und wo berührt diese Domäne die Arbeit von Rolle eins.

Geh dafür zurück zu deinen Review-Notizen und sortiere, wo Prüfungen zuverlässig etwas gefangen haben, und zwar früh, nicht erst am Ende. Nicht die Domäne, die am meisten reizt, weil sie neu und interessant wirkt. Nicht die Domäne, die am meisten schmerzt, weil sie seit Monaten nervt. Das ist derselbe Leidensdruck, den die erste Auswahl schon einmal ausgeschlossen hat, nur diesmal mit dem zusätzlichen Risiko einer schlecht definierten Schnittstelle obendrauf. Wähle die Domäne, in der du am ehesten sagen kannst, wann ein Ergebnis nicht durchgeht, und in der sich eine Übergabe an eine andere Rolle sauber beschreiben lässt.

Company 0

Bei uns zeigt sich das an der Übergabe zwischen der Rolle, die den Artikel schreibt und veröffentlicht, und der Rolle, die die Social-Beiträge dazu verfasst. Die zweite braucht die veröffentlichte Adresse des Artikels, um sie in den Beitrag für Dienstag zu schreiben. Diese Übergabe war nie als Signal definiert, sondern lief immer über eine Konvention: die Social-Rolle ruft die Adresse ab, und wenn die Seite noch nicht da ist, lässt sie den Link einfach weg.

In der Praxis heißt das, dass der Link fast jede Woche nachträglich ergänzt wird, sobald der Artikel live ist, weil beide Rollen fast gleichzeitig arbeiten und die zweite fertig wird, bevor die erste veröffentlicht hat. Es funktioniert, aber nur, weil jemand die Lücke jede Woche von Hand schließt. Genau das beschreibt dieser Artikel: eine Schnittstelle, die so lange unsichtbar bleibt, wie ein Mensch sie stillschweigend ausgleicht.

Was das für dich heißt

Bevor du Rolle zwei festlegst, schreib eine einzige Sache auf: Wo landet das Ergebnis von Rolle eins gerade, und wer oder was fasst es als Nächstes an. Ein Mensch, ein System, eine Ablage, ein Kunde. Diese Antwort ist keine Fleißarbeit. Sie ist die Schnittstelle, die Rolle zwei respektieren muss, noch bevor du weißt, wie die zweite Rolle heißt.

Wenn dir dabei auffällt, dass du diese Frage nicht klar beantworten kannst, ist das kein Rückschlag. Es ist dieselbe Art von Befund wie bei Rolle eins: eine Stelle, an der etwas bisher nur in deinem Kopf existiert, diesmal nicht der Standard für ein Ergebnis, sondern der Weg, den es danach nimmt.

Häufige Fragen

Wann bin ich bereit für eine zweite Rolle?

Wenn die FTT deiner ersten Rolle stabil ist und dein wöchentlicher Review dir zeigt, in welcher Domäne deine eigene Prüfung bereits zuverlässig ist. Diese Landkarte deiner Prüfkompetenz entscheidet, nicht ob die erste Rolle "funktioniert hat".

Muss ich dieselben vier Kriterien wieder anwenden?

Nein. Die vier Kriterien haben das Risiko der ersten Wette abgesichert, während du die Mechanik gelernt hast. Für Rolle zwei zählt stattdessen, in welcher Domäne dein eigener Prüfstandard schon am stärksten ist und wo diese Domäne die Arbeit von Rolle eins berührt.

Was ist eine Routines-Zuweisung, und warum wird sie erst bei der zweiten Rolle wichtig?

Im Tools-Tab legt das Feld Routines fest, welche Domänen ein Operator berühren darf, und ist damit die einzige Kontrolle im Produkt, die das steuert. Bei einer einzigen Rolle überschneidet sich nichts, deshalb bleibt eine unklare Übergabe unsichtbar, bis eine zweite Rolle dazukommt.

Was mache ich konkret, bevor ich die zweite Rolle festlege?

Schreib auf, wo das Ergebnis von Rolle eins heute landet und wer oder was es als Nächstes anfasst, ein Mensch, ein System, eine Ablage. Diese eine Antwort ist die Schnittstelle, die Rolle zwei respektieren muss, noch bevor die zweite Rolle feststeht.