Was ein Living Playbook wirklich ist.
Ein Living Playbook ist mehr als eine Prozessbeschreibung und mehr als ein statischer Workflow. Es ist eine ausführbare, rollenbewusste und beobachtbare Arbeitsweise — und der eigentliche Gegenstand, den Texenda verwaltet.
Die Leiter: Prompt → Skill → Playbook
Die meisten Unternehmen stehen auf Stufe eins und wundern sich, dass es nicht trägt. Der häufigste Denkfehler: Ein Skill wirkt fertig, ist für echte Arbeit aber viel zu klein geschnitten.
-
Der Prompt
Eine gute Formulierung, gespeichert in einem Dokument oder einer Prompt-Bibliothek.
Es fehlt
- Welche Quellen gelten
- Wie aktuell sie sein müssen
- Welche Tools verfügbar sind
- Welche Rechte gelten
- Wer freigibt
Ein guter Prompt ohne verlässlichen Kontext bleibt ein gut formulierter Wunsch.
-
Der Skill
Eine abgegrenzte Teilaufgabe mit Kontext, Instruktion und erlaubten Fähigkeiten. Schon deutlich mehr — aber bewusst klein.
Das Problem
„Zielgruppe strukturieren“ ist nützlich, aber niemand hat den Auftrag, eine Zielgruppe zu strukturieren. Der Auftrag heißt: eine Kampagne vorbereiten.
Einzelne Skills sind für reale Arbeit systematisch unterkomplex.
-
Das Living Playbook
Mehrere Skills, verwoben zu einer vollständigen Arbeitsweise — mit Reihenfolge, Bedingungen, Rollen, Freigaben und Ergebnisvertrag.
Der Unterschied
Es deckt die Aufgabe ab, die tatsächlich jemand vergeben hat — vom Auftrag bis zum freigegebenen Ergebnis. Und es verändert sich, wenn sich die Arbeit verändert.
Woraus ein Playbook besteht
Elf Bestandteile — jeder einzelne beantwortet eine Frage, die sonst im Kopf einer erfahrenen Person steckt.
-
Business-Ziel
Wozu das Ganze — in einem Satz.
-
Strukturierte Inputs
Was der Mensch mitbringen muss.
-
Freigegebene Datenquellen
Woher verbindliche Informationen kommen.
-
Context Recipes
Welcher Ausschnitt wann geladen wird.
-
Skills und Instruktionen
Wie vorgegangen wird.
-
MCP- und Systemfähigkeiten
Was technisch getan werden kann.
-
Rollen und Zugriffe
Wer was darf.
-
Guards und Freigaben
Wo ein Mensch zustimmen muss.
-
Output-Verträge
Wie das Ergebnis aussehen muss.
-
Qualitätskriterien
Wann es gut genug ist.
-
Monitoring und Run-Historie
Was beim letzten Mal passiert ist.
Sechs Eigenschaften, die es „lebend“ machen
Nimm eine davon weg, und du hast wieder ein Dokument, das niemand pflegt.
-
Ausführbar
Es wird nicht nur gelesen. Ein Agent kann es über Texenda tatsächlich verwenden.
-
Kontextbewusst
Es weiß, welche Informationen für die jeweilige Aufgabe verbindlich sind.
-
Rollenbewusst
Verschiedene Nutzer erhalten unterschiedliche Daten und Aktionen — im selben Playbook.
-
Beobachtbar
Texenda zeigt, welche Quellen, Skills und Capabilities tatsächlich verwendet wurden.
-
Versioniert
Änderungen an Quellen, Instruktionen, Rollen und Schritten bleiben nachvollziehbar.
-
Es entwickelt sich weiter
Aus realen Runs entstehen Vorschläge — geprüft und freigegeben von Menschen.
Das Playbook lernt nicht unkontrolliert. Es entwickelt sich durch beobachtete Nutzung und menschlich freigegebene Verbesserungen weiter.
Context Engineering ist kein Projekt, sondern ein Zustand
Der Kontext, den eine Aufgabe braucht, ist nie fertig: Quellen kommen hinzu, Systeme werden abgeschaltet, Teams ändern ihre Arbeitsweise, Regulierung ändert sich, frühere Annahmen erweisen sich als falsch.
-
Kontext gestalten
-
Kontext testen
-
Im Einsatz beobachten
-
Lücken erkennen
-
Recipe anpassen
-
Neue Version freigeben
Abgrenzung zu dem, was ihr schon habt
-
Wiki / Handbuch
Erklärt den Ablauf für Menschen, kennt aber weder den aktuellen Fall noch die Rechte des Lesenden — und ist nicht ausführbar.
-
Workflow-Automatisierung
Führt feste Schritte aus, verträgt aber keine Varianz und kein Urteilsvermögen. Ein Playbook lässt dem Agenten Spielraum innerhalb harter Grenzen.
-
Custom GPT / Assistant
Lebt in einem Client, ist nicht versioniert, kennt keine Rollen und verschwindet, wenn der Ersteller das Unternehmen verlässt.
-
RAG-Suche
Findet ähnliche Textstellen. Sie unterscheidet nicht zwischen verbindlich und veraltet und verbindet Wissen nicht mit erlaubten Aktionen.
-
Klassisches Process Mining
Analysiert strukturierte Events aus Geschäftssystemen. Agentische Arbeit — Kontextsuche, Rückfragen, verworfene Quellen — taucht dort gar nicht auf.