muench.dev Articles

Hindsight: Ein Agent-Memory-System, das mich begeistert hat

2026-08-27T07:00:00+00:00

Jeder, der täglich mit Claude Code, Codex CLI oder opencode arbeitet, kennt das Problem: Der Agent ist am Ende jeder Session wieder bei null. Man erklärt zum gefühlt zehnten Mal den Tech-Stack, die Team-Konventionen, warum man Redis-Caching vor drei Monaten wieder verworfen hat. Notizen in System-Prompts oder CLAUDE.md-Dateien helfen, skalieren aber nicht – sie erfassen keine gewachsene, sich verändernde Wissensbasis, sondern nur einen statischen Snapshot.

Ich bin seit ein paar Wochen mit Hindsight unterwegs, einem Open-Source-Memory-System von Vectorize.io, und bin ziemlich angetan. Oder sagen wir es wie es ist. Ich bin seit langem mal wieder richtig begeistert von einer Software-Lösung gewesen. Es macht genau das, was man sich unter "Agent-Gedächtnis" vorstellt, wenn man es nicht auf die naive Vektor-DB-Lösung reduziert. Es haben sich für mich gedanklich aber auch technisch neue Welten aufgetan.

Warum sollte man Hindsight nutzen?

Bevor ich in die technischen Details gehe, kurz die drei Gründe, die für mich den Ausschlag gegeben haben:

Erhöhte Kontextkontinuität: Agenten behalten relevantes Vorwissen über Sessions hinweg und liefern dadurch konsistente, personalisierte Empfehlungen – statt bei jeder neuen Session wieder bei null anzufangen.
Bessere Genauigkeit bei komplexen Fragen: Temporal- und Graph-Retrieval kombiniert mit automatischer Beobachtungs-Konsolidierung erhöhen die Trefferquote spürbar, gerade bei historischen oder indirekt verknüpften Fakten.
Kontrollierte, erklärbare Erinnerungs-Logik: Missionen und Direktiven schaffen Sicherheits- und Compliance-Guardrails, Evidenz-Tracking macht nachvollziehbar, worauf eine Antwort eigentlich basiert.

Was Hindsight ist – und was nicht

Der wichtigste Punkt zuerst: Hindsight ist keine reine Vektor-Datenbank mit hübscher API drumherum. Wer Rohdaten reinwirft und hofft, dass Cosine-Similarity am Ende die richtige Antwort liefert, wird von naiven RAG-Ansätzen regelmäßig enttäuscht. Sobald man ein paar hundert Memories über verschiedene Themen und Zeiträume hat, bricht das Prinzip "Embed alles, hol dir Top-K" oft zusammen.

Hindsight geht einen anderen Weg. Im Hintergrund läuft PostgreSQL mit der pgvector-Extension als Speicher, aber was aber genutzt wird, sind nicht die Rohdaten, sondern das Ergebnis eines Extraktionsprozesses: strukturierte Fakten, aufgelöste Entitäten (aus "Alice" und "meine Kollegin Alice" wird ein und dieselbe Entität), Zeitstempel für temporale Auswertungen und ein Wissensgraph, der die Beziehungen zwischen den Entitäten abbildet. Wer jetzt angst um seine Daten hat... ok, es sind auch die Dokumente in der Postgres Datenbank weiterhin gespeichert als "Document". Aber die reinen Dokuemten sind eben in dem gesamten Prozess nicht das spannende sondern die aufbereiteten Daten.

Angebunden wird das Ganze über MCP – Claude Code, Codex, opencode, Cursor, VS Code, praktisch jeder MCP-fähige Client kann sich verbinden. Für die interne Verarbeitung (Fakten-Extraktion, Entity-Resolution, Reflect-Operationen) braucht Hindsight einen eigenen LLM-Provider – unabhängig vom Modell, das der eigentliche Agent nutzt. Das ist ein Detail, das mir gut gefällt: Man kann hier bewusst ein günstiges, schnelles Modell einsetzen, weil diese Verarbeitung im Hintergrund läuft und nicht die Qualität der eigentlichen Agent-Antworten beeinflusst. Ich habe für meine Tests das GPT-5.6 Luna Modell verwendet, weil es erstmal auf meine private Rechnung lief. Trotz des günstigen Modells habe ich aber richtig gute Ergebnisse bekommen. Man kann in Hindsight aber auch mehrere Modelle nutzen und falles feintunen. Ich habe ehrlicherweise bisher vielleicht 30-40% der Funktionen ausprobiert. Aber das macht nichts. Man bekommen einfach schnell Ergebnisse und kann mit den Daten arbeiten und auch selbst die Daten verbessern. Wie? Das kommt jetzt.

Die drei Kernoperationen

Hindsight bietet drei zentrale Operationen, die als MCP-Tools zur Verfügung stehen:

retain – Speichern. Man füttert Hindsight mit Text (eine einzelne Tatsache, eine ganze Konversation, ein Dokument), und im Hintergrund extrahiert ein LLM strukturierte Fakten, löst Entitäten auf, erzeugt Embeddings und indiziert alles für die spätere Suche. Wichtig: Man sollte nicht vorab selbst zusammenfassen oder Fakten extrahieren – Hindsight braucht den vollen Kontext einer Konversation, sonst wird aus "ja, genau" oder "ich nehme Option 2" schlicht bedeutungsloser Text.

recall – Suchen. Hier laufen vier Retrieval-Strategien parallel: semantische Suche, BM25-Keyword-Matching, Graph-Traversal über den Wissensgraphen und temporale Filterung. Die Ergebnisse werden anschließend per Cross-Encoder-Reranking sortiert. Das ist der eigentliche Clou gegenüber einer simplen Vektorsuche: Eine Frage wie "Was haben wir zum Caching entschieden?" findet die richtige Antwort auch dann, wenn die ursprüngliche Memory eine andere Terminologie verwendet.

reflect – Synthetisieren. Reflect geht über reines Abrufen hinaus und lässt ein LLM über mehrere Memories hinweg Schlüsse ziehen – etwa auf die Frage "Welchen Tech-Stack würdest du mir basierend auf meinen bisherigen Entscheidungen empfehlen?".

flowchart LR    
    subgraph YourApp["Your Application"]
        A["AI Agent"]
    end

    subgraph Hindsight["Hindsight"]
        API["API Server"]

        subgraph MemoryBank["Memory Bank"]
            direction TB
            MM["Mental Models"]
            OBS["Observations"]
            ME["Memories & Entities"]
            CH["Chunks"]
            DOC["Documents"]

            MM --> OBS
            OBS --> ME
            ME --> CH
            CH --> DOC
        end
    end

    A -->|retain| API
    A -->|recall| API
    A -->|reflect| API

    API --> ME

Extraktionsstrategien und Tagging

Ein Punkt, der in der Praxis unterschätzt wird: Nicht jede Datenquelle soll gleich verarbeitet werden. Hindsight bietet dafür benannte Retain-Strategien – etwa verbatim für Inhalte, die wortwörtlich gespeichert werden sollen, oder chunks für größere Dokumente, die in Abschnitte zerlegt werden. Diese Strategien lassen sich in der Bank-Konfiguration definieren und dann je nach Quelle gezielt beim retain-Aufruf auswählen.

Dazu kommt ein Tagging-System mit sogenannten Entity Labels: kontrollierte Vokabulare nach dem Schema key:value, etwa user:christian oder topic:architektur, die beim Speichern automatisch extrahiert werden können. Für die reine inhaltliche Suche braucht man das oft gar nicht – Entitäten landen ohnehin im Wissensgraph und treiben die Graph-basierte Suche an. Für explizite Filterung auf entitätsähnliche Werte sind die Tags aber Gold wert, gerade wenn man mehrere Projekte oder Kunden in einer Bank sauber getrennt halten will.

Mental Models: lebende Dokumente

Was mich am meisten überzeugt hat, sind die Mental Models. Man definiert eine Frage – zum Beispiel "Welche Architekturentscheidungen wurden für Projekt X getroffen?" – und Hindsight erzeugt daraus ein Dokument, das sich automatisch aktualisiert, sobald neue Memories dazukommen oder sich bestehende Dokumente ändern. Man muss also nicht bei jeder Anfrage ein volles reflect über den kompletten Memory-Bestand laufen lassen, sondern bekommt eine Art vorberechnete, immer aktuelle Zusammenfassung.

Technisch läuft das asynchron über eine Queue: Die eigentliche LLM-gestützte Generierung passiert im Hintergrund, ein API-Aufruf liefert zunächst nur eine Operation-ID zurück, das fertige Ergebnis ist dann nach ein paar Sekunden abrufbar. Das ist konsequent zu Ende gedacht, hat aber auch eine Kehrseite, dazu gleich mehr.

Skalieren ist auch kein Problem, denn es gibt im Konzept auch Worker-Instanzen die dann auch per Kubernetes skaliert werden können. Das ist alles möglich. In meinem Homelab Setup tut es auch ein einzelner Worker in einem fixen Docker-Container.

Visualisierung

Im Control Plane – dem Admin-UI von Hindsight – gibt es die sogenannte Constellation View: eine interaktive, zoombare Graphdarstellung der Entity-Relationships mit Heat-Gradient-Einfärbung, auch im Dark Mode nutzbar. Für mich ist das mehr als nur ein nettes Feature – bei einem wachsenden Wissensgraphen hilft die visuelle Übersicht enorm dabei, ein Gefühl dafür zu bekommen, was die eigene Memory-Bank eigentlich "weiß" und wo die Extraktion vielleicht danebenliegt.

Natürlich kann man auch filtern, zoomen und auf die einzelnen dahinterliegenden Dokumente schauen.

Features im Überblick

Ein paar Punkte aus der Gesamtliste, die im Artikel bisher noch nicht vorkamen, aber zum Verständnis dazugehören:

Hierarchische Memory-Typen: Neben Mental Models (kuratierte, selbst definierte Zusammenfassungen) gibt es Observations – automatisch aus Rohfakten konsolidierte, evidenzgestützte Glaubenssätze –, außerdem World Facts und Experience Facts. Diese Trennung sorgt dafür, dass reflect bei der Beantwortung einer Frage zuerst die Mental Models prüft, dann die Observations und erst zuletzt auf Rohfakten zurückgreift.
Multi-Strategie-Retrieval (TEMPR): Die vier parallelen Suchstrategien aus recall – Semantic, Keyword/BM25, Graph, Temporal – laufen unter dem Namen TEMPR und werden per Reciprocal-Rank-Fusion zusammengeführt, bevor das Cross-Encoder-Reranking greift. Das macht den Abruf auch bei zeitlich oder graphbasiert verknüpften Fragen robust.
Observation Consolidation: Nach jedem retain-Aufruf läuft im Hintergrund automatisch ein Konsolidierungsprozess, der neue Fakten gegen bestehende Observations abgleicht, dedupliziert und mit Evidenz-Verweisen versieht. Beobachtungen, die durch neuere, noch nicht konsolidierte Fakten überholt sein könnten, werden dabei als "stale" markiert und vor der Nutzung gegen die Rohfakten verifiziert.
Temporal Reasoning: Abfragen wie "letzten Frühling" oder "im Juni" werden nicht nur semantisch, sondern explizit zeitbasiert aufgelöst – ein Bereich, in dem reine Vektorsuche typischerweise versagt.
Missions- und Richtlinien-Konfiguration: Auf Bank-Ebene lässt sich eine Mission definieren, die vorgibt, welches Wissen priorisiert werden soll, dazu unveränderliche Direktiven als Compliance-Guardrails und Disposition-Traits wie Skepsis, Literalität oder Empathie, die beeinflussen, wie reflect Argumente gewichtet. Wichtig: Diese Einstellungen wirken nur auf reflect, nicht auf recall.
Evidenz-gestützte Antworten: Observations verweisen auf ihre Quell-Memories inklusive Zitat-Belegen und Proof-Counts – das macht die Herleitung einer Antwort nachvollziehbar, statt sie als Black Box hinzunehmen.
Clients & SDKs: Offizielle SDKs für Python, TypeScript und Go, dazu CLI und HTTP-API – die Integration in bestehende Agent-Stacks jenseits von MCP ist damit unkompliziert.
Deployment-Optionen: Neben dem lokalen Docker-Setup, wie ich es im Homelab nutze, gibt es Helm-Charts für Kubernetes, eine pip-Installation für den schnellen lokalen Test sowie einen Integrations-Hub für angebundene Datenquellen.

Wie kommen Daten ins System?

Daten können auf verschiedenen Wegen in das Memory gelangen. Wird der MCP-Server genutzt kann einfach über das retain Tool etwas gespeichert werden. Bei jedem erfassten Dokumente können Tags und eine eindeutige Document-ID definiert werden. Das definieren der Document-ID ist optional. Wird keine mitgesendet, erstellt das System eine UUID.
Wenn man Rohdaten z.B. Chatverläuft speicher will, dann reicht es die generierte UUID zu verwenden. Wenn es Daten wie z.B. der Inhalt hinter Webseite sind, dann kann die Document-ID auch eine URL sein. Wird mit der gleichen Document-ID ein neues Dokument gesendet, dann aktualisiert Hindsight auch den bestehenden Eintrag.
Zusätzlich lassen sich in Hindsight auch für verschiedene Quellen dann unterschiedliche strategien für das extrahieren der Daten definieren. Man kann dann auch Einfluss auf die RAG spezifischen Parameter wie die Chunk-Size nehmen.

Da Hindsight durchgängig so konzipiert wurde, dass alles was die UI macht über eine REST-API kommuniziert, ist es auch ein einfaches die gleiche API für das importieren von Daten zu nutzen.
Beispielhaft habe ich mal ein n8n Community Plugin installiert, dass einfach die drei Grundopterationen in einem n8n Node abbildet.

Mein Setup im Homelab

Ich habe mir das Ganze nicht in der Cloud, sondern in meinem Homelab aufgesetzt – zwei LXC-Container, einer für die API, einer für das Admin-UI beziehungsweise Control Plane. Die Datenbank musste ich nicht neu aufsetzen: Ich hatte bereits einen PostgreSQL-Server mit pgvector-Extension laufen und musste dort nur eine zusätzliche Datenbank anlegen. Das hat das Setup deutlich vereinfacht – wer schon eine Postgres-Instanz mit pgvector betreibt, ist hier in Minuten startklar, statt sich mit der eingebetteten PostgreSQL-Variante aus dem Docker-Quickstart herumzuschlagen.

Als LLM-Provider für die interne Verarbeitung habe ich schnell OpenRouter angebunden und dort auf GPT-5.6 Luna gesetzt – die günstige, latenzoptimierte Variante aus OpenAIs GPT-5.6-Serie, gedacht für genau solche hochfrequenten, aber nicht sonderlich anspruchsvollen Hintergrundaufgaben wie Fact-Extraction. Das Modell lässt sich aber problemlos austauschen: Hindsight unterstützt eine breite Auswahl an Providern, von OpenAI über Anthropic und Gemini bis zu lokalen Modellen über Ollama oder llama.cpp. Wer die interne Verarbeitung lieber komplett offline und ohne externe API-Calls fahren will, kann das inzwischen ebenfalls tun.

Integration in andere Systeme

Über MCP lässt sich Hindsight praktisch überall andocken, wo ein Client den Standard spricht – Claude Code, Codex CLI, opencode und weitere Coding-Agents sind direkt unterstützt, teils sogar mit automatischer Ingestion ohne zusätzlichen Setup-Schritt.

Der MCP Server ist direkt in Hindsight enthalten und kann für jede Memory-Bank einzeln eingestellt werden. Man kann auch die MCP-Tools beschränken.

Ich habe bei mir nichts beschränkt da ich sowieso noch einen zwischengeschalteten LiteLLM-Gateway habe.

Use Cases

Der naheliegendste Use Case für mich persönlich ist gar nicht primär technisch: Ich möchte Daten rund um den Fußballverein Wormatia Worms aufbereiten, um die Mitarbeiter in der Geschäftsstelle zu entlasten. Statt jede Anfrage manuell zu beantworten, könnte ein Agent auf einer Hindsight-Bank mit historischen Informationen, Vereinsregeln und wiederkehrenden Fragen aufsetzen und so einen echten Teil der Kommunikationslast abnehmen.

Daneben baue ich gerade eine zweite, eigene Bank auf: Dort arbeite ich die Vereinschronik, Saisonergebnisse und Spieler-Steckbriefe ein. Das Interessante hier ist nicht der reine Abruf einzelner Fakten, sondern dass das System selbstständig statistische Besonderheiten und Zusammenhänge über die eingespielten Daten hinweg entdecken soll – etwa, dass eine bestimmte Saison auffällig viele Unentschieden hatte oder ein Spieler in mehreren Spielzeiten überdurchschnittlich oft getroffen hat. Genau dafür ist reflect gedacht: nicht nur Fakten abrufen, sondern über den gesamten Datenbestand hinweg Schlüsse ziehen. Besonders spannend wird das für den Archivar des Vereins, der Fragen stellen möchte wie "Wann war die längste Siegesserie?" – Fragen, die kein einzelner Datensatz beantwortet, sondern die erst aus der Zusammenschau vieler Saisonergebnisse entstehen.

Im technischen Projektumfeld sehe ich mindestens zwei weitere sinnvolle Einsatzszenarien:

Architektur- und Richtlinien-Gedächtnis: Ein Agent, der Softwarearchitektur-Entscheidungen, Coding-Guidelines und Projektkonventionen im Blick behält und Entwicklern direkt im Coding-Tool als Frage-Antwort-Instanz zur Verfügung steht – ohne dass diese erst in einem Wiki suchen müssen.
Vollständigkeitsprüfung bei Anforderungen: In Projekten, in denen Anforderungen laufend erfasst werden, kann ein Agent mit Zugriff auf die gesammelten Memories prüfen, ob alle notwendigen Dokumente und Informationen vorliegen, und gezielt auf Lücken hinweisen. Gerade in Business-Kontexten mit vielen Stakeholdern ist das ein Szenario, das echten Mehrwert liefert.

Beurteilung

Was gut funktioniert: Der Einstieg ist erfreulich niedrigschwellig, insbesondere wenn – wie in meinem Fall – schon eine Postgres/pgvector-Instanz vorhanden ist. MCP als Anbindungsstandard bedeutet, dass man nicht für jeden Client eine eigene Integration bauen muss. Die Kombination aus Multi-Strategy-Retrieval und Reranking liefert in der Praxis spürbar bessere Trefferqualität als eine simple Vektorsuche, gerade bei größeren, thematisch gestreuten Memory-Beständen.

Gibt es bei dem Ansatz auch Dinge die mich stören? Nicht wirklch, aber man sollte sich bewusst sein, dass mit der steigenden Anzahl an Informationen und mit jedem Mental Model auch der Aufwand steigt alles aktuell zu halten. Es können schon einige Token-Kosten entstehen.
Jede retain-Operation bedeutet zusätzliche LLM-Calls für die interne Verarbeitung, das summiert sich bei hohem Volumen. Und der Reifegrad des Ökosystems ist noch nicht in Stein gemeißelt. Integrationen können sich relativ kurzfristig ändern.

Hier kommt es einfach darauf an ob man den Context/Memory auch als Wert für sich entdeckt hat.

Business-Ausblick

Für ein Projekt-Umfeld wie ich es bei valantic kenne sehe ich den größten Hebel darin, dass Agenten über Sessions hinweg Projektkontext, Kundenpräferenzen und getroffene Architekturentscheidungen behalten. Das bedeutet, dass weniger Zeit für wiederholte Kontext-Vermittlung, mehr Zeit für die eigentliche Wertschöpfung vorhanden ist. Das ist ein handfester Produktivitätsgewinn, gerade in längeren Projekten mit wechselnden Ansprechpartnern.

Gleichzeitig darf man die Governance-Frage nicht ausblenden: Wo landen die extrahierten Fakten, wer hat Zugriff auf die Memory-Bank, wie sauber lässt sich zwischen Kunden oder Projekten trennen? Self-Hosting via Docker beziehungsweise, wie in meinem Fall, im eigenen Homelab per LXC-Container ist hier eine valide Antwort – man behält die volle Kontrolle über die Daten, statt sie einem Cloud-Anbieter anzuvertrauen.

Fazit

Hindsight ist das erste Agent-Memory-System, das mich wirklich direkt begeistert hat, weil es Memory nicht auf "Text in eine Vektor-DB werfen" reduziert, sondern strukturierte Fakten, Entitäten, Zeitbezug und einen Wissensgraphen kombiniert. Das Setup im eigenen Homelab war dank vorhandener Postgres/pgvector-Infrastruktur überraschend unkompliziert, und die Kombination aus MCP-Standard und flexibler LLM-Provider-Wahl macht das System für sehr unterschiedliche Einsatzszenarien interessant – vom Vereinsalltag bei Wormatia Worms bis zum Architektur-Gedächtnis in technischen Projekten. Ich werde das in den kommenden Wochen weiter ausbauen und berichte, sobald sich daraus konkrete Workflows ergeben haben.

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.