Empty States als Conversion-Hebel im Storefront 2026Empty States sind keine Randfalle. Sie sind syst…
VTEX Vision 2026: Was die Storefront jetzt rendern muss
VTEX Vision 2026: Was die Storefront jetzt rendern muss
VTEX Vision hat im April 2026 vier native AI-Agents in den Commerce-Stack geschrieben: Catalog, Promotions, Data Insights und Search Optimisation. Der Agent Marketplace ist angekündigt. Im Enterprise-Rollout bei Decathlon, Whirlpool und Amo Beleza taucht jetzt eine Frage auf, die kein Agent selbst beantwortet: Wer rendert deren Output?
Vier Agents im Backend, drei Anforderungen am Frontend. Dieser Post schlüsselt auf, was das konkret bedeutet, bevor eure Storefront in den Agent-Betrieb geht.
Anforderung 1: Catalog-Agent, Soft-Realtime-Updates und das Cache-Burn-Problem
Der Catalog-Agent verändert Produkt-Texte live. Er optimiert Beschreibungen, justiert Attribute, schreibt Titel nach Suchsignal. Wenn eure Storefront auf klassisches Full-Cache mit langen TTLs oder manuell getriegenem Cache-Invalidation ausgelegt ist, entsteht ein struktureller Bruch: Der Agent ändert das Backend, die Storefront zeigt noch die alte Version.
Das klassische Werkzeug ist ISR on Demand (Incremental Static Regeneration mit Webhook-Trigger) oder SWR (Stale-While-Revalidate) auf Komponentenebene. Beides funktioniert, aber keins davon ist in FastStore oder VTEX IO ab Werk auf Agent-Output-Bursts ausgelegt. FastStore verwendet eine statische Build-Pipeline mit manuellem Revalidation-Hook. Wenn der Catalog-Agent 200 Produktseiten in einem Lauf aktualisiert, bedeutet das 200 ISR-Trigger in kurzer Zeit. Das ist kein Edge-Case, das ist Agent-Normalbetrieb.
Die Anforderung an die Storefront-Architektur ist konkret: Component-Level-Revalidation, nicht Page-Level. Produkttitel und Beschreibung als separate Fetch-Einheiten mit kurzer TTL, losgelöst vom Rest der Page-Build-Pipeline. Wer das Frontend vom Backend-Build-Zyklus entkoppelt hat, kann diesen Kanal granular konfigurieren. Wer noch in einem monolithischen Build steckt, baut den Cache-Burn-Mechanismus manuell nach.
Mehr zur Decoupling-Architektur in unserem Headless Frontend for VTEX Pillar-Hub.
Anforderung 2: Promotions-Agent, serverseitige Slots und Segment-Logik
Der Promotions-Agent dreht Conditional-Content pro Kundensegment. Er entscheidet, welche Aktionen welchen Nutzergruppen gezeigt werden, und das nicht als einmaliger Konfigurationsschritt, sondern kontinuierlich während der Kampagnenlaufzeit.
Das klassische Render-Muster bei VTEX-Storefronts ist entweder vollständig clientseitig (JavaScript nach Page-Load prüft Segment, tauscht Inhalte aus) oder vollständig statisch (eine Page pro Segment, manuell gepflegt). Beides hat Probleme. Clientseitig bedeutet Layout-Shift und LCP-Regression, weil der Segment-Check nach dem ersten Paint passiert. Statisch bedeutet n-fache Pflege, und der Promotions-Agent könnte diese Logik täglich verändern.
Die architektonisch saubere Antwort ist serverseitig gerenderte Personalisierungs-Slots: Der Render-Layer kennt das Segment zum Request-Zeitpunkt (via Cookie, JWT oder Edge-Middleware) und wählt den passenden Content-Block, bevor HTML ausgeliefert wird. Das Segment-Routing passiert am Server oder am Edge, nicht im Browser.
In einem entkoppelten Frontend-Layer ist das ein Middleware-Slot in der Request-Pipeline, kein Backend-Deployment. Ihr konfiguriert den Slot, der Promotions-Agent befüllt ihn, die Storefront rendert das Ergebnis. Der Agent braucht keine Kenntnis von der Storefront-Architektur, die Storefront braucht keine Kenntnis der Agent-Logik. Entkopplung als Voraussetzung, nicht als Bonus.
Der Composable Headless Frontend beschreibt, wie der Layer-Schnitt dabei konkret aussieht.
Anforderung 3: Search-Optimisation-Agent und Facet-State-Toleranz
Der Search-Optimisation-Agent pflegt Auto-Synonyme und Boosting-Regeln. Er verändert, was ein Suchbegriff zurückliefert, auch ohne dass jemand manuell in den Suchindex eingreift. Das ist aus Backend-Sicht sauber. Aus Storefront-Sicht entsteht ein subtiles Problem mit dem Facet-State.
Wenn ein Nutzer eine Suche mit aktiven Facets aus einem Lesezeichen oder einer URL aufruft, und der Agent hat zwischenzeitlich die Boosting-Regeln verändert, kann der Facet-State zu einer Ergebnismenge passen, die nicht mehr existiert. Die Storefront muss in diesem Fall graceful degraden: leere Facets entfernen, reduzierte Ergebnismenge ohne harten Fehler anzeigen, Fallback-State sauber rendern.
Das ist kein hypothetisches Problem. Es ist das gleiche Problem, das entsteht, wenn ein Out-of-Stock-Event einen Facet-State obsolet macht, nur dass es jetzt durch einen Agent systematisch und häufiger ausgelöst wird. Storefronts, die auf stabilen Facet-States gebaut wurden, brauchen eine explizite Toleranzschicht: Facet-Validity-Check vor Render, Soft-Reset bei leerem Result-Set.
Der Data-Insights-Agent liefert dabei keine Storefront-Inputs direkt. Er erzeugt Natural-Language-Reports und Segment-Analysen, die als Trigger für die Promotions-Logik dienen. Die Kette ist: Insights-Agent analysiert Nutzerverhalten, Promotions-Agent justiert Conditional-Content auf Basis der Analyse, Storefront rendert das Ergebnis. Das Frontend sieht nur den letzten Schritt.
Component-Resolver: Agent-Output als Render-Input
Hier ist ein TypeScript-Snippet, das zeigt, wie ein Component-Resolver Agent-Output-Typen auf Frontend-Render-Pfade abbildet. Das ist kein Pseudo-Code, sondern ein Ausgangspunkt für eine reale Integration.
type AgentOutputType =
| "catalog_update"
| "promotion_segment"
| "search_boost"
| "insights_trigger";
interface AgentOutputSlot {
type: AgentOutputType;
payload: Record<string, unknown>;
segment?: string;
ttl?: number;
}
async function resolveAgentSlot(
slot: AgentOutputSlot,
context: { segmentId: string; locale: string }
): Promise<React.ComponentType | null> {
switch (slot.type) {
case "catalog_update":
return (await import("@/components/ProductContent")).default;
case "promotion_segment":
if (slot.segment !== context.segmentId) return null;
return (await import("@/components/PromotionSlot")).default;
case "search_boost":
return (await import("@/components/FacetLayer")).default;
default:
return null;
}
}Der Resolver trennt drei Verantwortlichkeiten sauber: Welcher Agent-Output-Typ liegt vor, passt das Segment zum aktuellen Nutzerkontext, welche Komponente rendert das Ergebnis. Die TTL-Steuerung (im AgentOutputSlot) ist der Hebel, der bestimmt, wie lange der Output gecacht wird, bevor eine neue Revalidation ausgelöst wird.
Im Rahmen einer Agentic Frontend Management Platform ist dieser Resolver-Layer konfigurierbar, ohne dass Engineering jedes Mal einen Build startet.
Frontend-Entkopplung als Voraussetzung, nicht als Option
Wer VTEX Vision ernst nimmt, muss die Render-Architektur ernst nehmen. Vier Agents im Backend bedeuten nicht automatisch vier zusätzliche Aufgaben am Frontend. Aber sie bedeuten, dass das Frontend auf asynchrone, kontinuierliche Zustandsveränderungen ausgelegt sein muss.
FastStore ist ein solides Jamstack-Toolkit. Sein Kern ist eine statische Build-Pipeline mit CMS-First-Architektur. Das ist für redaktionelle Inhalte mit manueller Pflegerate gut designed. Für Agent-Output-Bursts mit kurzen TTLs und serverseitiger Segment-Logik braucht es eine entkoppelte Render-Schicht oben drauf.
Die Performance-Seite ist dabei nicht zu unterschätzen: LCP-Regression durch clientseitiges Segment-Rendering, Core-Web-Vitals-Stalls durch unbehandelten Facet-State, Cache-Burn-Overhead durch Page-Level-ISR statt Component-Level-Revalidation. Diese Probleme sind lösbar. Aber sie sind einfacher zu lösen, wenn die Architektur von Beginn an auf Entkopplung ausgelegt ist.
Mehr zur Performance-Seite in unserem Performance und Core Web Vitals Produkt-Hub.
Wenn ihr VTEX als Backend behaltet und die Render-Schicht modernisieren wollt: Demo-Slot buchen. Wir zeigen euch, wie der Component-Resolver und die Agent-Output-Slots in einer laufenden VTEX-Integration aussehen.
Weiterlesen: