muench.dev Articles

mage-remote-run mit JSON Body Support und anderen neuen Features

2026-06-25T07:00:00+00:00

Zwei Releases an einem Tag - das passiert, wenn Features bereit sind. Am 17. Juni 2026 haben ich v1.9.0 und v1.10.0 von mage-remote-run veröffentlicht. Das Highlight in v1.9: Virtual Commands unterstützen jetzt JSON Request Bodies — POST- und PUT-Requests gegen die Magento REST API sind damit ohne eigenen JavaScript-Code möglich. v1.10 bringt eine sauberere Plugin-Infrastruktur: Inkompatible Plugins werden jetzt beim Laden erkannt und mit klarer Fehlermeldung abgewiesen.

v1.9.0: Virtual Commands mit JSON Body, Choices und interaktiven Prompts

Virtual Commands sind seit v1.4 ein zentrales Erweiterungs-Feature: REST-Requests per Konfiguration definieren, ohne JavaScript schreiben zu müssen. Bisher waren sie auf GET-Requests beschränkt. Das ist jetzt Geschichte.

JSON Body Templates

Mit body in der Command-Definition lassen sich POST- und PUT-Requests direkt aus der Konfiguration absetzen. Der Body ist ein JSON-Template. Optionen werden als Platzhalter eingebettet und zur Laufzeit ersetzt.

{
  "name": "customer update-email",
  "method": "PUT",
  "endpoint": "/V1/customers/:id",
  "description": "Update customer email address",
  "body": {
    "customer": {
      "id": ":id",
      "email": ":email"
    }
  },
  "options": {
    "id": {
      "type": "string",
      "required": true,
      "description": "Customer ID"
    },
    "email": {
      "type": "string",
      "required": true,
      "description": "New email address"
    }
  }
}

mage-remote-run customer update-email --id 42 --email new@example.com

Damit öffnet sich die gesamte Magento REST API für Virtual Commands und eben nicht nur lesende Operationen, sondern auch schreibende Workflows, ohne eigenen Plugin-Code.

Die vollständige Dokumentation dazu findet ihr unter: mage-remote-run.muench.dev/extensibility/virtual-commands

Choices für Options-Definitionen

Optionen können jetzt vordefinierte Auswahlwerte bekommen. Das macht Commands benutzerfreundlicher und verhindert ungültige Eingaben:

"options": {
  "status": {
    "type": "string",
    "required": true,
    "description": "Order status",
    "choices": ["pending", "processing", "complete", "canceled"]
  }
}

Im interaktiven Modus erscheinen die choices als Auswahlmenü. Per CLI werden ungültige Werte direkt zurückgewiesen.

Interaktive Prompts für fehlende Pflichtoptionen

Virtual Commands fragen fehlende Required Options jetzt interaktiv ab anstatt mit einer Fehlermeldung abzubrechen. Das Verhalten hängt vom Kontext ab: Im Terminal erscheint ein Prompt, in CI/CD-Pipelines wird der Fehler wie bisher ausgegeben. Soweit möglich werden Variablen die bereits von CI/CD Systemen wie Gitlab-CI oder Github Actions standardmäßig definiert wurden (wie CI=1), automatisch erkannt, sodass der interaktive Modus nicht die Pipeline blockieren kann.

Für Pipelines lässt sich der interaktive Modus aber auch explizit deaktivieren:

NON_INTERACTIVE=1 mage-remote-run my-command
# alternativ:
NONINTERACTIVE=1 mage-remote-run my-command

Beide Environment-Variablen werden als Alias akzeptiert an das Homebrew-Konvention-Feeling für Shell-Scripting.

Weitere Änderungen in v1.9

Performance: Config-I/O läuft jetzt vollständig asynchron (fs.promises statt synchronem fs) — spürbar bei häufigen Profil-Wechseln
Performance: findRegisteredPluginIndex nutzt Promise.all für parallele Prüfungen
Fix: Verschluckte Fehler in Catch-Blöcken wurden repariert — Fehler sind jetzt sichtbar statt still ignoriert
Refactoring: Duplicated Filter-Matching-Logik wurde in parseFilterOption extrahiert
Deps: axios, zod, inquirer und @modelcontextprotocol/sdk auf aktuelle Versionen gehoben

v1.10.0: Plugin-Kompatibilitätsprüfung über peerDependencies

Plugins deklarieren seit v1.6 eine peerDependency auf mage-remote-run. Ab v1.10 wird diese beim Laden tatsächlich ausgewertet.

Wenn ein Plugin eine Version von mage-remote-run voraussetzt, die nicht mit der installierten übereinstimmt, bricht das Laden mit einer klaren Fehlermeldung ab — statt mit unerklärlichem Laufzeitverhalten.

Das ist das übliche Prinzip: explizit schlechter als stumm falsch. Wer Plugins entwickelt oder nutzt, deklariert die peerDependency in der package.json des Plugins:

{
  "name": "my-mage-remote-run-plugin",
  "peerDependencies": {
    "mage-remote-run": ">=1.10.0"
  }
}

Die Prüfung läuft beim Plugin-Laden — noch bevor Commands registriert werden. Inkompatible Plugins werden übersprungen und der Fehler protokolliert.

Update

npm update -g mage-remote-run

Oder direkt auf die aktuelle Version:

npm install -g mage-remote-run@latest

Feedback und Bugreports wie immer via GitHub Issues. Wer Virtual Commands produktiv einsetzt oder Plugins entwickelt... ich freue mich über Erfahrungsberichte.

valantic wird Anthropic Partner – und ich war dabei

2026-06-18T08:46:00+00:00

valantic ist offiziell Select Partner im Claude Partner Network (Services Track) von Anthropic geworden - eines der ersten Consulting- und Solutions-Unternehmen in Europa überhaupt. Ich durfte an diesem Prozess inhaltlich mitwirken und war selbst Teil der Schulung, die dazu notwendig war.

Was diese Partnerschaft bedeutet

Eine Partnerschaft mit Anthropic ist kein reines Marketing-Abkommen. Um Select Partner zu werden, muss man nachweisen, dass man die Materie wirklich versteht: Claude, das Anthropic-Ökosystem, die Architektur hinter Agenten-Systemen. Und man muss in der Lage sein, dieses Wissen weiterzugeben – intern an Kolleginnen und Kollegen, aber auch in Kundenprojekten und Schulungen.

Der Gedanke dahinter ist nachvollziehbar: Anthropic will sicherstellen, dass Implementierungspartner nicht nur Lizenzen verkaufen, sondern echten Mehrwert liefern. Das setzt voraus, dass die Leute, die Kunden beraten, wissen, wovon sie reden.

London: Schulung zum Trainer

Ein Teil dieses Nachweises war eine Schulung in London, die ich zusammen mit meinem Kollegen Alexander Weinfurter besuchen durfte. Das Ziel war klar: Wir sollten das Wissen erwerben, um andere zu schulen – sowohl intern bei valantic als auch für Kunden.

Inhaltlich war es ein intensives Format. Wir haben uns tief mit der Evaluierung von Prompt-Ergebnissen beschäftigt – ein Thema, das in der Praxis oft unterschätzt wird. Es reicht nicht, einen Prompt zu bauen, der auf den ersten Blick funktioniert. Man muss strukturiert messen können, ob ein Modell konsistent, korrekt und für den jeweiligen Use Case geeignet antwortet. Dafür gibt es Methoden und Frameworks, die wir in London durchgearbeitet haben.

Ein weiterer Schwerpunkt war das Erstellen und Deployment von Agenten in der Cloud. Es ging darum wie man KI-Agenten produktionsreif aufsetzt, welche Infrastruktur dahintersteckt und wo die typischen Fallstricke liegen. Das ist genau der Bereich, der in vielen Projekten über Erfolg oder Misserfolg entscheidet: nicht das Modell selbst, sondern wie es eingebettet und verwendet wird.

Wir haben außerdem verschiedene Anthropic-Modelle verglichen und ein Gefühl dafür bekommen, wann welches Modell für welchen Einsatzzweck sinnvoll ist.

Was mich persönlich am meisten gefreut hat: der direkte Austausch mit Anthropic-Mitarbeitern und KI-Architekten und meinem valantic Kollegen. Alexander war zum Beispiel viel besser in der Optimierung der Prompts. So lernt man gegenseitig. Man bekommt in solchen Formaten einen anderen Einblick als durch Dokumentation und Blog-Posts. Fragen, die man im Alltag nicht einfach stellen kann, lassen sich dort direkt klären.

Was das für Kunden bedeutet

Wenn ich mir die valantic-Seite zur Claude Implementierung anschaue, sehe ich genau das abgebildet, was wir in London erarbeitet haben. Der Ansatz ist nicht "KI einschalten und fertig", sondern ein strukturierter Prozess: von der ersten Sondierung über einen Pilot mit messbarem Business Case bis zum unternehmensweiten Rollout.

Besonders wichtig finde ich den Aspekt, den valantic explizit benennt: Viele Unternehmen scheitern beim Sprung von einzelnen Tests zur produktiven Nutzung. Nicht weil das Modell schlecht ist, sondern weil Strategie, Governance und Integration fehlen. Das deckt sich mit dem, was ich in Projekten erlebe. Die Technologie ist selten das Problem.

Als konkreten Einstieg bietet valantic Claude Code Workshops für Entwicklungsteams an – ein direkter, praxisnaher Weg in Anthropics agentische Coding-Fähigkeiten. Für Entwickler, die verstehen wollen wie KI-gestützte Softwareentwicklung in der Praxis aussieht, ist das ein guter erster Schritt.

Der Select Partner Status bedeutet außerdem: valantic hat direkten Zugang zu Anthropic-Expertise und -Roadmaps. Das ist in einem Bereich, der sich so schnell entwickelt, kein unwichtiger Punkt. Einen Vorsprung beim Zugriff auf Informationen oder Modelle ist gerade jetzt ein Wettbewerbsvorteil.

Fazit

Ich finde es gut, dass valantic diesen Schritt gemacht hat – und ich finde es noch besser, dass er mit echtem Substanz-Aufwand verbunden war. Eine Schulung in London, inhaltliche Auseinandersetzung mit Evaluierung, Deployment und Architektur, direkter Kontakt zu Anthropic. Das ist kein Badge auf der Website, sondern Grundlage für Projekte, die tatsächlich funktionieren.

Wer das Thema Claude im Unternehmenskontext ernsthaft angehen will, hat bei valantic jetzt einen Ansprechpartner, der weiß, wovon er spricht.

Google Cloud Summit DACH 2026

2026-06-15T08:25:00+00:00

Letzte Woche war ich für valantic beim Google Coud Summit DACH in Frankfurt. Die Anreise war entspannt: mit dem Deutschlandticket per Zug, klimafreundlich und ohne Parkplatz-Stress. Schon das Rahmenprogramm hat gesetzt, was den Ton für die zwei Tage vorgab – groß, professionell, durchdacht. Mehrere Tausend Teilnehmer, kostenfreie Veranstaltung inklusive Essen und Getränken. Google lässt sich das was kosten.

Tag 1: Der AI Experience Walk

Der erste Tag stand für mich im Zeichen des AI Experience Walk – einer Art begehbaren KI-Ausstellung, bei der Google seine Lösungen entlang der kompletten Wertschöpfungskette vorgestellt hat. Vom ersten Kundenkontakt bis zur internen Prozessautomatisierung war alles vertreten.

Google gab selbst Einblicke wie sich die Entwicklung aufgrund der Nutzung von KI geändert hat. Es gibt immer mehr Entwickler die nur noch mit Prompts arbeiten und die IDE selbst gar nicht mehr wirklich nutzen.

Was für mich imer wieder durchkam war, dass das Thema "Grounding" einfach viel ernster genommen werden muss. Über Tests gilt es die Ergebnisse (gerade in Verbindung mit eigenen Daten) immer wieder zu automatisch zu überprüfen. Das Test-Driven-Development ist wieder da aber eben anders wie früher.

Was mich am meisten beeindruckt hat: Live-Remote-Video-Übersetzung in 15 Sprachen, in Echtzeit, direkt im Video-Stream. Das war kein Demo-Video und kein "coming soon" – das hat funktioniert. Solche Momente zeigen, wo KI gerade wirklich steht. Nicht alles ist noch Versprechen.

Ein zweites großes Thema am ersten Tag war Digitale Souveränität. Das ist kein neues Thema, aber es war auffällig, wie prominent Google es platziert hat. Wer kontrolliert die Infrastruktur, wer hat Zugriff auf die Daten, wo laufen die Modelle? Für viele Unternehmen sind das inzwischen keine akademischen Fragen mehr, sondern konkrete Entscheidungskriterien bei der Plattformwahl.

Tag 2: Hands-on statt Hype

Tag 2 war für mich der wertvollere. Weniger Bühne, mehr Werkstatt. In den Hands-on Sessions konnte man direkt selbst ran – und das macht einen Unterschied.

Ich habe einen MCP Server live auf das Google ADK umgestellt – direkt auf der Veranstaltung, nicht vorher vorbereitet, nicht in einer kontrollierten Demo-Umgebung. Das hat funktioniert, und das war ein gutes Signal. Das ADK ist praxistauglich genug, um spontan damit zu arbeiten.

Besonders interessant war ein Vortrag zum Thema RAG (Retrieval-Augmented Generation) am konkreten Anwendungsfall: Gesetzestexte. Die Herausforderung bei juristischen Dokumenten ist nicht nur, die richtige Passage zu finden – sondern sie auch korrekt zu zitieren, mit Paragraphen-Referenz und im richtigen Kontext. Genau das wurde gezeigt. Ein Anwendungsfall, der echte Anforderungen hat und bei dem schlechte Ergebnisse echte Konsequenzen hätten. RAG muss hier nicht nur "meistens" funktionieren.

Google als einziger Full-Stack-KI-Anbieter

Eine Beobachtung zieht sich durch beide Tage: Google ist der einzige Anbieter, der Hardware, Software und Plattform für KI aus einer Hand liefert. Eigene TPUs, eigene Modelle (Gemini), eigene Cloud-Infrastruktur, eigene Entwicklertools. Das ist eine andere Ausgangssituation als bei Anbietern, die sich auf externe Chip-Hersteller oder Drittanbieter-Infrastruktur verlassen.

Ob das ein Vorteil ist, hängt davon ab, was man sucht. Wer tief in das Google-Ökosystem einsteigen will, hat eine konsistente Stack-Erfahrung. Wer Unabhängigkeit und Portabilität priorisiert, sieht das vielleicht anders. Ich finde es trotzdem bemerkenswert, dass kein anderer Hyperscaler diese Kombination in dieser Tiefe vorweisen kann.

Fazit

Zwei Tage, mehrere Tausend Teilnehmer, kein Eintrittsgeld. Google investiert sichtbar in Community und Sichtbarkeit – und das zahlt sich aus. Man verlässt so eine Veranstaltung nicht mit fertigen Entscheidungen, aber mit einem guten Gefühl dafür, wo die Reise hingeht.

Für mich persönlich: Tag 2 hat mehr gebracht als Tag 1. Nicht weil der AI Experience Walk uninteressant war – sondern weil Hands-on-Erfahrung durch nichts zu ersetzen ist. Einen MCP Server live umzustellen und direkt Feedback zu bekommen, ist mehr wert als zehn Folien über dasselbe Thema.

Wer die Möglichkeit hat, beim nächsten Google Summit dabei zu sein: lohnt sich.

PHP Supply Chain Security: Composer und Packagist machen den nächsten Schritt

2026-05-28T07:00:00+00:00

Die letzten Wochen haben gezeigt, wie verwundbar auch das PHP-Ökosystem gegenüber Angriffen auf die Software-Lieferkette ist. Lange galt Supply Chain Security vor allem als NPM-Problem. Wer die jüngsten Vorfälle rund um laravel-lang (22. Mai) und intercom/intercom-php (30. April) verfolgt hat, weiß: PHP ist nicht weniger betroffen – wir haben es nur seltener auf dem Radar.

In beiden Fällen haben Angreifer kompromittierte GitHub-Accounts oder gestohlene Access-Tokens genutzt, um schadhafte Git-Tags auf Paketen zu veröffentlichen, auf die sie keinen legitimen Zugriff hatten. Das Ergebnis: Schadcode in weit verbreiteten Paketen, der bei einem composer update auf tausenden Systemen landet.

Das Packagist-Team hat jetzt in einem ausführlichen Blog-Post dargelegt, was bereits aktiv ist, was diese Woche ausgeliefert wird und wohin die Reise langfristig geht. Die Roadmap ist beeindruckend – und zeigt, dass hier seit fast einem Jahr konsequent an der Infrastruktur gearbeitet wird.

Was bereits funktioniert

Seit März 2026 ist Aikido-Malware-Erkennung direkt in Packagist.org integriert. Wenn eine Version als schädlich markiert wird, erscheint das sowohl in der Packagist-UI als auch in den Metadaten, die Composer abruft. In den jüngsten Vorfällen hat Aikido die kompromittierten Versionen korrekt geflagged.

Parallel dazu gibt es bereits ein öffentliches Transparenz-Log auf Packagist.org. Dieses Log zeichnet sicherheitsrelevante Ereignisse auf: Eigentümerwechsel, Maintainer-Änderungen, Versionsreferenz-Änderungen. Bei den aktuellen Angriffen – bei denen Angreifer bestehende Git-Tags im Nachhinein manipulierten – hat das Log genau das dokumentiert, was verändert wurde. Das ist solide forensische Infrastruktur.

Was diese Woche kommt: Composer 2.10

Das ist der Teil, der mich am meisten interessiert – und der unmittelbaren Handlungsbedarf schafft.

Unveränderlichkeit stabiler Versionen ist die wichtigste Änderung. Bisher konnte ein Angreifer (oder ein unvorsichtiger Maintainer) ein bestehendes Git-Tag einfach neu setzen – und Packagist aktualisierte die Referenz stillschweigend. Das ist vorbei. Ab diesem Deploy können stabile Versionen nicht mehr lautlos überschrieben werden. Tag-Änderungen am Upstream-Repository werden erkannt und abgelehnt; der Maintainer bekommt eine E-Mail-Benachrichtigung.

Das klingt wie eine Kleinigkeit, ist es aber nicht. Mutable Releases bedeuten: Ein kompromittierter Account kann eine bereits millionenfach installierte, als vertrauenswürdig eingestufte Version mit Backdoor versehen. Wer dann composer update ausführt, bekommt den manipulierten Code, ohne Warnung, ohne Versionsnummernänderung. Diese Angriffsfläche wird jetzt geschlossen.

Composer 2.10 führt außerdem ein einheitliches Dependency Policy Framework ein. Malware-Flags, Sicherheitswarnungen und verwaiste Pakete werden damit über einen gemeinsamen, konfigurierbaren Mechanismus gesteuert statt als Einzelfeatures übereinander gestapelt. Das ist die richtige Architekturentscheidung, weil es einen klaren Erweiterungspunkt für künftige Policies schafft.

Der Source-Fallback wird deprecated und in Version 2.11 komplett entfernt. Bisher konnte Composer bei einem fehlgeschlagenen Dist-Download auf das Git-Repository als Quelle zurückfallen. Das ist ein Verhalten, das in bestimmten Angriffsszenarien zu unerwartetem Code-Download führen konnte. Gut, dass das weg kommt.

Was folgt: Cooldown-Phasen und MFA-Sichtbarkeit

Zwei geplante Features, die ich für besonders wirksam halte:

Minimum Release Age: Eine Policy, die verhindert, dass brandneue Releases sofort in CI/CD-Pipelines installiert werden. Die meisten eingeschleusten schädlichen Versionen werden innerhalb von Stunden entdeckt und entfernt. Wer einen Cooldown von z.B. 24 Stunden erzwingt, nimmt Angreifern das entscheidende Zeitfenster. Diese Policy ist direkt abhängig von der oben beschriebenen Versions-Unveränderlichkeit – deswegen kam sie noch nicht, kommt aber bald.

MFA-Status wird öffentlich sichtbar: Künftig wird der MFA-Status von Maintainern auf ihren Profilen und im Transparenz-Log erscheinen. Das erzeugt sozialen Druck was ich für einen wirkungsvollen Hebel halte. Wer als Maintainer eines viel genutzten Pakets ohne 2FA dasteht, wird das merken.

Was mich dazu bewogen hat, heute zu handeln

Ich pflege mehrere Pakete auf Packagist.org, unter anderem n98-magerun2. Ich habe heute meinen Packagist-Account mit 2FA abgesichert.. Ehrlich gesagt hatte ich das gar nicht auf dem Schirm. Aber lieber spät als gar nicht.

Nicht weil es mich jemand gezwungen hat. Sondern weil mir beim Lesen des Packagist-Blog-Posts klar wurde: Das ist keine hypothetische Bedrohung mehr. Die Vorfälle sind real, die Angriffsvektoren sind dokumentiert, und die Konsequenzen eines kompromittierten Accounts treffen nicht nur mich – sondern alle, die das Tool nutzen.

Wer noch keinen guten Passwortmanager nutzt, sollte das ohnehin ändern. Tools wie 1Password, Bitwarden oder KeePassXC unterstützen heute alle TOTP-basiertes 2FA direkt – kein separates Authenticator-App-Chaos nötig. Ein Passwortmanager, der 2FA abdeckt, senkt die Hürde zur Aktivierung auf nahezu null. Es gibt keine sinnvolle Ausrede mehr.

Vertrauen ist eine Währung. Wer ein weit genutztes Open-Source-Paket pflegt, trägt Mitverantwortung für die Sicherheit der Systeme, auf denen es läuft. Das geht nicht an jemand anderen weiter. Nicht an Packagist, nicht an Composer, nicht an GitHub.

Was ich jedem Maintainer empfehle

2FA auf Packagist.org aktivieren – jetzt. Der MFA-Status wird bald öffentlich einsehbar sein. Wer jetzt handelt, tut das aus Überzeugung und nicht aus Druck.
Composer auf 2.10 aktualisieren, sobald die Version veröffentlicht ist. Das Source-Fallback-Verhalten allein ist ein guter Grund.
Keine shared Company Accounts für Pakete nutzen. Das Packagist-Team baut gerade Organizational Package Ownership, um diesen Übergang zu erleichtern.
Das Transparenz-Log kennen. Wer Pakete pflegt oder nutzt, sollte wissen, dass dort Änderungen protokolliert werden – und ab wann auch MFA-Ereignisse.

Einordnung: Ein Ökosystem zieht die Schrauben an

NPM hatte obligatorisches 2FA für beliebte Pakete bereits früher eingeführt, PyPI machte es im Januar 2024 für alle Maintainer verpflichtend. Das Packagist-Team sagt selbst, dass Composer hier punktuell hinterherhinkt – aber die jetzt angekündigte Roadmap ist keine Ad-hoc-Reaktion. Versions-Unveränderlichkeit, ein Dependency Policy Framework, FIDO2-gestützte Release-Flows, SLSA-Provenance – das ist erkennbar über Monate geplante Arbeit. Die Sovereign Tech Agency hat Teile davon mitfinanziert, was zeigt, dass kritische Open-Source-Infrastruktur inzwischen als schützenswert gilt.

KI hat hier übrigens Dynamik in beide Richtungen gebracht. Automatisierte Analyse hilft beim Erkennen von Anomalien – aber sie senkt auch die Hürde für Angreifer, überzeugende schädliche Commits zu erstellen. Das Wettrüsten ist real.

Was von uns als Community bleibt: unseren Teil tun. Und der beginnt mit dem Aktivieren von 2FA. Das dauert fünf Minuten.

Coding Agents im Vergleich: Meine Erfahrungen – und was Claude Code anders macht

2026-04-14T07:00:00+00:00

In den letzten Monaten habe ich mich intensiv mit Coding Agents beschäftigt. Angefangen mit dem GitHub Copilot Agent, über Google Jules, JetBrains Junie bis hin zu Kiro und OpenCode – ich habe fast alle relevanten Tools getestet und auf muench.dev beschrieben. Jetzt, wo ich (auch) Claude Code täglich im Einsatz habe, wird es Zeit für eine Zusammenfassung: Wo stehen die einzelnen Tools? Was unterscheidet Claude Code von der Konkurrenz? Und – eine Frage, die ich mir zunehmend stelle – wie schütze ich mich eigentlich vor einem Vendor-Lock-in?

Meine bisherigen Coding-Agent-Tests im Überblick

Wer meine Artikel kennt, weiß: Ich teste Dinge so lange, bis ich mir ein echtes Bild gemacht habe – mit echten Projekten, echten Fehlern und echten Erkenntnissen. Hier die Übersicht der bisher auf diesem Blog vorgestellten Agents:

JetBrains Junie

Mein erster "Wow, das klappt ja wirklich"-Moment in der Vibe-Coding-Serie. Junie ist tief in die JetBrains-IDE integriert, läuft serverbasiert und hat mich mit seinem iterativen Ansatz (Tests ausführen, Fehler korrigieren, weitermachen) wirklich beeindruckt. Einziger Nachteil: Rate-Limits treffen schnell, und wer nicht im JetBrains-Ökosystem lebt, ist außen vor.

Google Jules

Jules arbeitet in einer isolierten Cloud-Umgebung – asynchron und ohne dass man dabei sein muss. Interessanter Ansatz, aber die fehlende Interaktivität war für mich bei explorativer Entwicklung ein echtes Handicap. Für definierbare Batch-Aufgaben ein solider Kandidat.

Jules lasse ich inzwischen Code-Verbesserungen in meinen Open Source Projekten automatisch vorschlagen. Das produziert auch einiges an guten Ergebnissen. Allerdings bin ich als Mensch beim Review selbst das Bottleneck. Aber hier habe ich selten Zeitdruck. Daher ist das alles in Ordnung für mich. Generell habe ich 100 Tasks pro Tag in meinem AI Pro Account. Das ist sehr großzügig. Im Hintergrund arbeitet ein Gemini Pro Modell. Mein Anfangstest war noch mit durchwachsenen Ergebnissen. Das ist inzwischen aber alles sehr gut und brauchbar was produziert wird.

Ebenso sind die Sandboxes die Jules besser ausgestattet was den Speicherplatz angeht. Jetzt passen auch alle meine Projekte in deren Speicher.

GitHub Copilot Agent

Der bekannteste Name im Feld. VS Code-Integration ist unschlagbar, MCP-Support ist vorhanden und die Tiefe der Workspace-Analyse ist stark. Im direkten Vergleich mit Junie hatte ich allerdings etwas schlechtere Ergebnisse – und bei größeren Aufgaben musste ich die Arbeit auf mehrere Sessions aufteilen.

GitHub Copilot als asynchroner Agent

Spannend ist sicherlich die Nutzung des CoPilot auch als Helfer in GitHub Projekten selbst. Das kostet immer mindestens einen Premium-Request, wenn man eine Task verteilt. Davon habe ich in meinem Account 300 pro Monat. Geschäftlich hosten wir in unserem Team keine Kunden-Projekte in GitHub. Allerdings haben wir bei dem einen oder anderen Open Source Repository auch mal den GitHub CoPilot direkt Code prüfen gelassen. Der CoPilot meldet sich auch proaktiv in Pull Requests. Man kann das Ticket dann direkt dem CoPilot als Benutzer zuweisen und er arbeitet los.

Das ist schon sehr praktisch. Allerdings nutze ich den CoPilot selbst nur selten.

OpenAI Codex

Das Cloud-basierte Modell von OpenAI direkt als Agent. Gut für isolierte Tasks, aber mit der bekannten Cloud-Abhängigkeit und den üblichen Datenschutz-Abwägungen.

Ich habe Codex sehr zu schätzen gelernt. Er fragt weniger nach als Claude (mein subjektiver Eindruck). Die Ergebnisse von Codex bewerte ich meistens als sehr gut. Daher sehr zu empfehlen. Codex lässt sich auch über ein offizielles Plugin in Claude einbauen um dort Tokens zu sparen.

Codex CLI

Das CLI-Tool von OpenAI – kompakter als der vollständige Codex, aber flexibel einsetzbar. Für meinen Linux-Setup war es anfangs ein fester Bestandteil geworden. Hier nutze ich aber inzwischen Codex nur in Verbindung mit OpenCode.

Vibe-Coding mit Qwen Code

Qwen Code ist der Open-Source-Vertreter aus dem Hause Alibaba. Wer lokale Modelle bevorzugt oder keine Cloud-Daten möchte, wird hier fündig. Performance auf Augenhöhe mit den großen Playern – zumindest für eine bestimmte Klasse von Aufgaben. Qwen Code müsste ich mir neu anschauen. Daher habe ich keine aktualisierte Meinung.

Kiro

Kiro von AWS hat mich mit seinem "Spec-Driven Development"-Ansatz überrascht: erst Spezifikation, dann Implementierung. Der strukturierte Ansatz reduziert Missverständnisse zwischen Entwickler und Agent – aber auch hier: tief im AWS-Ökosystem verankert.

Damals hatte ich nur so "semi gute" Ergebnisse. Das Tool müsste ich heute nochmal neu bewerten.

OpenCode

Mein Favorit für maximale Flexibilität. OpenCode läuft mit fast jedem Modell, unterstützt MCP, hat eine schicke TUI und hält mich unabhängig von einem einzelnen Anbieter. Genau darum geht es mir.

Leider blocken sowohl Google als auch Anthropic die Nutzung über die Subscriptions. Man kann die Modelle aber per API anbinden.

OpenCode gefällt mir weiterhin sehr gut. Die TUI ist einfach schön und gut bedienbar. Auch in Gitlab CI habe ich OpenCode an den Start gebracht. Das ist einfach ein tolles und vielseitiges Tool. OpenCode verwende ich wie oben schon geschrieben inzwischen nur noch mit Codex und ich habe auch meinen GitHub CoPilot Account verknüpft. Damit kann man einfache Tasks in z.B. Sub-Agents an das nicht Token-limitierte GPT 4.1 Modell delegieren.

Vendor-Lock-in

Zwischen all den Feature-Vergleichen und Benchmark-Diskussionen geht eine Frage oft unter: Was passiert, wenn das Tool, auf das ich mich eingelassen habe, plötzlich die Preise erhöht, den Dienst einstellt oder – wie im Fall von Anthropic und OpenCode – politisch eingreift?

In meinem OpenCode-Artikel habe ich das bereits angesprochen: Anthropic hat zeitweise signalisiert, dass sie es nicht mögen, wenn Claude-Modelle über Drittanbieter-Tools wie OpenCode genutzt werden. OpenAI hat diesen Sachverhalt nun genutzt, um OpenCode öffentlich seine Unterstützung auszudrücken. Da ist Politik im Spiel – und das erinnert mich daran, dass ich meinen Tool-Stack nicht auf einem einzigen Anbieter aufbauen will.

flowchart TD
    M["🔵 Modell\nNur Modell X? Erpressbar.\nPricing, Einschränkungen"]
    T["🟡 Tool\nCLI / Extension gebunden.\nCopilot = MS-Ökosystem"]
    W["🟢 Workflow\nCLAUDE.md, MCP, Skills.\nUmbau kostet Zeit"]

    TRIGGER["⚡ Auslöser\nPreiserhöhung · Dienst eingestellt · Politischer Eingriff (Anthropic / OpenCode)"]

    CONV["✅ Gute Nachricht: Konvergenz\nAgent Skills funktionieren plattformübergreifend.\nAblage im Dateisystem wird zunehmend genormt.\nPortabilität wächst — Diversifikation wird leichter."]

    SOL["🔷 Antwort: Pragmatische Diversifikation\nKein Purismus — kein Single Point of Failure"]

    M --> TRIGGER
    T --> TRIGGER
    W --> TRIGGER
    TRIGGER --> CONV
    CONV --> SOL

    style M fill:#EEEDFE,stroke:#534AB7,color:#3C3489
    style T fill:#FAEEDA,stroke:#854F0B,color:#633806
    style W fill:#E1F5EE,stroke:#0F6E56,color:#085041
    style TRIGGER fill:#F1EFE8,stroke:#5F5E5A,color:#2C2C2A
    style CONV fill:#EAF3DE,stroke:#3B6D11,color:#27500A
    style SOL fill:#E6F1FB,stroke:#185FA5,color:#0C447C

Das Risiko ist real und betrifft mehrere Ebenen:

Modell-Abhängigkeit: Wenn mein Workflow nur mit Modell X funktioniert, bin ich erpressbar. Ändert sich die Pricing-Struktur oder werden bestimmte Nutzungsszenarien eingeschränkt, stehe ich vor einem Migrations-Problem.

Tool-Abhängigkeit: Wenn das CLI-Tool oder die IDE-Extension nur mit einem bestimmten Backend kommuniziert, ist der Wechsel aufwändig. Copilot ist hier das Paradebeispiel: tief in das Microsoft/GitHub-Ökosystem eingebettet, was Stärke und Schwäche zugleich ist.

Workflow-Abhängigkeit: Wenn ich meine CLAUDE.md, meine MCP-Server-Konfiguration und meine Skills auf eine Plattform zugeschnitten habe, kostet ein Wechsel eventuell einiges an Arbeitszeit.

Meine Antwort darauf ist kein Purismus, sondern pragmatische Diversifikation.

Zum Glück gleichen sich aber auch die Agenten in bestimmten Bereichen immer mehr an. So können z.B. Agent Skills quasi in allen Systemen genutzt werden. Auch die Ablage der Skills im Dateisystem wird immer mehr genormt.

Und jetzt: Claude Code

Ich habe bereits über die Installation von Claude Desktop unter Linux geschrieben. Claude Code ist nochmal eine andere Geschichte – und aktuell mein bevorzugtes Tool für intensive Entwicklungsarbeit.

Was Claude Code von den anderen unterscheidet

Der entscheidende Unterschied liegt nicht in den Features – fast alle modernen Agents können heute Dateien lesen, Code schreiben, Tests ausführen und Fehler korrigieren. Claude Code unterscheidet sich aus meiner Sicht in vier Punkten:

Qualität der Code-Analyse: Claude hat das tiefste Verständnis für bestehende Codebasen, das ich bisher erlebt habe. Es erkennt nicht nur, was der Code tut, sondern auch warum er so strukturiert ist. Das führt zu Vorschlägen, die sich nicht wie "generiert" anfühlen, sondern wie von einem Kollegen geschrieben, der den Code wirklich gelesen hat.

Das CLAUDE.md-Prinzip: Ähnlich wie GitHub Copilots copilot-instructions.md oder Kiros Spec-Ansatz setzt Claude Code auf eine CLAUDE.md-Datei als Projekt-Kontext. Ich definiere einmal Coding-Standards, Architekturentscheidungen und Was-nicht-zu-tun-ist – und Claude Code arbeitet konsequent darin. Das spart enorm viel Korrekturaufwand.

Was ich inzwischen auch mache ist die CLAUDE.md Datei auf die AGENTS.md verweisen zu lassen. In der Art wie Claude mit der Datei umgeht sehe ich schon Unterschiede zu den anderen Agenten. Hier ist Claude einfach das Maß der Dinge.

MCP als First-Class-Feature: Das Model Context Protocol (MCP) ist nicht zufällig das Protokoll, das ich am meisten nutze – Anthropic hat es entwickelt. In Claude Code ist MCP keine Erweiterung, sondern der Kern des Tool-Konzepts. Das merkt man in der Stabilität der Integration und in der Tiefe der möglichen Automatisierungen.

Wenn es sinnvoll ist und kein Skill ausreichend ist, erstelle ich MCP Server für wichtige Workflows wie z.B. das Anlegen von Drafts in meinem Blog.

Oft reicht aber auch ein einfacher Agent Skill aus. Da auch die Agent Skills ebenfalls ursprünglich von Anthropic stammen sind diese natürlich auch bestens integriert. In vielen Fällen sind die Skills sogar effizienter als MCP selbst. Aber egal was ich davon nutze, Claude ist eben genau dabei immer etwas vor der Konkurrenz.

Desktop Integration

Claude ist sehr gut in den Desktop integriert und ist hier Vorreiter. Die anderen Anbieter versuchen gerade nachzuziehen. Es gibt auch einen Codex Desktop oder OpenCode Desktop. Hier hat Anthropic einen guten Vorsprung und erlaubt es jetzt auch, dass auch Nicht-Entwickler das Tool im Arbeitsalltag einsetzen können.

Mein aktueller Stack

Nach all diesen Tests bin ich zu einer klaren Erkenntnis gekommen: Es gibt nicht den einen Coding Agent. Und ehrlich gesagt gilt das nicht nur für Agents – auch beim klassischen Chat-Interface setze ich bewusst auf mehrere Anbieter.

Coding Agents

Intensive Entwicklungsarbeit & Architekturentscheidungen: Claude Code – hier ist die Modellqualität entscheidend, und die API-Kosten rechtfertigen sich durch die Ergebnisqualität. Skills und MCP-Server (die Anthropic selbst erfunden hat) sind hier am besten integriert. Auch das Ökosystem zum Teilen von Agents und Skills über Plugins und Marktplätze ist schon sehr ausgereift.
Daily Driver mit Provider-Flexibilität: OpenCode mit OpenAI Codex als Backend – das gibt mir die Unabhängigkeit, die ich brauche, und hält mich nicht an ein einzelnes Modell gebunden.
Autonome Code-Verbesserungen: Google Jules im Hintergrund – vor allem für automatische Vorschläge in meinen Open-Source-Projekten. Mit 100 Tasks pro Tag im AI Pro Account ist das sehr großzügig. Dass ich als Mensch beim Review das Bottleneck bin, nehme ich in Kauf. Bei Open-Source-Projekten habe ich selten Zeitdruck.
Antigravity: Ebenfalls im Einsatz, wenn es darum geht, Coding-Aufgaben asynchron und toolgestützt zu delegieren.

Chat-Interfaces

Der Coding Agent ist aber nur eine Seite meines KI-Stacks. Für Recherche, Konzeption, Textentwürfe und ad-hoc-Fragen nutze ich ganz bewusst verschiedene Chat-Interfaces – und bin auch hier an keinen Anbieter gebunden:

Claude Desktop – mein täglicher Begleiter, auch unter Linux. Ich habe das Setup bereits in einem eigenen Artikel beschrieben.
Google Gemini – vor allem wenn es um große Kontextfenster geht oder ich eine zweite Meinung zu einer Architekturentscheidung brauche.
ChatGPT – nach wie vor ein solides Interface, das ich regelmäßig nutze.
Mistral – als europäische Alternative schätze ich Mistral, gerade wenn es um datenschutzsensible Themen geht. Die Modelle haben sich in letzter Zeit deutlich verbessert.

Das ist kein dogmatisches Setup, sondern ein lebendiges. Wenn in drei Monaten ein neuer Agent oder ein neues Chat-Interface einen dieser Slots besser besetzt, tausche ich ihn aus. Genau das ist der Punkt: kein Lock-in, sondern Entscheidungsfreiheit.

Was ist euer Stack? Und wie geht ihr mit dem Vendor-Lock-in-Thema um? Ich bin gespannt auf eure Perspektiven in den Kommentaren.

Adobe Commerce Optimizer: Das Unified Data Model unter der Haube

2026-04-13T07:00:00+00:00

Vor kurzem habe ich bei einem Adobe Event das Produkt Adobe Commerce Optimizer (ACO) vorgestellt. Bei der Vorstellung wollte ich nicht mit den Standard-Demodaten arbeiten und wollte meine eigenen Demo-Daten nutzen. Dazu musste ich folgende Dinge klären: Welche API nimmt Daten entgegen? Wie ist das Datenmodell strukturiert? Und wie kommt das Ergebnis in mein Storefront (oder eigenes Frontend)?

Was ist das Unified Data Model?

Hinter ACO steckt eine SaaS-Schicht namens Merchandising Services, die auf einem zentralisierten, quellenunabhängigen Datenspeicher basiert. Adobe spricht in diesem Zusammenhang von der CCDM-Architektur – Composable Catalog Data Model.

Der Kerngedanke: Produktdaten kommen aus beliebigen Quellen (ERP, PIM, Magento, Shopify, was auch immer), landen in einem einzigen Basiskatalog und werden dort nach einem einheitlichen Modell gespeichert. Die Storefront greift über GraphQL darauf zu – gefiltert durch Catalog Views und Policies (Regelwerk).

Das Standardfrontend ist die neue Adobe Commerce Storefront auf Basis von Edge Delivery Services (EDS). Diese Storefront ist darauf ausgelegt, Produktdaten direkt über die GraphQL-Schicht von ACO zu konsumieren – ohne klassischen Magento-Applikationsstack dazwischen. Wer ein eigenes Headless-Frontend betreiben will, kann ebenfalls direkt auf den GraphQL-Endpoint aufsetzen; die EDS-Storefront bleibt aber der von Adobe vorgesehene und gepflegte Standardweg.

Datenerfassung: REST rein

Daten kommen über eine RESTful Data Ingestion API in den ACO. Die Base-URL folgt diesem Schema:

https://{region}-{environment}.api.commerce.adobe.com/{tenantId}

Alle Requests benötigen einen Authorization-Header mit Bearer-Token (IMS-Credential-basiert) sowie Content-Type: application/json.

Schritt 1: Attribut-Metadaten definieren

Bevor ein einziges Produkt importiert werden kann, müssen die Attribut-Metadaten angelegt werden – und das pro Locale. ACO muss vorab wissen, wie es mit jedem Attribut umgehen soll: Ist es filterbar? Sortierbar? Suchbar? Mit welchem Gewicht?

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products/metadata' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "code": "name",
      "source": { "locale": "en-US" },
      "label": "Product Name",
      "dataType": "TEXT",
      "visibleIn": ["PRODUCT_DETAIL", "PRODUCT_LISTING", "SEARCH_RESULTS"],
      "filterable": false,
      "sortable": true,
      "searchable": true,
      "searchWeight": 1,
      "searchTypes": ["AUTOCOMPLETE"]
    },
    {
      "code": "brand",
      "source": { "locale": "en-US" },
      "label": "Brand",
      "dataType": "TEXT",
      "visibleIn": ["PRODUCT_LISTING", "SEARCH_RESULTS"],
      "filterable": true,
      "sortable": false,
      "searchable": true,
      "searchWeight": 1,
      "searchTypes": ["AUTOCOMPLETE", "CONTAINS", "STARTS_WITH"]
    }
  ]'

Der dataType kann TEXT, DECIMAL, BOOLEAN oder INT sein. visibleIn steuert, wo das Attribut auf der Storefront erscheint: Produktdetailseite, Listing, Suchergebnisse, Vergleich.

Schritt 2: Produkte anlegen

Danach kommen die eigentlichen Produkte per POST. Das Produkt-Objekt trägt neben den Pflichtfeldern (sku, source, name, slug, status) alle benutzerdefinierten Attribute als flache Key/Value-Liste im attributes-Array. Über routes wird das Produkt Kategorien zugeordnet.

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "sku": "aurora-battery-pro-100",
      "source": { "locale": "en-US" },
      "name": "Aurora Battery Pro 100",
      "slug": "aurora-battery-pro-100.html",
      "status": "ENABLED",
      "description": "High-performance 100Ah lithium battery for electric vehicles.",
      "shortDescription": "100Ah LiFePO4 traction battery",
      "visibleIn": ["CATALOG", "SEARCH"],
      "metaTags": {
        "title": "Aurora Battery Pro 100",
        "description": "100Ah LiFePO4 battery for EVs",
        "keywords": ["battery", "aurora", "electric vehicle"]
      },
      "attributes": [
        { "code": "brand", "values": ["Aurora"] },
        { "code": "location", "values": ["US"] },
        { "code": "capacity_ah", "values": ["100"] }
      ],
      "images": [
        {
          "url": "https://example.com/images/aurora-battery-pro-100.jpg",
          "label": "Aurora Battery Pro 100",
          "roles": ["BASE", "SMALL"],
          "customRoles": []
        }
      ],
      "routes": [
        { "path": "batteries" },
        { "path": "batteries/lithium", "position": 1 }
      ]
    }
  ]'

Auffällig: Alle Attributwerte – egal ob TEXT, DECIMAL oder INT – werden als Strings in values übergeben. ACO konvertiert sie intern anhand der vorher definierten Metadaten. An manchen Stellen würde ich mir etwas mehr Tiefe im Datenmodell wünschen, um auch kompliziertere Datenstrukturen (z. B. strukturierte Variantenkonfigurationen) sauber abbilden zu können. Das Array-Modell ist funktional, aber manchmal etwas flach.

Schritt 3: Price Books und Preise

Price Books ermöglichen unterschiedliche Preisstrukturen für verschiedene Kundensegmente, Regionen oder Kanäle – ohne den Basiskatalog zu verändern. Price Books können hierarchisch aufgebaut werden: Ein Basis-Price-Book legt die Währung fest, Kind-Price-Books erben davon und können selektiv überschreiben.

Zunächst werden die Price Books selbst angelegt:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/price-books' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "priceBookId": "us",
      "name": "US Base Price Book",
      "currency": "USD"
    },
    {
      "priceBookId": "us-retail",
      "parentId": "us",
      "name": "US Retail"
    },
    {
      "priceBookId": "us-wholesale",
      "parentId": "us",
      "name": "US Wholesale"
    },
    {
      "priceBookId": "eu",
      "name": "EU Base Price Book",
      "currency": "EUR"
    }
  ]'

Ein Price Book ohne parentId ist ein Root-Price-Book und muss eine currency definieren. Kind-Price-Books erben die Währung vom Parent und brauchen kein eigenes currency-Feld – nur eine parentId.

Danach werden die Preise pro SKU und Price Book über einen separaten Endpoint gepflegt:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/v1/catalog/products/prices' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer {accessToken}' \
  -d '[
    {
      "sku": "aurora-battery-pro-100",
      "regular": 899.99,
      "priceBookId": "us"
    },
    {
      "sku": "aurora-battery-pro-100",
      "regular": 749.99,
      "priceBookId": "us-wholesale"
    },
    {
      "sku": "aurora-battery-pro-100",
      "regular": 849.00,
      "priceBookId": "eu"
    }
  ]'

Dasselbe Produkt bekommt also je nach Price Book einen anderen Preis. Welchen Preis die GraphQL-API zurückliefert, steuert der AC-Price-Book-ID-Header im Storefront-Request – ohne dass dafür die Produktdaten angepasst werden müssten.

Das Datenmodell: Catalog Views und Policies

Der eigentlich interessante Teil der CCDM-Architektur ist nicht der Import, sondern die Filterschicht:

Catalog Views definieren eine Geschäftseinheit: ein Händler, eine Marke, ein Markt. Jede View ist mit einer Katalogquelle (Locale) und einer Menge von Policies verknüpft.
Policies sind Datenzugriffsfilter auf Basis von Produktattributen. Eine Policy Brand mit Wert Aurora liefert beispielsweise ausschließlich Produkte, die das Attribut brand = Aurora tragen.

Das bedeutet: Derselbe Basiskatalog kann über verschiedene Catalog Views mit verschiedenen Policies völlig unterschiedliche Produktmengen ausliefern – ohne Datenduplizierung. Für Szenarien mit mehreren Marken, Märkten oder Vertriebskanälen ist das ein erheblicher architektonischer Vorteil.

Ein konkretes Beispiel aus der offiziellen Dokumentation: Ein fiktives Unternehmen (Zenith Automotive) pflegt einen einzigen Katalog für zwei Marken und zwei Märkte. Statt vier separate Instanzen zu betreiben, wird ein View mit zwei Policies konfiguriert:

Policy Location filtert nach Zielmarkt (USA, UK)
Policy Brand filtert nach Marke (Aurora, Bolt)

Ein Produkt trägt die entsprechenden Attribute. Welche Produkte ein API-Aufruf zurückliefert, hängt ausschließlich von den übergebenen Policy-Headern ab – nicht von der Datenstruktur selbst.

Datenzugriff: GraphQL raus

Die Storefront – ob EDS-basiert oder eine eigene Headless-Implementierung – greift auf die Daten per GraphQL Merchandising API zu. Authentifizierung ist auf dieser Ebene nicht erforderlich; die Steuerung läuft über HTTP-Header:

Header	Bedeutung
`AC-View-ID`	Pflichtfeld – welche Catalog View soll verwendet werden?
`AC-Policy-{Name}`	Optional – Filterung nach Policy-Wert, z. B. `AC-Policy-Brand: Aurora`
`AC-Price-Book-ID`	Optional – welches Price Book soll für die Preisberechnung genutzt werden?

Eine typische Produktsuche sieht so aus:

curl -X POST \
  'https://na1-sandbox.api.commerce.adobe.com/{tenantId}/graphql' \
  -H 'Content-Type: application/json' \
  -H 'AC-View-ID: {catalogViewId}' \
  -H 'AC-Policy-Brand: Aurora' \
  -H 'AC-Price-Book-ID: us-wholesale' \
  -d '{
    "query": "query ProductSearch($search: String!) {
      productSearch(phrase: $search, page_size: 10) {
        items {
          productView {
            sku
            name
            description
            images { url }
            ... on SimpleProductView {
              price {
                regular {
                  amount { value currency }
                }
              }
            }
          }
        }
      }
    }",
    "variables": { "search": "battery" }
  }'

Die Response enthält ausschließlich Produkte, die zur konfigurierten View und Policy passen. Das Frontend muss nur die richtigen Header mitschicken – die gesamte Kataloglogik liegt in der ACO-Konfiguration.

Praktische Use Cases

Wo ist dieser Ansatz in der Praxis relevant?

Multi-Brand-Händler ohne Datensilos: Wer heute für jede Marke eine separate Magento-Instanz betreibt, kennt den Aufwand: Doppelte Pflege, doppelte Synchronisation, doppelter Upgrade-Aufwand. Mit CCDM ist das ein einziger Basiskatalog mit konfigurierten Views – und die organisatorische Trennung bleibt über Policies erhalten.

Internationalisierung ohne Datenduplizierung: Verschiedene Märkte, verschiedene Preise, verschiedene Sortimente – über Price Books und Policies steuerbar, ohne den Katalog zu kopieren.

Headless-Storefronts mit beliebigem Backend: ACO ist explizit darauf ausgelegt, dass das datenliefernde System kein Adobe Commerce sein muss. ERP, PIM, Shopify, ein eigenes System – alles kann über die REST Ingestion API einspeisen. Die EDS-Storefront konsumiert dann via GraphQL. Wer die EDS-Storefront nicht nutzen will, kann mit einem eigenen Frontend direkt an den GraphQL-Endpoint andocken. Ich habe das exemplarisch umgesetzt unter aco.demo.muench.dev.

Warenkorb und Checkout bleiben flexibel: ACO stellt bewusst keinen Warenkorb bereit. Der wird über API Mesh oder App Builder an ein bestehendes System angebunden. Das ist pragmatisch – und verhindert, dass für einen Storefront-Umbau die gesamte Transaktionslogik angefasst werden muss.

Ehrliche Einschätzung

Das Modell ist relativ einfach aufgebaut (mir manchmal zu einfach). Die klare Trennung zwischen Ingestion (REST), Konfiguration (Catalog Views/Policies) und Delivery (GraphQL) ist sauber durchdacht. Gerade für komplexe Multi-Brand- oder Multi-Market-Setups ist das eine Architektur, die in klassischen Magento-Projekten mit erheblich mehr Aufwand gebaut werden muss.

Allerdings bietet ACO keine Transaktionslogik direkt von Haus aus an. Alles was komplizierter ist, muss momentan selbst angebaut werden.

Dazu kommt: ACO ist SaaS-only. Für Händler, die ihre Datenhaltung im eigenen Rechenzentrum behalten müssen oder wollen – ein Thema, das ich im Tech-Trends-Post für 2026 unter dem Stichwort Sovereign Commerce ausgeführt habe – ist ACO in seiner aktuellen Form keine Option.

Für die richtige Zielgruppe dagegen – Enterprise-Händler mit komplexen Katalogstrukturen, die ihren bestehenden Backend-Stack behalten und die Storefront-Experience modernisieren wollen – ist ACO ein überzeugender Ansatz.

Für alle die vielleicht schon eine sehr heterogene Landschaft haben und sowieso vieles auf Services verteilt haben, ist ACO echt spannend. Die Stärken von ACO sind auch immer in Verbindung mit einem hochskalierenden Frontend auf Basis von Adobe Edge Delivery Services zu sehen. Wer nur einach Daten halten und ausspielen will, für den ist ACO vielleicht nicht das richtige. Das heisst aber nicht, dass es nicht auch spannend sein kann ein eigenes Frontend direkt auf die GraphQL Schnittstelle zu setzen.

Fazit

Das Unified Data Model hinter Adobe Commerce Optimizer ist keine Abstraktionsschicht ohne Substanz. Es ist ein einfaches, quellenunabhängiges Katalogmodell: Daten kommen per REST-API rein, werden über Catalog Views und Policies konfiguriert und per GraphQL ausgeliefert – an die EDS-Storefront oder ein eigenes Frontend.

Wer das selbst erkunden will: Die offizielle Dokumentation ist inzwischen gut aufgestellt. Einstiegspunkte sind die Developer-Doku zur Data Ingestion API und der End-to-End Use Case in der Adobe-Dokumentation. Ihr braucht dann zum Ausprobieren eine Sandbox von Adobe oder lasst es euch von mir zeigen. :-)

Agentic Commerce: Wenn KI-Agenten den Einkaufswagen übernehmen

2026-04-10T05:00:00+00:00

In den letzten Monaten beschäftigt mich ein Thema mehr als jedes andere im E-Commerce-Umfeld: Agentic Commerce. KI-Agenten, die autonom einkaufen, verhandeln und bezahlen – ohne dass ein Mensch auch nur einen Button klickt. Das klingt nach Science-Fiction, ist aber bereits Realität. Und wer im Magento/Adobe-Commerce-Ökosystem unterwegs ist, sollte jetzt genauer hinschauen. Aus diesem Grund gibt es in diesem Blog-Beitrag auch einen Blick ins Magento Ökosystem.

McKinsey beziffert das globale Marktpotenzial auf 3–5 Billionen US-Dollar bis 2030, Gartner prognostiziert, dass 90 % aller B2B-Einkäufe bis 2028 von KI-Agenten abgewickelt werden. Gleichzeitig zeigt ein nüchterner Blick auf die aktuellen Daten: Der Hype ist der realen Nutzeradoption weit voraus. OpenAI hat sein Instant Checkout in ChatGPT Anfang 2026 bereits wieder auf Händler-Apps umgestellt. Deutsche Verbraucher würden einem KI-Agenten im Schnitt maximal 50 Euro pro Monat anvertrauen.

Ich versuche in diesem Post, das Thema strukturiert aufzudröseln: Was ist Agentic Commerce überhaupt? Welche Protokolle setzen sich durch? Wer sind die relevanten Player? Und was bedeutet das konkret für das Magento/Adobe-Ökosystem?

Was Agentic Commerce vom klassischen E-Commerce unterscheidet

Der entscheidende Unterschied liegt in der Rollenverteilung. Im traditionellen E-Commerce sucht, vergleicht und kauft der Mensch aktiv. Bei Conversational Commerce führt ein Chatbot ein Gespräch, aber der Mensch entscheidet. Bei Agentic Commerce delegiert der Mensch – er definiert Ziele, Budget und Präferenzen, und der Agent handelt innerhalb dieser Leitplanken eigenständig.

Deloitte beschreibt vier evolutionäre Stufen:

Assisted Discovery – KI hilft bei der Produktsuche
Agentic Shopping – Agent übernimmt Teilschritte autonom
Autonomous Shopping – vollständig eigenständige Käufe
Agent-to-Agent Commerce – Käufer- und Verkäufer-Agenten verhandeln direkt miteinander, ohne dass je ein Mensch einen Bildschirm sieht

Wir stehen gerade zwischen Stufe 1 und 2. Stufe 4 ist Zukunft – aber die Infrastruktur dafür entsteht jetzt.

Der Protokoll-Stack: Kein Krieg, sondern Schichten

Anfangs gab es viel Lärm um einen angeblichen „Protocol War" zwischen MCP, A2A, UCP und ACP. Das hat sich inzwischen differenziert. Die Protokolle sind keine Konkurrenten, sondern Schichten eines gemeinsamen Stacks.

MCP – die universelle Datenschicht

Das Model Context Protocol (MCP), im November 2024 von Anthropic vorgestellt, ist mittlerweile der De-facto-Standard dafür, wie Sprachmodelle auf externe Daten, APIs und Tools zugreifen. Es funktioniert wie „USB-C für KI" – eine standardisierte Schnittstelle, unabhängig vom Modell-Hersteller.

Im Dezember 2025 übergab Anthropic MCP an die Agentic AI Foundation (AAIF) unter dem Dach der Linux Foundation. Gründungsmitglieder sind AWS, Google, Microsoft und OpenAI – inzwischen sind über 10.000 öffentliche MCP-Server registriert. Das ist ein starkes Signal für langfristige Stabilität.

A2A – Agenten reden miteinander

Googles Agent-to-Agent Protocol (A2A), im April 2025 vorgestellt, ermöglicht Agenten unterschiedlicher Hersteller, einander zu entdecken und Aufgaben zu delegieren. Kernkonzept sind Agent Cards – JSON-Metadaten unter /.well-known/agent.json, die Fähigkeiten und Auth-Anforderungen beschreiben. Quasi eine Visitenkarte für Agenten. Im Juni 2025 ebenfalls an die Linux Foundation übergeben, inzwischen mit 150+ unterstützenden Organisationen.

UCP vs. ACP – die eigentliche Protokollfrage im Commerce

Das ist die Frage, die mich im Moment am meisten beschäftigt. Die Kollegen bei valantic haben dazu einen lesenswerten Deep-Dive zum Agentic Commerce Protocol veröffentlicht, der die technischen Unterschiede beider Ansätze gut herausarbeitet.

Das Universal Commerce Protocol (UCP) wurde im Januar 2026 auf der NRF von Google und Shopify gemeinsam vorgestellt. Es deckt den kompletten Commerce-Lebenszyklus ab – von Discovery über Checkout bis Post-Purchase-Support. Transport-agnostisch, mit REST-, MCP- und A2A-Bindings. Die Koalition dahinter ist beeindruckend: Walmart, Target, Etsy, Wayfair, Zalando, Mastercard, Visa, Stripe und 20+ weitere Partner.

Universal Commerce Protocol: Checkout Sequenz

Layered Architecture: UCP trennt die Verantwortlichkeiten in Schichten. Der Shopping Service definiert die Grundbausteine (Warenkorb, Status), während Capabilities (Checkout, Catalog, Orders) und Extensions (z. B. spezielle Liefermodelle) flexibel hinzugefügt werden können.
Discovery via /.well-known: Ähnlich wie bei A2A nutzt UCP einen standardisierten Pfad (/.well-known/ucp), über den Agenten die "Fähigkeiten" eines Shops entdecken und aushandeln können, welche Protokollversionen beide Seiten beherrschen.
State-Management: Ein Checkout im UCP durchläuft definierte Zustände: incomplete (fehlende Daten), requires_escalation (Eingriff nötig) und ready_for_complete (bereit zum Abschluss). Dies ermöglicht den nahtlosen Übergang zwischen KI-Automatisierung und menschlicher Interaktion über das Embedded Checkout Protocol (ECP).

Das Agentic Commerce Protocol (ACP) wurde von OpenAI und Stripe entwickelt und trieb ChatGPTs „Instant Checkout" an. OpenAI hat diesen Ansatz Anfang März 2026 jedoch bereits angepasst: Der Checkout-Prozess verlagert sich zunehmend in händlerspezifische „ChatGPT Apps", weil die Komplexität des Handels – dynamische Preise, Echtzeit-Bestände, Steuerregeln – besser in kontrollierten Händler-Umgebungen abgebildet werden kann. Walmart meldete eine 3x schlechtere Conversion als auf walmart.com direkt.

Agentic Commerce Protocol: Checkout Sequenz

Minimalistische Architektur: Das Protokoll beschränkt sich auf die vier Endpunkte Create, Update, Complete und Cancel Checkout, um die Komplexität für Händler gering zu halten.
Shared Payment Token (SPT): Dies ist der entscheidende Sicherheitsmechanismus. Der Agent (z. B. ChatGPT) sieht niemals die echten Kreditkartendaten des Nutzers. Er erhält lediglich einen "selbstzerstörenden", einmaligen Token von Stripe, den er an den Händler weiterreicht.
Merchant of Record: Im ACP-Modell bleibt der Händler der rechtliche Verkäufer ("Merchant of Record") und behält die Kontrolle über die Abwicklung, Steuern und den Kundensupport.
Voraussetzung: Händler müssen ihre Produktkataloge maschinenlesbar (Product Feed) bereitstellen und ihre Checkout-Logik über die ACP-Schnittstellen zugänglich machen.

Strategisch klug aufgestellt sind Stripe und Shopify – beide sind in beiden Lagern vertreten. Das macht sie zu Gewinnern unabhängig vom Ausgang.

AP2 und ANP als Ergänzungen

Googles Agent Payments Protocol (AP2) regelt die kryptographisch abgesicherte Payment-Autorisierung durch Agenten, mit drei abgestuften Autonomie-Levels.

Das AP2 nutzt das Konzept der Verifiable Credentials (VC), um Vertrauen in autonomen Systemen zu schaffen:

Intent Mandate (Absicht): Erteilt dem Agenten den Auftrag, innerhalb bestimmter Leitplanken (z. B. „maximal 150 €“) zu suchen und zu verhandeln. Es dient als Beweis, dass der Agent nicht eigenmächtig handelt.
Cart Mandate (Warenkorb): Dieses Dokument wird vom Händler und vom Nutzer signiert. Es fixiert den Preis und die Artikelmenge, sodass der Agent den Preis während des Checkouts nicht mehr (zuungunsten des Nutzers) verändern kann.
Payment Mandate (Zahlung): Ein minimaler Datensatz, der an die Bank übermittelt wird. Er signalisiert dem Zahlungsnetzwerk, ob der Nutzer gerade anwesend ist (Human-Present) oder ob der Agent eine vorab genehmigte Daueraufgabe ausführt (Human-Not-Present).

Das Agent Network Protocol (ANP) verfolgt den ambitioniertesten Ansatz mit dezentraler Agenten-Entdeckung via W3C DIDs – ist aber ohne starkes Unternehmens-Backing noch deutlich weniger reif.

ANP verfolgt im Gegensatz zu den meist Client-Server-basierten Protokollen wie ACP oder UCP einen radikal dezentralen Peer-to-Peer (P2P) Ansatz. Es wird oft als das „HTTP des Agentic Web“ bezeichnet und setzt konsequent auf Web-Standards wie W3C DIDs (Decentralized Identifiers) und Semantic Web Technologien.

Mandat im ANP Protokoll

Computer Use als pragmatischer Fallback

Für die vielen Websites ohne API-Anbindung bleibt Browser-Automatisierung der Fallback. Claudes Computer Use erreicht inzwischen 72,5 % auf dem OSWorld-Benchmark (von 14,9 % bei Launch). Langsamer und fehleranfälliger als saubere APIs – aber sofort einsetzbar. McKinsey sieht Web-Crawling als Zwischenschritt, bevor Merchants standardisierte Protokolle implementieren.

Wer baut die Infrastruktur?

Shopify hat den größten Vorsprung

Shopify ist der aggressivste Akteur. Seit den Summer '25 Editions hat jeder Shopify-Store einen eigenen MCP-Endpoint (your-store.myshopify.com/api/mcp). Der Shopify Catalog kategorisiert Milliarden von Produkten für KI-Agenten. Agentic Storefronts ermöglichen es Händlern, ihre Markenpräsenz auf ChatGPT, Perplexity, Google Gemini und Microsoft Copilot direkt aus dem Admin zu steuern.

Besonders interessant: Der neue Agentic Plan öffnet den Shopify Catalog explizit für Marken auf Magento, Salesforce Commerce Cloud und Custom-Stacks – ohne Migration. Das ist eine aggressive Einladung an unsere Community.

Google baut den vollständigsten Stack

Google hat: eigene Protokolle (A2A, AP2), gemeinsam mit Shopify entwickelten Commerce-Standard (UCP), 50 Milliarden indexierte Produkte im Shopping Graph, KI-Shopping in AI Mode und Gemini sowie eine neue Enterprise-Plattform mit Kroger, Lowe's und Woolworths als Live-Kunden. Über eine Milliarde Shopping-Interaktionen täglich laufen durch Google-Oberflächen.

Adobe Commerce ist drin – aber noch nicht live

Für unser Ökosystem ist die Situation ehrlich gesagt gemischt. Adobe hat am 18. Februar 2026 offiziell die Unterstützung von UCP, ACP und AP2 angekündigt – aber noch kein Live-Shopping über KI-Plattformen. Während Shopify-Händler bereits über ChatGPT und Gemini verkaufen, baut Adobe seine Grundlagen noch auf.

Adobe nennt dabei beeindruckende Zahlen aus dem Adobe Digital Insights Report vom Januar 2026: KI-Referrals erzielen eine 31 % höhere Konversionsrate, 254 % mehr Umsatz pro Besuch und 45 % längere Verweildauer gegenüber herkömmlichem Traffic.

Adobes Strategie hat drei Säulen:

Discovery Layer mit dem LLM Optimizer (GA seit Oktober 2025) – macht Produktkataloge für KI-Agenten auffindbar
Agent-to-Agent Commerce Layer durch UCP/ACP-Unterstützung (angekündigt, noch nicht live)
Brand-Owned Experience mit dem Adobe Brand Concierge als konversationelle KI-Schicht auf AEP-Profildaten

Der Adobe Commerce Optimizer ist das vielversprechendste neue Produkt: ein eigenständiges Commerce-Frontend auf Edge Delivery Services mit Lighthouse-Score 100, einer GraphQL-Merchandising API für Agents und Frontends sowie einer Data Ingestion REST API. Entscheidend: Es arbeitet mit jedem Commerce-Backend, nicht nur Adobe Commerce.

Die AEP Agent Orchestrator Plattform (GA September 2025) ist das technische Fundament: 10 zweckgebundene KI-Agenten, ein Reasoning Engine, Agent SDK und Agent Registry. Über 70 % der berechtigten AEP-Kunden nutzen bereits den AI Assistant.

Bildquelle: Adobe

Das Magento MCP-Ökosystem lebt

Was mich positiv überrascht hat: Das MCP-Ökosystem rund um Magento ist überraschend lebendig. Neben dem offiziellen Adobe Commerce Extensibility MCP Server (mit RAG-Zugriff auf die gesamte Dokumentation und 7 AI-Agent-Skills) gibt es mindestens 10 Community-Server:

Rafael Corrêa Gomes' GraphQL-basierter Dev MCP (Practice Director bei Valtech)
Mirasvits kommerzieller AI Agent Connector – ermöglicht Befehle wie „Reduziere alle Sommerprodukte, die sich 30 Tage nicht verkauft haben, um 15 %"
Freentos Extension auf dem Adobe Marketplace
Magenable Magento MPC für OpenAI Agent Builder
Magendoos REST- und GraphQL-MCP-Server mit 594 Endpoints und weitere
mage-remote-run MCP - Der Vollständigkeit wegen liste ich hier auch den MCP Server meines eigenen neuen Tools über den mal auch beliebige Shops flexibel andocken kann ohne etwas in dem jeweiligen Shop zu installieren.

Die Community reagiert schnell. Ob das reicht, um mit Shopifys nativem MCP-Endpoint pro Store mitzuhalten – das ist die Frage, die mich treibt.

ACP-Module für Magento 2: Die Community liefert bereits

Parallel zum MCP-Ökosystem entstehen erste Open-Source-Implementierungen des Agentic Commerce Protocol direkt für Magento 2. Zwei Projekte, die ich im Blick habe:

run-as-root/ACP-for-Magento-2 ist das technisch ausgefeilteste der beiden. Das Modul der Würzburger Agentur run_as_root setzt zu 95 % die OpenAI-ACP-Spezifikation um: vollständige Checkout Session API mit fünf Endpunkten, ACP-konformer Product Feed (inkl. Varianten, Gallery-Images, Echtzeit-Inventory), HMAC-Signaturvalidierung, Idempotency-Key-Handling via Redis und Replay-Attack-Schutz. Die Stripe-Integration für Delegated Payments ist dabei, ebenso wie 39 Unit- und Integrationstests.

magebitcom/magento2-agentic-commerce-module kommt von der lettischen Agentur Magebit und bezeichnet sich selbst als erstes öffentlich verfügbares Open-Source-ACP-Modul für Magento 2. Der Funktionsumfang ist ähnlich: ChatGPT-kompatibler Product Feed Export, Instant Checkout, Delegated Payment via Stripe, Webhooks. Wichtig: Das Modul ist Hyva- und Adobe Commerce Cloud-kompatibel – das ist für viele Projekte entscheidend.

Salesforce und Amazon der Vollständigkeit halber

Salesforce hat mit Agentforce Commerce (GA November 2025) über 6.000 bezahlte Deals abgeschlossen. Die KI-gestützte Intent-Aware Search basiert auf einem Commerce-optimierten Small Language Model. Salesforce-eigene Daten: KI-Agenten beeinflussten 17 % ($13,5 Mrd.) der Holiday-Weekend-Bestellungen 2025.

Amazon betreibt mit Rufus (300 Millionen aktive Nutzer, geschätzt 12 Mrd. Dollar inkrementeller Jahresumsatz) und der „Buy for Me"-Funktion ein geschlossenes Ökosystem. Alle OpenAI-Crawler blockiert, nicht in ACP oder UCP integriert. 40 % des US-E-Commerce sind damit für externe KI-Agenten unsichtbar – eine strategische Entscheidung, die Amazon teuer werden könnte.

Stripe als Payment-Schicht beider Welten

Stripe hat mit der Agentic Commerce Suite (Dezember 2025) eine vollständige Lösung: Katalog-Syndizierung, Checkout, Payments und Fraud Detection. Shared Payment Tokens (SPT) – einmal verwendbar, widerrufbar, programmierbar – lösen das Problem, wie Agenten sicher bezahlen können, ohne Zahlungsdaten offenzulegen. Parallel dazu treiben Coinbase und Cloudflare den x402-Standard voran – optimiert für Micropayments im Machine-to-Machine-Bereich. Bis März 2026 wurden darüber bereits 50 Millionen Transaktionen abgewickelt, durchschnittlich 0,20 US-Dollar je Transaktion.

Was der Wandel für PSPs konkret bedeutet, beleuchtet valantic in einem separaten Artikel: Agentic Commerce und Payment Service Provider.

Was Agentic Commerce konkret bedeutet

Im B2C noch in der Frühphase

Amazons „Buy for Me" (Beta seit April 2025), Googles entsprechendes Feature in Gemini, ChatGPT Shopping mit 50 Millionen täglichen Anfragen – die erste Welle läuft. Autonomous Reordering durch IoT-Geräte, Preisvergleichs-Agenten, die dutzende Retailer simultan scannen und beim optimalen Zeitpunkt kaufen – das sind die ersten real nutzbaren Use Cases.

Laut Adobe beeinflussten KI-Agenten in der Weihnachtssaison 2025 bereits 262 Milliarden US-Dollar des globalen Online-Umsatzes. KI-generierte Produktempfehlungen erzielen eine 4,4-fach höhere Konversionsrate als die traditionelle Suche.

Im B2B liegt der eigentliche Hebel

Hier sehe ich das größte Potenzial. Procurement-Agenten überwachen Verbrauchssignale, validieren Vertragspreise und platzieren Orders automatisch unter Budgetlimits. Auf der Verkäuferseite reagiert ein Sales Agent dynamisch, passt Rabatte und Lieferkonditionen an und schließt die Bestellung ab – alles in Sekunden. Gartner prognostiziert bis 2028 ein B2B-Beschaffungsvolumen von 15 Billionen US-Dollar durch KI-vermittelte Einkäufe.

Die unbequemen Fragen: Vertrauen, Haftung, Sichtbarkeit

Was die Adoption bremst, sind nicht die Protokolle – sondern Vertrauen und ungelöste Haftungsfragen.

Eine Riverty/Adyen-Umfrage (1.000 Deutsche, Dezember 2025) zeigt: 50 % würden KI-Agenten maximal 50 Euro pro Monat anvertrauen. 46 % assoziieren KI-Shopping mit Skepsis. 93 % verlangen, KI-Entscheidungen jederzeit einsehen und stoppen zu können.

Die Haftungsfrage ist juristisch ungeklärt. Wer haftet, wenn der Agent falsch kauft? Vermutlich bleibt es am Merchant hängen. Hinzu kommt ein 25 % Anstieg bösartiger Händleraktivitäten im Zusammenhang mit Agentic Commerce (Visa) – Betrüger manipulieren agentische Shopping-Ergebnisse gezielt.

Und dann ist da noch Agent Optimization – der Nachfolger von SEO. Wenn nicht mehr Menschen, sondern KI-Agenten die ersten „Kunden" sind, braucht es maschinenlesbare Produktdaten, strukturierte Kataloge und API-First-Architektur. Creatuity empfiehlt dabei konkret: vollständige Produktattribute (technische Daten, Materialien, Zertifizierungen), GraphQL-Abdeckung (reduziert Payload um 30–50 %) und korrektes Schema.org Markup. Gartner prognostiziert einen 25 % Rückgang des traditionellen Suchvolumens bis 2026. Der KI-getriebene Traffic zu US-Retail-Sites stieg laut Adobe im Juli 2025 um 4.700 % im Jahresvergleich.

Eine zentrale strategische Frage bleibt dabei oft ungestellt: Brauchen wir in Zukunft überhaupt noch eigene Webshops? Die valantic-Kollegen haben das klar eingeordnet: Der Webshop verschwindet nicht, seine Rolle verschiebt sich aber vom zentralen Einstiegspunkt zum Fundament eines vernetzten Vertriebssystems. Wer eine modulare, API-basierte Architektur betreibt, ist klar im Vorteil.

Mein Fazit (bisher)

Agentic Commerce ist weder bloßer Hype noch unmittelbare Revolution – es ist eine fundamentale Infrastruktur-Transformation, deren Nutzung der Technologie um 12–24 Monate hinterherhinkt.

Für das Magento/Adobe-Commerce-Ökosystem sehe ich eine gemischte Lage: Wir haben eine lebendige MCP-Community, reichhaltige APIs und mit dem Commerce Optimizer ein zukunftsfähiges Produkt. Der Rückstand auf Shopifys native Agentic Storefronts ist aber real – und die Community holt aktiv auf, wie die ersten ACP-Module zeigen.

Was ich jedem empfehle, der heute im Commerce-Bereich entwickelt:

MCP-Server für den eigenen Shop evaluieren – ob offiziell, kommerziell oder aus der Community
ACP-Modul testen – Magebit oder run-as-root bieten funktionierende Ausgangspunkte
Strukturierte Produktdaten optimieren – Schema.org, JSON-LD und maschinenlesbare Kataloge sind die Grundlage
Adobe Commerce Optimizer imf Auge behalten – als potenzieller Weg zu Agent-fähigen Storefronts
Shopifys Agentic Plan beobachten – Shopify ist hier vorne und sollte immer im Blick sein. Das gilt auch dann, wenn man selbst nicht auf Shopify setzt.

Die nächsten 12 Monate werden von Low-Consideration-Käufen dominiert sein – Nachbestellungen, Standardprodukte, Commodity-Elektronik. Die wirkliche Disruption im High-Engagement-Commerce kommt später, aber langsamer als die Keynote-Slides vermuten lassen.

API-First ist kein Nice-to-have mehr, sondern existenzkritisch. Wer heute maschinenlesbare, gut dokumentierte APIs betreibt, wird morgen von KI-Agenten gefunden. Wer sich ausschließlich auf menschliche Browser-Interaktion verlässt, wird zunehmend unsichtbar.

Weiterführende Artikel

Das Thema ist breit – hier ein paar Beiträge von direkten Kollegen von mir, die ich empfehle um einen Überblick zu bekommen:

valantic: Agentic Commerce – Interview und Einordnung – Was Agentic Commerce wirklich bedeutet und wo wir heute stehen
valantic: Das Agentic Commerce Protocol im Detail – Technischer Deep-Dive zu ACP und UCP
valantic: Agentic Commerce und Payment Service Provider – Was der Wandel für PSPs und Zahlungsinfrastruktur bedeutet
valantic: Brauchen wir noch eigene Webshops? – Strategische Einordnung der Rolle des eigenen Shops im Zeitalter von KI-Agenten

Stabil vs. Volatil: Wann klassische Automatisierung die bessere Wahl ist – und wann nicht

2026-04-07T07:00:00+00:00

Wer mich kennt, weiß: Ich liebe Automatisierung, die einfach funktioniert. Um ein Prinzip zu verdeutlichen, das mir gerade durch den Kopf geht, habe ich ein kleines Gedankenexperiment in n8n aufgebaut. Es ist ein fiktives Szenario, das aber ein reales Problem moderner Workflows auf den Punkt bringt. Ich habe zwei parallele Wege konstruiert, um nützliche Daten zu generieren.

Auf der einen Seite: Ein simpler Code-Node – mein "Fels in der Brandung". Er tut exakt das, was er soll, jedes Mal gleich, nahezu kostenlos. Auf der anderen Seite: Ein AI-Agent, befeuert durch OpenRouter. Das "kreative Chaos", das Lösungen findet, die man nicht hart codieren kann, aber eben auch eine gewisse Unberechenbarkeit mitbringt.

Mir kamen dann die Begriffe Stabil oben in Grün und Volatil unten in Gelb in den Sinn.

Zwei fiktive Wege in einem n8n Workflow

Das ist keine Wertung. Es ist eine Kategorisierung. Und genau darum geht es mir in diesem Post: Wann greife ich zu welchem Werkzeug – und warum?

Was "stabil" bedeutet

Klassische Automatisierung – also regelbasierte Systeme, Skripte, Code-Nodes, Regex – arbeitet deterministisch. Gleiche Eingabe, gleiches Ergebnis. Immer. Das klingt langweilig, ist aber in vielen Kontexten genau das, was ich brauche.

Nehmen wir ein konkretes Beispiel aus der Forschung: Bei der Extraktion von BI-RADS-Scores aus radiologischen Berichten (Röntgenbilder) wurde Regex direkt mit LLMs verglichen [1]. Die Genauigkeit? Nahezu identisch. Der Unterschied: Regex war 28.120-mal schneller. Nicht ein bisschen schneller. 28.000-mal. Das ist kein akademisches Detail – das ist ein Architektur-Argument.

Stabile Automatisierung ist auch aus Sicht der Betriebskosten attraktiv. Ein Code-Node in n8n kostet mich nichts extra. Ein LLM-Aufruf schon. Und bei jedem Zyklus wieder. Wer Workflows mit hohem Durchsatz betreibt, merkt das am Ende des Monats.

Was klassische Automatisierung braucht: saubere, strukturierte Daten und klar definierte Regeln. Wenn ich weiß, was rein geht und was raus kommen soll, ist ein Code-Node die überlegene Wahl. Keine Überraschungen, keine Halluzinationen, kein Token-Verbrauch.

Was "volatil" bedeutet – und warum das kein Fehler ist

KI ist nicht instabil. KI ist in einer gewissen Weise kreativ (KI im Sinne von Generative KI). Das ist ein wichtiger Unterschied.

Wenn ich einem AI Agent eine Aufgabe gebe, bekomme ich nicht zwingend das identische Ergebnis bei identischer Eingabe. Das klingt nach Nachteil – ist aber oft genau das, was ich brauche. Nämlich dann, wenn:

die Eingabedaten unstrukturiert sind (Freitexte, E-Mails, PDFs ohne Schema)
ich keine vollständigen Regeln definieren kann, weil die Varianz zu groß ist
ich Kontext und Intention verstehen muss, nicht nur Muster matchen

Ein Beispiel: Ich möchte eingehende Support-Anfragen automatisch kategorisieren und priorisieren. Kein Regex der Welt kommt damit klar, wenn Kunden auf zwölf verschiedene Arten schreiben, dass ihr Shop-Login nicht funktioniert. Ein LLM versteht das – auch in holprigem Deutsch, mit Rechtschreibfehlern und ohne klare Struktur.

Das ist die Stärke der volatilen Seite. Kein Regelbuch nötig. Dafür: Laufzeitkosten, potenziell variierende Ergebnisse und – wichtig – höherer Ressourcenverbrauch.

Das Demokratisierungsproblem

Hier wird es interessant – und ehrlich gesagt auch ein bisschen heikel.

KI-Tools haben die Automatisierung demokratisiert. Wer früher einen Entwickler brauchte, um einen Workflow zu bauen, kann heute in n8n einen AI Agent hinwerfen, einen Prompt schreiben und loslegen. Das ist großartig. Im Prinzip.

In der Praxis sehe ich aber immer häufiger, dass Nicht-Techniker – und leider auch manche Dienstleister – AI Agents einsetzen, wo ein einfacher Code-Node die bessere Lösung wäre. Nicht aus Böswilligkeit, sondern weil:

Der AI Agent "einfach funktioniert" – zumindest beim ersten Test
Die Kosten und Konsequenzen erst später sichtbar werden
Das Verständnis fehlt, was unter der Haube passiert

Konkret: Wer eine Bestellbestätigung per E-Mail versendet und dafür einen LLM-Aufruf macht, weil "das KI kann", zahlt sinnlose Token-Kosten für eine Aufgabe, die ein Template mit drei Variablen in Millisekunden löst. Sicher ist das nicht zwingend teuer – aber es skaliert schlecht. Und es ist fehleranfälliger: Was, wenn das Modell mal kreativ wird und den Inhalt der E-Mail leicht variiert?

Noch kritischer wird es bei sicherheitsrelevanten Prozessen. KI-generierter Output ist kein deterministischer Output. Wer das in Berechtigungsprüfungen einbaut, ohne das zu verstehen, baut sich ein Problem auf Vorrat.

Schon im Jahr 2020 haben Kollegen von mir bei einer Studie in Deutschland große Defizite bei Expertise zu KI, Prozessoptimierung und Automatisierung [2] festgestellt. Ob wir jetzt in 2026 viel besser darstehen?

Ressourcen, Kosten, Geschwindigkeit

Ein paar Zahlen, die ich im Hinterkopf behalte:

Ein einfacher Code-Node: nahezu keine Laufzeitkosten, Ausführung in Millisekunden
Ein LLM-Aufruf via API: Token-Kosten, die sich bei hohem Durchsatz summieren – und das nicht linear, sondern kumulativ, weil bei Multi-Turn-Konversationen der gesamte Verlauf mitbezahlt wird
Reasoning-Modelle (die mit explizitem "Thinking"): bis zu 50-facher CO₂-Ausstoß gegenüber kompakten Modellen – für oft marginale Genauigkeitsgewinne [3]

Das bedeutet nicht, KI zu vermeiden. Es bedeutet, bewusst zu wählen. Brauche ich wirklich ein Reasoning-Modell für das Taggen von Blog-Posts? Nein. Reicht ein kleineres, schnelles Modell für die Sentiment-Klassifikation von Kundenbewertungen? Ja, in den meisten Fällen.

In meinem privaten n8n habe ich die Metriken immer im Blick.

Dashboard in Grafana

Die meisten meiner n8n Prozesse sind immer noch klassisch ohne KI oder nur an gewissen Stellen mit KI ergänzt. Es gibt aber auch Workflows die nur auf KI basieren.

Wann ich zur KI muss

Es gibt Aufgaben, bei denen ich mit klassischer Automatisierung schlicht nicht weiterkomme:

Unstrukturierte Eingaben verstehen – Freitexte, OCR-Ergebnisse, gescannte Dokumente
Inhaltliche Bewertung – Ist diese Produktbeschreibung vollständig? Klingt dieser Text professionell?
Kontextabhängige Entscheidungen – Was ist die passende Antwort auf diese Kundenfrage, abhängig von Bestellhistorie und aktuellem Kontext?
Kreative Aufgaben – Texte generieren, variieren, übersetzen, zusammenfassen

Für alles davon gibt es keine Regex. Kein if-else-Baum wächst hoch genug. Hier ist KI nicht die bequeme Option – sie ist die einzig sinnvolle.

Der hybride Weg: Determinismus als Leitplanke

Meine persönliche Architektur-Präferenz sieht so aus: deterministischer Rahmen, KI dort wo nötig [4].

In n8n bedeutet das konkret: Ich prüfe zuerst, ob ich ein Problem regelbasiert lösen kann. Wenn ja, Code-Node. Wenn nein, AI Agent – aber mit klaren Leitplanken: definierten Eingabeformaten, validierten Ausgaben, und einem deterministischen Weiterverarbeitungsschritt danach.

Das Diagramm am Anfang dieses Posts zeigt genau das: Beide Wege laufen in denselben Output. Ich entscheide pro Aufgabe, welcher Pfad sinnvoller ist. Das ist keine Entweder-oder-Frage. Es ist eine Designentscheidung.

Wo steckt bei mir überall KI drin?

Wichtig finde ich auch, dass man seine KI-Prozesse im Blick hat. Auch diese benötigen eine Wartung und müssen immer mal wieder angepasst werden. Gerade, wenn neue Modelle auf den Markt kommen.

In meinen Fall habe ich verschiedene Dashboards in meinen Grafana erstellt. Unter anderem eines, dass mir eine Übersicht der in den n8n Workflows genutzten Modelle und Provider bietet.

Metriken in n8n

Gelöst habe ich das über einen n8n Workflow der mir täglich alle anderen Workflows analyisiert und die Metadaten dann in meiner Postgres Datenbank abgelegt.

Eine weiterer wichtiger Teil ist, dass man seine KI Modelle auch mit Testdaten testet. Dazu gibt es aber bestimmt mal einen eigenen Blog-Post von mir.

Fazit

KI ist kein Allheilmittel – und klassische Automatisierung ist kein Relikt. Beides hat seinen Platz. Die Kunst liegt darin zu erkennen, welches Werkzeug für welche Aufgabe geeignet ist [5].

Was mich bei der aktuellen Entwicklung beschäftigt: Immer mehr Menschen automatisieren, ohne die Implikationen zu verstehen. Das ist erst mal gut – Automatisierung ist wichtig. Aber die Wahl des falschen Werkzeugs produziert Systeme, die teurer, langsamer, fehleranfälliger und schwerer wartbar sind als nötig.

Meine Faustregel: Wenn ich das Problem vollständig beschreiben kann, brauche ich keine KI. Wenn nicht – dann schon.

Literatur

[1] Lacoste et al. (2025): A Comparative Performance Analysis of Regular Expressions and an LLM-Based Approach to Extract the BI-RADS Score from Radiological Reports. medRxiv.
https://www.medrxiv.org/content/10.1101/2025.06.01.25328636v1.full-text

[2] valantic (2020): Exklusive valantic-Studie: Große Defizite bei Expertise zu KI, Prozessoptimierung und Automatisierung
https://www.valantic.com/de/presse/exklusive-valantic-studie-mit-luenendonk/

[3] ScienceDaily (2025): Thinking AI models emit 50x more CO2 — and often for nothing.
https://www.sciencedaily.com/releases/2025/06/250619035520.htm

[4] Elementum AI (2025): Deterministic vs. Probabilistic AI: Enterprise Workflow Guide.
https://www.elementum.ai/blog/deterministic-vs-probabilistic-ai

[5] ECI Software Solutions: AI vs. Automation: Why the Difference Matters for SMB Growth.
https://www.ecisolutions.com/blog/ai-vs-automation-smb-difference/

Claude Desktop unter Linux

2026-03-31T16:12:00+00:00

Ich arbeite seit Jahren auf Fedora. Linux ist für mich kein Experiment, sondern Alltag. Umso mehr hat es mich gestört, dass Anthropic Claude Desktop offiziell nur für macOS und Windows anbietet. Für Linux: Fehlanzeige.

Mein Kollege bei valantic, Patrick Schönfeld, hat das nicht einfach hingenommen. Er ist KI-Experte, Open-Source-Enthusiast – und jemand, der lieber Probleme löst als darüber redet.

Das Ergebnis: claude-desktop-bin

Hier ein Screenshot von meinem Fedora Desktop

Installation: Für jede Distribution

Patrick hat wirklich alle großen Distributionen bedacht. Kein halbgarer Single-Distro-Port.

Arch Linux / Manjaro

yay -S claude-desktop-bin

Updates kommen automatisch über den AUR-Helper – nichts weiter zu tun.

Debian / Ubuntu

Der empfohlene Weg über das APT-Repository bringt automatische Updates mit:

curl -fsSL https://patrickjaja.github.io/claude-desktop-bin/install.sh | sudo bash
sudo apt install claude-desktop-bin

Wer kein fremdes Install-Script ausführen möchte – das ist ein vollkommen legitimer Standpunkt – greift zum .deb direkt von den Releases:

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/claude-desktop-bin_1.1.5749-1_amd64.deb
sudo dpkg -i claude-desktop-bin_*_amd64.deb

Fedora / RHEL

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/claude-desktop-bin-1.1.4088-1.x86_64.rpm
sudo dnf install ./claude-desktop-bin-*-1.x86_64.rpm

NixOS

# Ausprobieren ohne Installation
nix run github:patrickjaja/claude-desktop-bin

# Dauerhaft ins Profil
nix profile install github:patrickjaja/claude-desktop-bin

Wer es direkt in die Systemkonfiguration übernehmen will:

{
  inputs.claude-desktop.url = "github:patrickjaja/claude-desktop-bin";

  environment.systemPackages = [
    inputs.claude-desktop.packages.x86_64-linux.default
  ];
}

AppImage (alle anderen)

wget https://github.com/patrickjaja/claude-desktop-bin/releases/latest/download/Claude_Desktop-1.1.5749-x86_64.AppImage
chmod +x Claude_Desktop-*-x86_64.AppImage
./Claude_Desktop-*-x86_64.AppImage

Cowork unter Linux

Cowork ist Anthropics agentic Workspace-Feature – Dateioperationen, Desktop-Automatisierung, Task-Management direkt vom Desktop aus. Auch hier: offiziell kein Linux-Support.

Patrick hat den Windows Service reverse-engineered und unter Linux lauffähig gemacht. Das Projekt: claude-cowork-service

Der Service ist optional. Claude Desktop funktioniert auch ohne Cowork. Wer ihn möchte:

# Schnellinstallation, jede Distribution
curl -fsSL https://raw.githubusercontent.com/patrickjaja/claude-cowork-service/main/scripts/install.sh | bash

# Arch Linux per AUR
yay -S claude-cowork-service
systemctl --user enable --now claude-cowork

Voraussetzung ist die Claude Code CLI – sie muss installiert und im Pfad erreichbar sein. Die Pfade /usr/bin/claude, ~/.local/bin/claude und /usr/local/bin/claude werden automatisch erkannt.

Was dahintersteckt

Das ist kein Quick-Port. Das Paket enthält eine ganze Reihe gezielter Patches, die aus Claude Desktop – einer Electron-App, primär für macOS entwickelt – eine funktionale Linux-Anwendung machen. Tray-Icon-Integration, DBus-Handling, MCP-Server-Support, Computer Use via xdotool und scrot – alles dabei.

Ein automatisierter CI-Job prüft täglich auf neue Claude-Desktop-Versionen, validiert alle Patches in Docker und stellt sicher, dass nur funktionierende Builds ins AUR kommen. Das ist solide Arbeit.

Ein Hinweis für Wayland-Nutzer: Der globale Shortcut (Ctrl+Alt+Space) funktioniert nur unter X11. Wer auf einem Wayland-Compositor unterwegs ist, startet Claude Desktop so:

claude-desktop --ozone-platform=x11

Das lässt sich auch dauerhaft in der .desktop-Datei eintragen.

Fazit

Es ist inzwischen ein bekanntes Muster: Hersteller ignoriert Linux, Community oder engagierte Entwickler wie mein Kollege Patrick übernehmen.

Danke, Patrick – für die Arbeit, die da drin steckt. Das Ergebnis ist wirklich brauchbar.

Habt ihr Claude Desktop unter Linux schon ausprobiert? Auf welcher Distribution läuft es bei euch?

Update 7. April 2026

Ich habe den Text nach Feedbacl von Patrick nochmal angepasst. Bei RPMs und AppImage hatte ich geschrieben, dass es keine automatischen Update gibt. Das war nicht korrekt. Patrick hat auch für diese Installationen ein automatisches Update bereitgestellt.

Rückblick: Magento Stammtisch Stuttgart – Remote dabei mit mage-remote-run

2026-03-27T07:00:00+00:00

Am 25. März 2026 fand der Magento Stammtisch Stuttgart statt – und ich war dabei. Nicht vor Ort, wie ich es mir gewünscht hätte, sondern von zuhause aus. Eine Erkältung hat mir einen Strich durch die Reisepläne gemacht. Zum Glück war eine Remote-Teilnahme möglich, und so konnte ich trotzdem meinen Beitrag über mage-remote-run halten ... ganz schön viel "remote" :-)

Persönlich vor Ort zu sein hat natürlich einen anderen Charakter. Die spontanen Gespräche am Rande, das gemeinsame Abendessen, das Netzwerken beim Getränk in der Hand – das lässt sich nicht durch einen Video-Call ersetzen. Aber die Community hat das unkompliziert möglich gemacht, und dafür bin ich dankbar.

Mein Beitrag: mage-remote-run in der Praxis

Ich habe mage-remote-run vorgestellt – mein Tool für die Remote-Verwaltung von Magento-Instanzen ohne SSH-Zugriff. Gerade in Cloud-nativen Umgebungen wie Adobe Commerce as a Cloud Service oder abgesicherten Kubernetes-Clustern stößt man schnell an Grenzen, wenn man gewohnte Shell-Werkzeuge einsetzen will. mage-remote-run setzt deshalb konsequent auf einen API-first-Ansatz und kommuniziert über HTTPS mit dem Shop.

Die Vorstellung beim Stammtisch gibt es als Video – ich verlinke es hier, sobald es verfügbar ist.

Neu war das Plugin-System in mage-remote-run, dass ich erstmals beim Stammtisch vorstellen konnte.

MageForge: Ein Build-Tool für Frontend-Entwickler

Mathias Elle, Magento- und Hyvä-Frontend-Experte, hat zusammen mit Thomas Hauschild an MageForge gearbeitet und beim Stammtisch vorgestellt, was dahintersteckt. MageForge ist ein Tool, das speziell auf die Bedürfnisse von Frontend-Entwicklern im Magento-Ökosystem ausgelegt ist – mit dem Fokus auf Build-Prozesse.

Wer schon mal mit Hyvä gearbeitet hat, weiß, dass der Frontend-Stack dort deutlich moderner ist als im klassischen Magento. Genau da setzt MageForge an: Es soll die Build-Workflows vereinfachen und beschleunigen, ohne dass man tief in die Konfigurationsdetails einsteigen muss. Ich bin gespannt, wie sich das Tool weiterentwickelt – das ist genau die Art von pragmatischer Tooling-Arbeit, die der Community gut tut.

Auch in einer CI/CD Pipeline oder beim Reparieren von kaputten Frontend-Setups kann das Tool gute Dienste leisten.

Beeindrucken ist auch, dass es auf dem höchsten PhpStan-Level getestet wurde.
Weil es so gut ist, wird es in der nächsten n98-magerun2 Version ein neues Kommando mageforge:install geben damit ihr es schnell in euer Magento System installieren könnt.

Claude-AI-Benchmarks: Wie sehr machen Regeln den Unterschied?

Anton Gudkov, Magento-zertifizierter Entwickler, hat sich mit einem Thema beschäftigt, das mich ebenfalls intensiv begleitet: dem Einsatz von Claude-AI-Modellen in der Entwicklung. Kudos auch dafür, dass er beim Stammtisch seinen ersten Vortrag hielt. Sein Fokus lag auf einem konkreten und spannenden Aspekt – dem Benchmark unterschiedlicher Einstellungen und Regelwerke.

Die Kernfrage: Wie stark beeinflussen die Konfiguration und die definierten Regeln das Ergebnis, das ein Modell wie Claude liefert? Das ist etwas, was in der Praxis oft unterschätzt wird. Man gibt dem Modell einen Prompt, bekommt eine Antwort – und denkt wenig darüber nach, was passiert, wenn man die Rahmenbedingungen systematisch variiert. Anton hat genau das gemacht und die Ergebnisse verglichen.

Mein Fazit (aus der Ferne): Das ist wertvolle Arbeit. Gerade wenn man KI-Modelle in bestehende Entwicklungsprozesse integriert, lohnt es sich, diese Stellschrauben zu verstehen – und nicht einfach mit den Standardeinstellungen zu leben.

Ich hoffe, beim nächsten Mal persönlich dabei zu sein. Stuttgart wäre es wert gewesen. Danke an Phoenix Media für die wie immer tolle Orga.