Agency Transfer via Mandate

Ausgangsfrage: Der Kunde hat ein Ziel, aber die Journey hängt stark an seinen Constraints. Fallen die weg, oder übernimmt ein Agent sie, ändert sich das Bild grundlegend.

Bisheriger Mechanismus (Capability mitigates Constraint)

Capability K → mitigates → Constraint C → necessity(G) ↓ → Events verschwinden

Neuer Mechanismus: Agency Transfer

Actor A1 (Customer) grants Mandate M to Actor A2 (Agent)
→ Mandate M authorizes A2 to execute E1…En
→ Events bleiben bestehen, aber der ausführende Actor wechselt von A1 zu A2

Unterschied: Der Constraint verschwindet nicht aus der Welt — ein Formular bleibt ein Formular — sondern der Actor, der ihn bearbeiten muss, wechselt. Journey Structure ändert sich durch Delegation, nicht Elimination.

Konsequenz für die Journey-Semantik: Die vom Kunden erlebte Journey schrumpft auf grant Mandate → monitor/intervene → receive Outcome. Die delegierten Events laufen weiter, aber als Agent Execution Trace — kein Customer-Journey-Objekt mehr im engeren Sinn, sondern ein Ausführungsprotokoll unter Mandat, näher an Process Mining.

Voraussetzung ist nicht dieselbe wie bei Capability-Mitigation: nicht technologischer Fortschritt allein, sondern Trust als Actor-Actor-State und institutionelle Mandatsfähigkeit. In regulierten Kontexten (Banking: KYC, Signaturpflicht) ist diese Mandatsfähigkeit selbst oft ein Constraint, der Agency Transfer blockiert — dort verlagert sich die Reibung auf die Mandatsgrenze selbst als neuen Pain-Point-Typ.

Verhältnis zu H1–H3: Agency Transfer ist keine vierte Stufe, sondern eine zweite Achse — er beschreibt einen Wechsel des ausführenden Actors bei unverändertem Constraint, kann H1–H3 überlagern.

Neue View: Agent Execution Trace

Für Tooling-Zwecke: klassische Journey-Notation (Touchpoints, Sender/Empfänger/Kanal) bleibt für den weiterhin menschlich erlebten Teil richtig, ist aber für delegierte Ausführungsstrecken der falsche Darstellungs-Zielraum.