Wenn Agents Live-Storefronts schreiben: Das Orchestrierungs-Layer als Change-Provenance-Instanz

Es gibt einen Moment im Lifecycle eines Composable-Commerce-Systems, der architektonisch alles verändert. Nicht den Moment, in dem der erste Agent eine Seite liest. Sondern den Moment, in dem er anfängt, sie zu schreiben.

Genau da sind wir gerade. Und die Frage, die danach sofort auftaucht, ist keine UX-Frage und keine Performance-Frage. Sie ist eine Governance-Frage: Wer hat was verändert, wann, und warum?

Von lesenden zu schreibenden Agents

Die erste Welle der KI-Integration in Commerce-Stacks war passiv. LLMs haben Storefronts gelesen, Produkt-Attribute analysiert, SEO-Empfehlungen generiert, A/B-Test-Hypothesen formuliert. Der Stack selbst blieb unangetastet, der Mensch hat die Aktion ausgeführt.

Das verschiebt sich. Zwei konkrete Entwicklungen aus dem Juni 2026 zeigen, wo die Reise hingeht.

Uniform hat in seinem Release vom 4. Juni 2026 berichtet, dass der Uniform MCP-Server verbessert wurde, um A/B-Tests und Personalisierungen auf Kompositionen direkt anzulegen - laut Changelog ist Scout, Uniforms Agentic-AI-Partner, jetzt "better at creating A/B tests and personalizations on compositions". Die Agentic-Authoring-Fähigkeiten, die vorher manuelles Eingreifen erforderten, sind ein Stück weiter Richtung vollautomatischer Ausführung gegangen.

Webflow hat auf seiner Plattform, laut öffentlicher Dokumentation zu Workspace Audit Logs, Infrastruktur eingeführt, die Change-Einträge mit dem ausführenden Akteur verknüpft. Enterprise-Kunden können über die Workspace Audit Log API nachvollziehen, welche Aktion durch einen menschlichen Nutzer, durch Webflow AI oder durch ein MCP-verbundenes Tool ausgelöst wurde. Der Log-Eintrag trägt den Akteur-Typ - kein Freitext, sondern strukturiertes Attribut.

Das sind zwei verschiedene Systeme, aber ein gemeinsames Signal: das Authoring-Paradigma wechselt. Agents schreiben nicht mehr nur Empfehlungen, sie schreiben Kompositionen, A/B-Tests, Content-Varianten. Das Frontend-Layer ist der Ort, an dem diese Writes ankommen.

Was sich ändert, wenn der Schreiber ein Agent ist

Bevor dieser Punkt architektonisch durchdacht wird, lohnt sich ein kurzer Blick darauf, was sich konzeptionell verschiebt.

Wenn ein Mensch eine Landingpage ändert, gibt es implizite Kontext-Träger: der Mensch weiß, warum er die Änderung gemacht hat. Er kann es erklären. Er erinnert sich an den Business-Anlass, das A/B-Test-Ziel, die Kundenanfrage, die den Change ausgelöst hat. Dieses Wissen existiert außerhalb des Systems, im Kopf der Person.

Wenn ein Agent eine Komposition ändert, existiert dieser implizite Kontext nicht außerhalb des Systems. Der Agent weiß zur Ausführungszeit, warum er die Änderung ausführt (er hat einen Tool-Call mit Parametern und ggf. einem Prompt-Context erhalten). Aber sobald der Schreibvorgang abgeschlossen ist, ist dieser Kontext flüchtiger als das menschliche Gedächtnis.

Das ist der Kern der Change-Provenance-Herausforderung: nicht zu wissen, was geändert wurde (das wissen Datenbanken sehr gut), sondern zu wissen, welcher Entscheidungspfad zur Änderung geführt hat und wer oder was ihn gegangen ist.

Das Orchestrierungs-Layer als natürliche Audit-Instanz

Das Konzept des Orchestrierungs-Layers ist in der FMP-Architektur (Frontend Management Platform) nicht neu. Es ist die Schicht zwischen dem Backend-Daten-Layer und dem Render-Output, die entscheidet, welche Komposition in welchem Kontext zu welcher User-Session ausgeliefert wird.

Was sich verändert: dieses Layer ist jetzt nicht mehr nur ein Routing-Layer. Es ist die Stelle, an der Agent-Write-Operationen eintreffen, bevor sie den Live-Zustand beeinflussen.

Das macht es zur natürlichen Kontroll-Instanz. Nicht weil es Agents blockieren soll, sondern weil es der einzige Punkt im Stack ist, an dem alle relevanten Kontexte verfügbar sind:

• Der Agent, der die Änderung angefragt hat (Tool-Call-Herkunft, MCP-Client-ID)
• Die Änderung selbst (welcher Slot, welche Komponenten-Variante, welcher A/B-Test-Parameter)
• Der Business-Kontext, in dem die Änderung ausgelöst wurde (Personas, Segment, Release-Stage)
• Der Zeitpunkt und der aktuelle Live-State, bevor die Änderung angewendet wird

Wenn diese vier Kontexte im Orchestrierungs-Layer zusammentreffen, kann ein strukturierter Change-Provenance-Log geschrieben werden. Ein Log, der nicht nur "was wurde geändert" dokumentiert, sondern "durch wen, auf Basis welches Kontexts, in welchem Zustand".

Konzept-Diagramm: Agent-Write-Flow mit Audit-Trail

+---------------------------+
|   AI Agent / MCP-Client   |
|  (Scout, Custom Agent, ..)| 
+-----------+---------------+
            |
            |  write-intent: { slot, variant, reason, agent_id }
            v
+---------------------------+     +---------------------------+
|  Orchestrierungs-Layer    |---->|  Change-Provenance-Log    |
|  (FMP Runtime)            |     |  { ts, actor_type,        |
|                           |     |    agent_id, slot,        |
|  - Validierung            |     |    variant_id, reason,    |
|  - Policy-Check           |     |    prior_state,           |
|  - Provenance-Capture     |     |    session_ctx }          |
+-----------+---------------+     +---------------------------+
            |
            |  approved write
            v
+---------------------------+
|  Live Storefront State    |
|  (Komposition, A/B-Test,  |
|   Content-Variante)       |
+---------------------------+

Jeder Schritt hat einen definierten Ort. Der Agent kommuniziert sein Write-Intent mit strukturiertem Payload. Das Orchestrierungs-Layer validiert, prüft gegen Policy (darf dieser Agent diesen Slot schreiben?), erfasst den Provenance-Kontext und schreibt den Log-Eintrag, bevor der Change angewendet wird. Der Live-State ist das Ergebnis nach dem Commit.

Der Log-Eintrag ist nicht nachträglich. Er entsteht vor dem Commit, weil zum Commit-Zeitpunkt alle relevanten Metadaten verfügbar sind.

Warum das im klassischen CMS-Modell nicht funktioniert

Ein klassisches CMS löst diese Anforderung strukturell nicht, weil es für menschliche Autoren gebaut wurde. Änderungen kommen von einem eingeloggten User, der seinen Namen, seine Session und seine Permissions mitbringt. Das reicht für den Human-Authoring-Fall vollständig.

Wenn ein Agent via API oder MCP-Tool in dasselbe System schreibt, gibt es zwei schlechte Alternativen:

Option A: Der Agent benutzt einen Service-Account. Alle Änderungen erscheinen unter einem generischen User-Namen ("API-Bot" oder ähnlich). Wer später den Change-Log liest, sieht, dass etwas geändert wurde, aber nicht, welcher Agent-Typ, welche Ausführungs-Instanz, welcher Prompt-Kontext dahinter steht.

Option B: Das CMS bekommt neue Felder für Agent-Metadaten. Das funktioniert technisch, ist aber eine CMS-seitige Erweiterung, die bei jedem Deployment neu konfiguriert werden muss und keinen Standard-Pfad hat.

Keine der beiden Optionen gibt dir das, was ein Agentic-Commerce-System braucht: eine auditierbare, strukturierte, semantisch reiche Aufzeichnung jedes Writes mit vollständigem Kontext.

Das Orchestrierungs-Layer kann das liefern, weil es architektonisch zwischen dem Agenten und dem State sitzt und beide Seiten sieht.

Was das für die Architektur bedeutet

Wenn du heute einen Composable-Commerce-Stack baust oder bewertest, ist die relevante Frage nicht mehr nur "wie integriere ich Agents", sondern: "hat mein Frontend-Layer eine definierte Schicht, die Agent-Writes empfängt, bevor sie den Live-State beeinflussen?"

Wenn die Antwort nein ist, und Agents schreiben direkt via CMS-API oder Backend-Mutation in den Live-State, hast du kein Change-Provenance-Problem heute. Aber du hast es in dem Moment, in dem der erste fehlerhafte Agent-Write auf einer Live-Seite landet und du in deinem Audit-Log nicht findest, wer ihn ausgelöst hat, mit welchem Kontext, und wie du ihn rollbackst.

Drei konkrete Anforderungen an das Orchestrierungs-Layer für den Agentic-Commerce-Kontext:

Strukturiertes Actor-Modell. Nicht nur "User" vs. "API", sondern: Agent-Typ, Agent-ID, aufrufender MCP-Client, Policy-Scope. Das ist die Grundlage für semantisch auswertbare Logs.

Write-Intent vor Write-Commit. Der Provenance-Log-Eintrag entsteht vor dem Commit, nicht danach. Weil Prior-State nur vor dem Commit zuverlässig erfasst werden kann.

Policy-Layer für Agent-Writes. Welche Slots darf welcher Agent-Typ schreiben? Welche Komponenten-Kategorien sind für vollautomatische Writes freigegeben, welche erfordern Human-in-the-Loop-Confirmation? Dieser Policy-Layer muss im Orchestrierungs-Layer konfigurierbar sein, nicht im einzelnen Agent.

Keine neue Kategorie, sondern eine neue Anforderung an eine bestehende

Es ist verlockend, "Change Provenance für Agentic Commerce" als neue Produktkategorie oder neues Buzzword zu rahmen. Das wäre ungenau.

Was sich verändert, ist eine Anforderung an das Orchestrierungs-Layer, das in einer FMP-Architektur ohnehin vorhanden ist. Dieses Layer hat schon immer entschieden, welche Komposition ausgeliefert wird. Jetzt muss es zusätzlich dokumentieren, wer die Komposition auf welchem Weg angelegt hat.

Das ist eine Erweiterung, keine Neuerfindung. Aber es ist eine Erweiterung, die in vielen bestehenden FMP-Implementierungen noch nicht explizit gebaut ist. Weil sie bis vor kurzem nicht nötig war: Agents haben gelesen, Menschen haben geschrieben.

Das ändert sich gerade. Und der richtige Zeitpunkt, das Orchestrierungs-Layer für diese Anforderung zu konfigurieren, ist vor dem ersten Agent-Write auf einer Live-Seite, nicht danach.

Dieser Post ist Teil 3 des FMP-Orchestrierungs-Clusters. Relevante Vorarbeiten:

• Vom API-Gateway zum AI-Agent-Layer: BFF-Evolution 2026 - wie der BFF-Layer zum Agent-Interface wird (23.05.2026)
• LLM Buyer-Agents und Storefront-Engineering-Patterns 2026 - Agent-seitige Anforderungen an den Storefront-Layer (25.05.2026)
• Agentic Commerce - die Plattform-Schicht - Laioutrs Positionierung als Agentic FMP
• Composable DXP und Orchestrierung - Backend-agnostische Kompositions-Architektur
• Editor und Runtime - wie Editor-State und Live-State zusammengeführt werden