Der Agentic-Commerce-Verkaufskanal in Shopware 6.7

„Agentic Commerce" beschreibt den Fall, dass nicht ein Mensch im Shop einkauft, sondern ein KI-System in seinem Auftrag — Produkte findet, vergleicht und im Zweifel bestellt. Für Shopbetreiber ist die interessante Frage nicht, ob das kommt, sondern was das eigene System dafür heute schon mitbringt.

Wir haben in einer laufenden Shopware-6.7.13.1-Installation nachgesehen. Das Ergebnis ist konkreter, als die Diskussion darüber vermuten lässt — und es enthält einen Hinweis, den man kennen sollte, bevor man darauf aufbaut.

Was im Kern angelegt ist

Drei Migrationen im Verzeichnis V6_7 beschäftigen sich damit:

Der Verkaufskanaltyp hat eine feste Kennung in Defaults:

public const SALES_CHANNEL_TYPE_AGENTIC_COMMERCE = '5e29f9890c4d4d519a1c7f9d5c24b7c1';

Und wird mit diesen Angaben eingetragen:

Dass es eine dritte Migration gibt, die Konfiguration aus einer Erweiterung in den Kern überführt, ist der eigentlich interessante Teil: Die Funktion begann als Erweiterung und ist in 6.7 in den Kern gewandert.

Der Feed-Validator und seine Pflichtfelder

Der praktisch relevanteste Teil sitzt nicht im Verkaufskanal, sondern im Produktexport. Shopware bringt in 6.7 einen Validator mit, der einen Feed gegen die Anforderungen einer KI-Einkaufsplattform prüft — technischer Name open-ai.

Das Format ist JSONL: eine Zeile je Produkt, jede Zeile ein eigenständiges JSON-Objekt. Ein eigener Parser liest zeilenweise und meldet bei einem Formatfehler die Zeilennummer, statt den ganzen Feed abzulehnen.

Geprüft wird je Zeile:

Für die Verfügbarkeit sind genau vier Werte zugelassen:

in_stock   out_of_stock   backorder   pre_order

Vier Beobachtungen dazu, die im Projekt Zeit sparen:

return_policy ist eine URL, kein Text. Wer dort einen Freitext liefert, fällt durch die Prüfung. Es braucht eine erreichbare Seite mit der Rückgaberegelung.

seller_name und seller_url sind Pflicht. Die Plattform will wissen, bei wem gekauft wird — nicht nur, welches Produkt es ist. Für Marktplätze und Mehrmandantenaufbauten ist das die Stelle, an der Modellierungsfragen auftauchen.

is_eligible_search und is_eligible_checkout sind getrennt. Ein Produkt darf gefunden werden, ohne kaufbar zu sein. Das ist ein bewusster Freiheitsgrad und sollte nicht pauschal auf „wahr" gesetzt werden.

item_id muss über den ganzen Feed eindeutig sein. Bei Varianten ist das der Punkt, an dem selbstgebaute Exporte typischerweise brechen — zusammen mit group_id, das bei Varianten Pflicht wird.

Der Hinweis, den man kennen sollte

Im Quelltext des Validators steht:

/**
 * @deprecated tag:v6.8.0 - Will be removed and is going to be part of SwagAgenticCommerce
 */

Und die Methode, die den technischen Namen liefert, prüft ein Feature-Flag:

if (!Feature::isActive('v6.8.0.0')) {
    Feature::triggerDeprecationOrThrow(…);
}
return 'open-ai';

Zusammengefasst: Die Funktion ist in 6.7 im Kern, hängt an einem Feature-Flag und wandert in 6.8 in eine eigene Erweiterung. Das ist kein Grund, sie zu ignorieren — aber ein Grund, nicht fest gegen die Kernklassen zu bauen. Wer heute eine Integration schreibt, sollte den Feedaufbau von der Herkunft des Validators trennen, damit ein Umzug in eine Erweiterung nur eine Anpassung an einer Stelle bedeutet.

Was das praktisch bedeutet

Der Feed ist die eigentliche Arbeit, nicht der Verkaufskanal. Den Kanal anzulegen dauert Minuten. Einen Feed zu liefern, der die Prüfung besteht, setzt saubere Produktdaten voraus: vollständige Beschreibungen, gepflegte Marken, erreichbare Bilder, korrekte Verfügbarkeiten und eine Rückgaberegelung als eigene Seite.

Die Anforderungen sind streng, aber sinnvoll. Fast jede Prüfung entspricht einer Angabe, die ein Käufer sehen möchte, bevor er entscheidet. Ein Feed, der diese Prüfung besteht, ist auch für andere Kanäle besser.

Und der Zeitpunkt ist unbequem. Zwischen „im Kern vorhanden" und „stabil an einer Stelle" liegt in diesem Fall eine Hauptversion. Wer heute investiert, investiert in die Datenqualität — die bleibt, egal wo der Validator am Ende wohnt.

Woher diese Angaben stammen

Aus dem Quelltext einer laufenden 6.7.13.1-Installation, nicht aus einer Ankündigung. Wir betreiben mehrere Shopware-Runtimes nebeneinander, um Erweiterungen über Versionswechsel zu prüfen; solche Befunde fallen dabei ab. Ein anderer aus derselben Arbeit betrifft das Routing: wenn der Shopware-Kern eine Plugin-Route verdrängt.

Wenn Sie prüfen möchten, wie weit Ihre Produktdaten von den Anforderungen oben entfernt sind: Die Feldliste ist eine brauchbare Checkliste, auch ohne Verkaufskanal. Den Rahmen für Sichtbarkeit in KI-Systemen beschreibt GEO & KI-Optimierung, die technische Umsetzung im Shop Shopware-Agentur.