Experience Orchestration wird meist aus der Perspektive der Unternehmenssysteme gedacht. Ein Kundensignal entsteht, Kontext wird angereichert, eine Entscheidung getroffen, und anschließend eine Experience über Website, App, E-Mail, Messaging, Service oder einen anderen Touchpoint ausgespielt. Moderne Decisioning-Systeme können dabei bereits in Echtzeit entscheiden, welcher Kanal, welcher Content oder welches Angebot für die aktuelle Situation geeignet ist. Adobe beschreibt dieses Zusammenspiel beispielsweise als Verbindung von Journey Orchestration und Real-Time Decisioning: Der Journey-Kontext wird bewertet und an einzelnen Entscheidungspunkten dynamisch Kanal, Content oder Offer ausgewählt. (Quelle: Adobe Experience League 2026)

Die technische Ausgestaltung unterscheidet sich von Plattform zu Plattform. Die Grundannahme ist jedoch weitgehend dieselbe: Am Ende der Steuerungslogik steht ein Frontend oder Touchpoint, über den das Unternehmen mit einem Menschen interagiert.

Genau diese Annahme beginnt mit Consumer Agents brüchig zu werden.

Denn wenn ein Agent im Auftrag von Kund:innen recherchiert, Informationen bewertet oder Funktionen nutzt, muss die passende Experience nicht mehr zwingend über ein für Menschen gestaltetes Interface ausgeliefert werden. Die Journey bleibt relevant. Kontext und Entscheidung bleiben relevant. Aber die Form, in der das Unternehmen seine Informationen und Leistungen bereitstellt, verändert sich.

Für Experience Orchestration entsteht damit eine zusätzliche Aufgabe.

Unter der Orchestrierung liegt weiterhin die Journey

Um diese Veränderung einzuordnen, lohnt sich zunächst der Blick auf die darunterliegende Journey-Logik.

Customer Journey Management entwickelt sich bereits seit einiger Zeit vom Mapping zur aktiven Managementaufgabe. Forrester beschreibt Customer Journeys 2026 entsprechend nicht mehr als statische Artefakte, sondern als Management Operating Systems, die Discovery, Delivery und Measurement miteinander verbinden sollen. Erkenntnisse aus Feedback, Analytics und operativen Daten sollen dadurch nicht in der Journey Map enden, sondern in Entscheidungen und Veränderungen überführt werden. (Quelle: Forrester, Januar 2026)

Auf Shift/CX haben wir diese Entwicklung unter dem Begriff Journey Intelligence weitergeführt. Die Journey Map wird dabei zum Bezugsrahmen, auf dem Signale, Probleme, Geschäftswirkung und Verantwortlichkeiten zusammenlaufen. Entscheidend ist nicht mehr nur, einen Bruch sichtbar zu machen. Relevant wird, wie wichtig dieser Bruch ist, woran gearbeitet werden sollte und wer dafür Verantwortung übernimmt. Journey Intelligence: Von Insights zur Journey Accountability

Bildlich gesprochen entsteht damit zunehmend ein intelligenteres Steuerungscockpit über der Journey:

Wo entstehen Probleme? Welche Kundensituationen sind kritisch? Welche Wirkung haben sie? Wo müssen wir eingreifen?

Experience Orchestration setzt an der nächsten Frage an:

Was soll in dieser konkreten Situation passieren?

Damit verbindet sie den Journey-Kontext mit der operativen Aussteuerung.

Bisher endet diese Entscheidung meist in einem Unternehmens-Touchpoint

Genau hier liegt die bisherige Logik vieler Orchestrierungsansätze.

Ein Ereignis oder Signal verändert den Kontext. Ein Decisioning-System bewertet die verfügbaren Optionen. Anschließend wird beispielsweise ein anderes Angebot ausgespielt, ein Kanal ausgewählt, ein Serviceprozess gestartet oder ein bestimmter Content angezeigt.

Adobe trennt diese Aufgaben in seiner aktuellen Architektur sehr anschaulich: Journey Orchestration verwaltet Ablauf, Timing und Bedingungen, während Decisioning die Eignung und Priorität möglicher Inhalte oder Angebote bewertet. Die Entscheidung kann dabei vom konkreten Ausspielungskanal getrennt werden.

Vereinfacht: Journey-Kontext → Decisioning → Delivery-System → Kund:in

Diese Logik ist bereits wesentlich dynamischer als eine klassische Kampagnenstrecke. Der aktuelle Zustand einer Person kann zum Zeitpunkt einer Entscheidung berücksichtigt werden; Content, Angebot oder Kanal lassen sich entsprechend neu bewerten.

Trotzdem bleibt am Ende meist ein vom Unternehmen kontrollierter Interaktionsraum.

Und genau dort kommt nun die Entwicklung ins Spiel, die wir in unserem jüngsten Beitrag zu Multiexperience Management als bewusste Zuspitzung eine „Art vierte Modalität" genannt haben. Multiexperience Management: Warum AI Search, Conversational Interfaces und Consumer Agents die Kanal-Logik aufbrechen

Consumer Agents als „vierte Modalität": Warum der Begriff nur ein Ausgangspunkt ist

Im Multiexperience-Beitrag haben wir den Begriff bewusst etwas überdehnt.

Im engeren Verständnis bezeichnet eine Interaktionsmodalität die Art der Mensch-Maschine-Interaktion, etwa Sprache, Touch, Tastatur oder visuelle Interaktion. Ein Consumer Agent ist in diesem Sinn natürlich keine weitere Modalität.

Die Zuspitzung hilft trotzdem, weil sie die Radikalität der veränderten Zugriffssituation sichtbar macht.

Ein Mensch benötigt typischerweise ein bedienbares Interface. Ein Consumer Agent benötigt zunächst Informationen, Kontext und gegebenenfalls Funktionen, die er maschinell erschließen kann.

Aus Website → Navigation → Inhalt → Button/Formular → Aktion kann deshalb eine andere Zugriffskette werden: Ziel → strukturierte Information → verfügbare Funktion → Ergebnis

Im Multiexperience-Beitrag haben wir dafür den präziseren Begriff einer agentenvermittelten Delivery-Logik vorgeschlagen. Consumer Agents sind damit nicht einfach der nächste Kanal. Sie verändern die Form, in der ein Unternehmen Teile seiner Experience überhaupt bereitstellen kann.

Für Experience Orchestration ist genau diese Präzisierung entscheidend.

Neben Experience Delivery tritt Capability Delivery

Ein Agent kann weiterhin eine Website wie ein Mensch bedienen. Browserbasierte Agenten können navigieren, Texte auslesen, Buttons anklicken und Formulare ausfüllen.

Aber 2026 entsteht parallel eine andere technische Logik.

Google hat im Februar WebMCP als Early Preview vorgestellt. Websites können damit strukturierte Tools für AI Agents definieren. Ein Agent muss eine Funktion nicht mehr ausschließlich durch die Simulation einer menschlichen Bedienfolge erschließen. Die Website kann explizit beschreiben, welche Funktion vorhanden ist, welche Informationen sie benötigt und wie sie aufzurufen ist. Google nennt unter anderem Flugbuchungen und das Anlegen eines Supporttickets als Beispiele. (Quelle: Google Chrome, Februar 2026)

Im Commerce wird dieselbe Entwicklung noch konkreter. Shopify beschreibt seine im Juni geöffneten Catalog API und Universal Commerce Protocol (UCP) als Infrastruktur für End-to-End-Agentic-Commerce. Die Catalog API stellt Produkte als strukturierte, abfragbare Daten bereit; UCP definiert, wie Agenten mit Händlersystemen von Discovery bis Checkout interagieren können. (Quelle: Shopify, Juni 2026)

OpenAI verfolgt mit dem Agentic Commerce Protocol ebenfalls die Idee, Produktsuche und Commerce-Funktionen stärker direkt in AI-basierte Interaktionen einzubinden. Seit März 2026 können Nutzer:innen Produktanforderungen im Dialog formulieren, Optionen vergleichen und die Auswahl innerhalb von ChatGPT weiter eingrenzen. (Quelle: OpenAI, März 2026)

Die Beispiele stammen vor allem aus Web und Commerce. Das strukturelle Muster geht aber darüber hinaus: Unternehmen stellen nicht nur eine Oberfläche bereit. Sie beginnen, ihre Fähigkeiten explizit für andere Systeme adressierbar zu machen.

Damit erweitert sich Experience Delivery um eine zweite Dimension: Capability Delivery.

Zwei Delivery-Logiken müssen künftig zusammengedacht werden

Für Experience Orchestration ergibt sich daraus eine neue Gegenüberstellung:

Die rechte Seite ersetzt die linke nicht. Menschen werden weiterhin Websites, Apps, Shops oder Service-Portale nutzen. Und auch Agenten können diese Interfaces weiterhin über Browsertechnologien bedienen.

Die Veränderung besteht darin, dass das Human Interface nicht mehr zwingend der einzige Übergabepunkt zwischen Orchestrierungsentscheidung und Experience sein muss.

Das verändert die Aufgabe der Orchestrierung.

Bisher konnte die zentrale Fragestellung lauten: Welche Experience spielen wir in dieser Kundensituation über welchen Touchpoint aus?

Künftig kommt eine zweite hinzu: Welche Informationen und Fähigkeiten stellen wir in dieser Situation für einen maschinellen Intermediär bereit?

Damit muss Orchestration perspektivisch nicht nur Channel, Content oder Offer berücksichtigen. Sie muss auch entscheiden können, welche Capability in welchem Kontext verfügbar sein soll.

Die Journey bleibt, aber der Touchpoint gehört uns nicht mehr zwingend

Diese Entwicklung wird für das Journey Management besonders interessant.

Die Journey verschwindet nicht, nur weil ein Consumer Agent Teile der Interaktion übernimmt. Das menschliche Ziel bleibt schließlich bestehen. Ein Kunde möchte weiterhin einen Flug umbuchen, ein Produkt auswählen, einen Vertrag vergleichen oder ein Serviceproblem lösen.

Was sich verändert, ist der beobachtbare Weg dorthin.

Ein Teil der Recherche kann bereits in AI Search stattfinden. Ein Consumer Agent kann Informationen verschiedener Anbieter vergleichen. Ein Funktionsaufruf kann direkt über ein Protokoll oder eine API erfolgen. Möglicherweise sieht die Person das klassische Unternehmensfrontend während eines Teils dieses Prozesses überhaupt nicht.

Die Journey bleibt damit der Bezugsrahmen, aber der Touchpoint gehört dem Unternehmen nicht mehr zwingend.

Wir haben dieses Problem bereits aus Sicht der Website-Infrastruktur als zweiten Traffic-Typ diskutiert: Neben Menschen greifen zunehmend Software-Systeme auf Inhalte und Funktionen zu. Für Unternehmen entsteht deshalb die Aufgabe, Erreichbarkeit und Nutzbarkeit auch jenseits des sichtbaren Frontends zu gewährleisten. Der zweite Traffic-Typ: Wie Websites 2026 für KI-Agenten lesbar werden müssen

Für Journey Intelligence folgt daraus perspektivisch eine weitere Frage. Wenn wir Journey-Probleme erkennen und daraus Interventionsbedarf ableiten wollen, müssen wir zunehmend auch verstehen, welche agentenvermittelten Interaktionen stattgefunden haben.

Welche Informationen wurden abgefragt? Welche Capability wurde angeboten? Welche Funktion wurde genutzt? Und welches Journey-Ergebnis entstand daraus?

Das wird nicht sofort alle heutigen Journey-Datenmodelle verändern. Aber die bekannte Messlogik aus Visits, Klickpfaden und Channel-Wechseln erklärt einen solchen Verlauf nur noch teilweise.

Experience Orchestration muss den Kontext über das Frontend hinaus denken

Damit bekommt auch der Begriff des Kontexts eine zusätzliche Bedeutung.

In einer klassischen Personalisierungslogik besteht Kontext etwa aus Profilinformationen, Interaktionshistorie, aktuellem Verhalten, Customer Lifetime Value oder einem erkannten Journey-Zustand. Daraus wird entschieden, welcher Content, welches Angebot oder welcher Kanal am besten passt. Adobe beschreibt genau diese kontextbezogene Real-Time-Decisioning-Logik.

Bei einem Consumer Agent tritt zusätzlich dessen Auftrag hinzu.

Der Agent kommt nicht notwendigerweise mit derselben Navigationshistorie, die ein Unternehmen von einem menschlichen Websitebesuch kennt. Dafür kann er möglicherweise expliziter formulieren, was er benötigt: eine Verbindung unter bestimmten Bedingungen, ein Produkt mit konkreten Eigenschaften, eine verfügbare Serviceoption, oder eine Funktion, mit der sich ein bestimmtes Ziel erreichen lässt.

Für Experience Orchestration verschiebt sich damit ein Teil der Steuerung von der Interpretation des Interface-Verhaltens hin zur Interpretation einer expliziteren Aufgabe oder Intention.

Das ist zunächst eine Chance. Ein klar formulierter Auftrag kann mehr Kontext transportieren als mehrere anonyme Klicks.

Er erzeugt aber auch neue Anforderungen: Die dahinterliegenden Informationen müssen konsistent sein, Fähigkeiten klar beschrieben werden und die jeweiligen Systeme müssen wissen, welche Funktionen in welchem Kontext überhaupt angeboten werden dürfen.

Von agent-readable zu agent-interactable

Im Multiexperience-Beitrag haben wir die Entwicklung in drei Stufen eingeordnet: agent-readable → agent-interactable → agent-actionable

Diese Unterscheidung hilft auch für Experience Orchestration.

Auf der ersten Ebene sorgt das Unternehmen dafür, dass Informationen maschinell auffindbar und interpretierbar sind.

Auf der zweiten Ebene werden zusätzlich Funktionen verfügbar. Genau hier beginnt die Orchestrierungsfrage interessant zu werden: Welche Funktion passt zur aktuellen Situation? Welcher Kontext muss übergeben werden? Welche Alternative soll angeboten werden?

Die dritte Stufe geht darüber hinaus. Agent-actionable bedeutet, dass ein Agent nicht nur eine Funktion erkennen kann, sondern innerhalb eines eingeräumten Handlungsspielraums selbst entscheidet und die Aktion im Auftrag seiner Nutzer:innen ausführt.

An dieser Grenze verändert sich der Gegenstand erneut.

Dann geht es nicht mehr allein um Experience und Capability Delivery. Es geht um Delegation, Berechtigungen und Entscheidungsrechte.

Und genau dort beginnt die Diskussion um Agentic Experience.

Was sich damit für Experience Orchestration konkret verändert

Aus unserer Sicht lassen sich für die Orchestrierungsaufgabe fünf Konsequenzen ableiten:

1. Orchestration muss zwei Delivery-Kontexte berücksichtigen. Eine relevante Experience kann über ein Human Interface oder über einen agentenvermittelten Zugang bereitgestellt werden.
2. Content reicht als Aussteuerungsobjekt nicht mehr aus. Neben Content, Angebot und Kanal werden verfügbare Funktionen und Fähigkeiten zu einem möglichen Bestandteil des Decisionings.
3. Journey-Kontext muss von der Oberfläche entkoppelt werden. Eine relevante Kundensituation sollte nicht nur über einen bekannten Klickpfad erkannt werden können. Agentenvermittelte Anfragen können andere Signale und explizitere Intentionen liefern.
4. Delivery benötigt neue technische Anschlussfähigkeit. WebMCP, MCP, UCP, APIs und andere entstehende Protokolle zeigen unterschiedliche Wege, Informationen und Funktionen maschinenadressierbar bereitzustellen. Welche Standards sich durchsetzen, ist Anfang Juli 2026 noch offen.
5. Orchestration und Governance rücken näher zusammen. Spätestens wenn nicht nur Information, sondern eine ausführbare Funktion bereitgestellt wird, muss geklärt sein, wer oder was darauf zugreifen darf und welche Bedingungen gelten.

Darin liegt für uns die eigentliche Erweiterung gegenüber der klassischen Frontend-Aussteuerung.

Der Martech Stack muss deshalb nicht nur integrierter, sondern nach außen anschlussfähig werden

Diese Entwicklung passt zu einer Verschiebung, die wir bereits in unserer Analyse des Martech Stacks beschrieben haben.

Experience Orchestration setzt strukturierte Inhalte, einen belastbaren Datenkontext und signalbasierte Steuerungslogiken voraus. Das bleibt unverändert. Martech im Wandel, Teil 2: Warum Experience Orchestration scheitert — und was Unternehmen jetzt aufbauen müssen

Consumer Agents ergänzen allerdings eine neue Richtung.

Bislang denken wir Integration überwiegend nach innen: Daten aus Marketing, Service, Commerce und Customer Journey Management müssen zusammengeführt werden, damit eine konsistente Entscheidung möglich wird.

Agentenvermittelte Delivery verlangt zusätzlich Anschlussfähigkeit nach außen.

Informationen und Fähigkeiten müssen so bereitgestellt werden, dass auch ein System darauf zugreifen kann, das nicht Teil des eigenen Martech Stacks ist und nicht den Zielen des Unternehmens folgt.

Genau darin unterscheidet sich ein Agent of the Customer von einem unternehmensseitigen Marketing- oder Service-Agenten. Wie wir in unserer Einordnung der drei Agenten-Domains gezeigt haben, steht ein Consumer Agent außerhalb der direkten Steuerung des Marketers und vertritt zunächst die Ziele seiner Nutzer:innen. KI-Agenten im Martech Stack: Die drei Domains — wem sie gehören und was das für CX bedeutet

Experience Orchestration muss deshalb zunehmend mit einem Gegenüber umgehen, dessen Entscheidungslogik das Unternehmen nicht selbst kontrolliert.

Das ist neu.

Fazit: Orchestration endet künftig nicht zwingend am eigenen Frontend

Experience Orchestration bleibt zunächst eine bekannte Aufgabe: Kundensignale und Journey-Kontext müssen in eine Entscheidung übersetzt werden, die anschließend eine sinnvolle Interaktion ermöglicht.

Was sich 2026 verändert, ist die mögliche Delivery-Seite dieser Entscheidung.

Bisher war die Aussteuerung meist auf unternehmenseigene oder zumindest vom Unternehmen kontrollierte Touchpoints ausgerichtet. Website, App, Messaging, E-Mail und Service blieben die Orte, an denen die Experience konkret wurde.

Consumer Agents erweitern diese Logik.

Wie wir im Multiexperience-Beitrag bewusst zugespitzt haben, wirken sie zunächst wie eine Art vierte Modalität. Fachlich präziser handelt es sich um eine agentenvermittelte Delivery-Logik: Informationen und Funktionen müssen teilweise nicht mehr für ein menschliches Interface aufbereitet, sondern für einen maschinellen Intermediär adressierbar werden.

Damit erweitert sich auch die Leitfrage von Experience Orchestration.

Nicht mehr nur: Was sollen wir dieser Kundin oder diesem Kunden jetzt über welchen Touchpoint ausspielen?

Sondern zusätzlich: Welche Information oder Fähigkeit müssen wir in dieser Kundensituation einem Agenten verfügbar machen?

Die Journey bleibt dafür der Bezugsrahmen. Sie hilft uns zu verstehen, welches Ziel verfolgt wird, wo Probleme entstehen und an welcher Stelle eine Intervention sinnvoll ist.

Aber der Touchpoint gehört uns nicht mehr zwingend.

Und genau deshalb müssen Journey Management, Decisioning und Delivery künftig enger zusammengedacht werden.

Solange ein Agent Informationen abruft und Funktionen vermittelt, befinden wir uns noch in dieser erweiterten Orchestrierungs- und Multiexperience-Logik. Sobald er selbst auswählen, entscheiden und verbindlich handeln darf, kommt eine weitere Ebene hinzu.

Dann sprechen wir über Agentic Experience, und über die Frage, wie Handlungskompetenz zwischen Unternehmen, Menschen und Software-Agenten neu verteilt wird.