Agentische Arbeit wird zum ersten Mal sichtbar.
Weil alle freigegebenen Kontext- und Capability-Flüsse über einen Punkt laufen, kann Texenda auswerten, wie Arbeit mit Agenten tatsächlich abläuft — und daraus konkrete Verbesserungsvorschläge ableiten.
Was klassisches Process Mining sieht
Strukturierte Events aus Geschäftssystemen: Auftrag angelegt, Rechnung gebucht, Ticket geschlossen. Sauber, aber sehr grob.
- Auftrag angelegt
- → geprüft
- → freigegeben
- → abgeschlossen
Was bei agentischer Arbeit wirklich passiert
Ein dichter Ablauf aus Suchen, Verwerfen, Nachladen, Rückfragen und Korrekturen — bisher komplett unsichtbar.
- Agent sucht Kontext
- verwirft Quellen
- lädt zusätzliche Daten
- nutzt mehrere Capabilities
- stellt Rückfragen
- erzeugt Entwurf
- Mensch korrigiert Kontext
- Agent wiederholt Schritt
- Mensch erteilt Freigabe
Welche Signale erfasst werden
Alles, was über den zentralen Harness läuft und für die Verbesserung der Arbeitsweise aussagekräftig ist.
- Aufgabentyp
- Benutzerrolle
- Ausgewählter Skill
- Verwendete Context Sources
- Aufgerufene Capabilities
- Reihenfolge der Aufrufe
- Bearbeitungsdauer
- Rückfragen
- Fehler und Wiederholungen
- Freigaben
- Abbrüche
- Qualitätsbewertungen
Ehrliche Einordnung
Texenda sieht nicht jede interne Modellentscheidung eines externen KI-Clients. Analysiert werden die nachweisbaren Interaktionen, die über den zentralen Harness laufen. Eine tiefere Client-Integration kann optional auch finale Ergebnisse und Nutzerbewertungen zurückmelden — das ist eine bewusste Entscheidung, kein Standard.
Sechs Muster, die Texenda erkennt
Jedes Muster führt zu einem Vorschlag — nie zu einer automatischen Änderung.
-
Wiederkehrende Kontextabhängigkeit
Bei 84 % aller Produktlaunch-Briefings werden zusätzlich frühere Kampagnenergebnisse geladen.
VorschlagDiese Datenquelle als verpflichtenden Bestandteil des Context Recipes aufnehmen.
-
Wiederkehrende Capability-Sequenz
- Kampagnenhistorie lesen
- → Zielgruppendaten abrufen
- → Brand Guidelines laden
- → Briefing erstellen
- → Compliance-Prüfung anfordern
VorschlagDiese Sequenz als Playbook-Kandidat speichern.
-
Fehlender Kontext
Agenten fragen regelmäßig nach der aktuellen Produktpositionierung.
VorschlagEine verbindliche Produktquelle zum Skill hinzufügen.
-
Unnötiger Kontext
Eine Quelle wird immer geladen, in erfolgreichen Runs aber fast nie benötigt.
VorschlagQuelle optional machen oder progressiv nachladen — spart Kontextbudget und Kosten.
-
Berechtigungsengpass
Viele Runs scheitern, weil Werkstudenten eine freigegebene Lesesicht nicht besitzen.
VorschlagEine eng begrenzte Read-only-Capability bereitstellen.
-
Prozessvarianten im Vergleich
Team A beginnt mit Marktanalyse, Team B mit der Kampagnenhistorie. Texenda vergleicht Bearbeitungsdauer, Korrekturrate, Qualität und Freigabeaufwand.
VorschlagDie messbar bessere Variante als Standardpfad im Playbook setzen.
Verbesserung, aber kontrolliert
Das ist der wichtigste Satz dieser Seite: Texenda verändert kein produktives Playbook automatisch. Jede Änderung durchläuft denselben fünfstufigen Weg.
- Muster erkennen
Aus aggregierten Runs, nicht aus einem Einzelfall.
- Verbesserung vorschlagen
Mit Begründung, Datengrundlage und erwarteter Wirkung.
- Skill Owner prüft
Eine benannte, verantwortliche Person — kein Automatismus.
- Tests und Rollenmatrix ausführen
Wie in Forge: Was sieht welche Rolle nach der Änderung?
- Neue Version veröffentlichen
Versioniert, dokumentiert, rückrollbar.
Der Prozess wird nicht durch ein autonom lernendes Modell verändert. Er wird durch reale Nutzungsdaten verständlicher — und durch verantwortliche Teams kontrolliert weiterentwickelt.