Agentic AI im eCommerce: was es bedeutet und wie du es auf Rails und Solidus baust

Was "agentic" wirklich heißt, ohne Fachchinesisch

Alle paar Jahre erobert ein Wort die Techbranche und klebt danach auf allem. 2023 war es "generativ". 2024 war es "Copilot". 2025 und 2026 ist es "agentic". Die meisten, die es benutzen, könnten es nicht erklären, wenn man sie direkt fragt. Also erkläre ich es, in einfachen Worten.

Ein KI Agent ist Software, die auf ein Ziel hin plant, entscheidet und handelt, ohne dass ein Mensch ihr jeden Schritt vorgibt. "Agentic" heißt, sie hat Handlungsfreiheit. Sie trifft Entscheidungen selbst, innerhalb der Grenzen, die du ihr setzt.

Ein Vergleich hilft.

Ein Chatbot ist wie eine Kellnerin. Sie bringt deine Bestellung in die Küche und kommt mit dem zurück, was du bestellt hast. Dass der Küche der Lachs ausgeht, bemerkt sie nicht, und sie schlägt dir auch nicht das Hähnchen vor. Sie macht, was du sagst, eine Frage, eine Antwort.

Eine Automatisierungsregel ist wie die Zeitschaltuhr am Backofen. Sie schaltet jeden Tag um 18 Uhr ab, ob etwas drin ist oder nicht. Eine feste Regel, ohne jedes Gespür für die Lage.

Ein KI Agent ist wie die Restaurantleiterin. Sie sieht, dass die Vorräte knapp werden, und bestellt nach. Sie merkt, dass Tisch fünf zu lange wartet, und schickt jemanden hin. Sie sieht, dass der Lachs heute Abend nicht läuft, und ändert die Tafel mit den Tagesgerichten. Dutzende Entscheidungen an einem Abend, jede auf Grundlage dessen, was gerade wirklich passiert.

Technisch läuft ein Agent in einer Schleife aus vier Schritten.

Das Diagramm liest sich von oben nach unten: Der Agent schaut hin, denkt nach, handelt, prüft, was passiert ist, und fängt mit diesem Wissen von vorn an. In dieser Schleife liegt der ganze Unterschied. Ein Chatbot wartet auf eine Eingabe, antwortet und hört auf. Keine Schleife, keine Eigeninitiative. Ein Chatbot reagiert, ein Agent handelt von sich aus.

Ein Beispiel: Eine Kundin von Fleetblick Tee, einem erfundenen Onlineshop für Tee in Hamburg, fragt den Chatbot des Shops "Wo ist meine Bestellung?" und bekommt den Link zur Sendungsverfolgung. Das ist reaktiv. Der Agent des Shops hat in der Zwischenzeit längst gesehen, dass der Scan beim Paketdienst einen Tag zu spät kommt, ausgerechnet, dass das Paket den Freitag verpasst, und der Kundin schon am Mittwoch das neue Datum gemailt. Niemand hat ihn darum gebeten.

Warum das für eCommerce gerade jetzt zählt

Die Prognosen sind groß, und es sind Prognosen. Lies sie als Richtung, nicht als Tatsache. McKinsey schätzte im Oktober 2025, dass agentic commerce bis 2030 bis zu 1 Billion US Dollar Umsatz im US Einzelhandel steuern könnte, weltweit 3 bis 5 Billionen US Dollar.¹ Eine Studie des IBM Institute for Business Value von 2026 ergab, dass 45 % der Verbraucherinnen und Verbraucher KI schon für einen Teil ihres Einkaufs nutzen.² Gartner sagte im August 2025 voraus, dass bis Ende 2026 bis zu 40 % der Unternehmensanwendungen aufgabenspezifische KI Agenten enthalten würden, nach weniger als 5 % im Jahr 2025.³

Für einen Shop ist die Bedeutung einfacher als die Zahlen. Die mühsame operative Arbeit (Bestände im Blick behalten, Paketdiensten hinterhertelefonieren, abgebrochene Warenkörbe anstupsen) ist genau die Arbeit, die Agenten gut können. Wer sie abgibt, kann seine Leute für die Entscheidungen einsetzen, die Urteilsvermögen brauchen.

Ich gehe jetzt die Bereiche durch, in denen Agenten heute schon nützliche Arbeit leisten, einen nach dem anderen, jeweils mit dem Code für Rails und Solidus.

Agentic Lagerverwaltung

Klassische Lagerverwaltung reagiert. Du merkst, dass etwas knapp wird, und bestellst nach. Ein besser organisierter Shop hat Meldebestände, also eine Regel wie "fällt der Bestand unter X, bestelle Y". Nur sind diese Regeln starr. Sie wissen nichts von saisonalen Spitzen, von einer Kampagne, die gleich startet, oder von einem Lieferanten, dessen Lieferzeit sich langsam verlängert hat.

Ein agentisches Lagersystem beobachtet den Bestand in Echtzeit, misst, wie schnell sich jedes Produkt verkauft, rechnet kommende Aktionen und Lieferzeiten ein und entscheidet, wann nachbestellt wird. In einer Anwendung mit Rails und Solidus kann das so aussehen. Spree::StockItem und Spree::Promotion sind Modelle von Solidus, die Scopes (low_stock, upcoming), das Modell Supplier und die Services sind eigener Code des Shops.

class InventoryAgent
  SAFETY_FACTOR = 1.3

  def perceive
    {
      stock_items: Spree::StockItem.includes(:variant).low_stock,      # eigener Scope
      velocity: SalesVelocityService.calculate(period: 7.days),         # Stück pro Tag je Varianten ID
      promotions: Spree::Promotion.upcoming,                            # eigener Scope
      lead_times: Supplier.active.pluck(:id, :avg_lead_days).to_h       # eigenes Modell
    }
  end

  def reason(obs)
    obs[:stock_items].filter_map do |item|
      variant = item.variant
      velocity = obs[:velocity].fetch(variant.id, 0)
      next if velocity.zero?

      lead_time = obs[:lead_times].fetch(variant.supplier_id, 7)
      boost = promotion_multiplier(variant, obs[:promotions])
      days_of_stock = item.count_on_hand / velocity.to_f
      next unless days_of_stock < lead_time * 1.5

      quantity = (velocity * lead_time * SAFETY_FACTOR * boost).ceil
      urgency = days_of_stock < lead_time ? :critical : :standard
      { variant:, quantity:, urgency: }
    end
  end

  def act(decisions)
    decisions.each do |d|
      if d[:urgency] == :critical
        PurchaseOrderService.create_and_send!(d[:variant], d[:quantity])
        OperationsMailer.reorder_sent(d).deliver_later
      else
        PurchaseOrderService.create_draft(d[:variant], d[:quantity])
      end
    end
  end
end

Achte auf die abgestufte Autonomie. Wenn dem Shop gleich die Ware ausgeht, schickt der Agent die Bestellung selbst ab und sagt dem Team Bescheid. Sonst legt er einen Entwurf an, den ein Mensch freigibt. Der Agent hat Handlungsfreiheit, aber innerhalb von Grenzen.

Rechenbeispiel: eine Teesorte bei Fleetblick Tee

Die Annahmen des Beispiels: Die Ostfriesische Mischung von Fleetblick verkauft sich 12 Dosen am Tag, 100 Dosen sind auf Lager, der Lieferant braucht 10 Tage, und eine Aktion nächste Woche soll den Absatz um die Hälfte steigern (ein Faktor von 1,5).

Reichweite des Bestands: $100 \div 12 = 8{,}3$ Tage.

Die Schwelle liegt beim Anderthalbfachen der Lieferzeit, $1{,}5 \times 10 = 15$ Tage. Weil 8,3 unter 15 liegt, bestellt der Agent nach.

Menge: $12 \times 10 \times 1{,}3 \times 1{,}5 = 234$ Dosen.

Dringlichkeit: 8,3 Tage Bestand sind weniger als 10 Tage Lieferzeit. Der Shop ist also leer, bevor neue Ware ankommen kann. Das ist kritisch, und der Agent schickt die Bestellung sofort ab und mailt dem Team. Wären es 150 Dosen gewesen (12,5 Tage), wäre die Bestellung als Entwurf bei einem Menschen gelandet.

Agentic Kundenservice

Das meiste, was im eCommerce heute "KI im Kundenservice" heißt, ist ein besserer Chatbot. Er versteht Sprache besser als die alten Stichwortbots, wartet aber immer noch darauf, dass die Kundschaft fragt.

Ein agentischer Kundenservice beobachtet die Reise der Kundin und meldet sich zuerst. Angenommen, eine Bestellung geht ein, und der Agent sieht, dass das Lager im Rückstand ist und die Lieferung zwei Tage später kommt. Bevor die Kundin es merkt, schreibt er: "Deine Bestellung wird gerade gepackt, kommt aber erst am Donnerstag statt am Dienstag. Als kleine Entschuldigung bekommst du 10 % auf deine nächste Bestellung." Die Kundin hat sich nicht beschwert. Der Agent hat wahrgenommen, abgewogen und gehandelt.

In Rails hat das dieselbe Form, dieselbe Schleife. Solidus hat weder eine Spalte expected_delivery_at noch ein Modell für die Stimmung, beides ergänzt der Shop selbst.

class CustomerExperienceAgent
  def perceive
    {
      delayed_shipments: Spree::Shipment.ready.where("expected_delivery_at > promised_delivery_at"),
      negative_sentiment: CustomerSentiment.where(score: ...(-0.5)),
      abandoned_carts: AbandonedCart.recent.high_value
    }
  end

  def reason(obs)
    delays = obs[:delayed_shipments].map do |shipment|
      { type: :delay_notice, order: shipment.order, compensation: compensation_for(shipment.order) }
    end
    unhappy = obs[:negative_sentiment].pluck(:user_id)
    carts = obs[:abandoned_carts].reject { |cart| unhappy.include?(cart.user_id) }.map do |cart|
      { type: :cart_recovery, cart:, incentive: incentive_for(cart) }
    end
    delays + carts
  end

  def act(decisions)
    decisions.each do |d|
      case d[:type]
      when :delay_notice
        CustomerMailer.delay_notice(d[:order], d[:compensation]).deliver_later
        apply_compensation(d[:order], d[:compensation])
      when :cart_recovery
        CartRecoveryMailer.personalised(d[:cart], d[:incentive]).deliver_later
      end
      AgentAuditLog.create!(agent_name: self.class.name, action_type: d[:type], decision_payload: d)
    end
  end
end

Ein Detail lohnt sich zum Abschreiben: Wer kürzlich einen negativen Stimmungswert hatte, fliegt aus der Liste für die Warenkorbmails. Niemand, der sich gerade beschwert hat, will eine fröhliche Mail mit "Du hast da was vergessen".

Rechenbeispiel: was ein Hinweis auf Verspätung kostet und was er rettet

Die Annahmen des Beispiels: Fleetblick verschickt 1.200 Bestellungen im Monat, rund 3 % davon verspäten sich (36 Bestellungen), die durchschnittliche Bestellung liegt bei 32 €, und der Agent gibt 10 % auf die nächste Bestellung.

Wenn jede betroffene Kundin den Rabatt für eine ähnliche Bestellung einlöst, kostet das $36 \times 32 \times 0{,}10 = 115{,}20$ € im Monat. Schätzt der Shop, dass eine stille Verspätung jede sechste Kundin vergrault, und ist eine Kundin über ihre gesamte Zeit 90 € Marge wert, kostet das Schweigen $36 \div 6 \times 90 = 540$ €. Der Agent rechnet sich, wenn der Hinweis auch nur ein Viertel dieser Kundinnen hält. Die jede sechste und die 90 € sind Annahmen dieses Beispiels, und das Erste, was du mit einem echten Agenten tust, ist, sie zu messen.

Agentic Auftragssteuerung

Wenn du aus mehreren Lagern verkaufst oder mit Dropshipping Lieferanten arbeitest, ist die Auftragssteuerung einer der nützlichsten Orte für einen Agenten.

Feste Regeln sagen: Bestellungen aus dem Norden gehen ins Lager in Hamburg, Bestellungen aus dem Süden und Osten nach Leipzig. Und wenn Hamburg überlastet ist, den Artikel nicht hat, oder ein Lieferant schneller und zu niedrigeren Kosten liefern könnte? Ein agentischer Router bewertet jede Quelle nach dem aktuellen Zustand des Netzes: Bestand, Länge der Warteschlange, Versandkosten, Lieferzeit und Zuverlässigkeit.

Solidus bietet dafür echte Ansatzpunkte. Seine Lagerkonfiguration stellt einen Filter für Lagerorte bereit, der die Bestellung bekommt, einen Sortierer für Lagerorte, der festlegt, in welcher Reihenfolge Lagerorte genutzt werden, und einen Allocator, der entscheidet, wie vorrätige und nachbestellte Ware aufgeteilt wird.⁴ Ein Sortierer muss nur sort über die Lagerorte implementieren, die er bekommt.⁵ Ein Router mit Punktwertung kann also ein eigener Sortierer sein:

module Fleetblick
  class ScoredLocationSorter < Spree::Stock::LocationSorter::Base
    WEIGHTS = { speed: 0.3, cost: 0.3, reliability: 0.2, capacity: 0.2 }.freeze

    def sort
      stock_locations.sort_by { |location| -score(location) }
    end

    private

    # Jede Kennzahl ist eine Zahl von 0 bis 1, aktualisiert von einem Hintergrundjob
    def score(location)
      metrics = LocationMetrics.for(location)
      WEIGHTS.sum { |factor, weight| metrics.public_send(factor) * weight }
    end
  end
end

# config/initializers/spree.rb
Spree.config do |config|
  config.stock.location_sorter_class = "Fleetblick::ScoredLocationSorter"
end

Der eigentliche "Agent" sitzt drumherum. Ein Hintergrundjob hält LocationMetrics aus dem aktuell, was tatsächlich passiert (wie lange jedes Lager gebraucht hat, wie viele Pakete zu spät ankamen), und ein Subscriber prüft jede abgeschlossene Bestellung und gibt alles Ungewöhnliche, etwa Versandkosten weit über dem Normalen, an einen Menschen weiter.

Der Punktwert ist eine gewichtete Summe, ein naher Verwandter des gewichteten Mittelwerts:

$$S = \sum_{i=1}^{k} w_i \, m_i$$

Dabei ist $S$ der Punktwert des Lagerorts, $k$ die Zahl der Faktoren (hier vier), $w_i$ das Gewicht des Faktors $i$ (die Gewichte ergeben zusammen 1) und $m_i$ der Messwert des Lagerorts für diesen Faktor, skaliert von 0 bis 1. Grundlagen: der Mittelwert

Rechenbeispiel: Hamburg oder Leipzig für ein Paket nach München

Die Zahlen des Beispiels, jeweils von 0 bis 1 skaliert: Hamburg erreicht 0,5 bei der Geschwindigkeit, 0,6 bei den Kosten, 0,9 bei der Zuverlässigkeit und 0,3 bei der Kapazität (dort ist heute viel los). Leipzig erreicht 0,8, 0,7, 0,8 und 0,9.

$$S_{\text{Hamburg}} = 0{,}3 \times 0{,}5 + 0{,}3 \times 0{,}6 + 0{,}2 \times 0{,}9 + 0{,}2 \times 0{,}3 = 0{,}57$$

Das ist Hamburg: $S_{\text{Hamburg}}$ ist sein Punktwert, jedes Gewicht $w_i$ mal seinem Messwert $m_i$.

$$S_{\text{Leipzig}} = 0{,}3 \times 0{,}8 + 0{,}3 \times 0{,}7 + 0{,}2 \times 0{,}8 + 0{,}2 \times 0{,}9 = 0{,}79$$

Und das ist Leipzig, mit $S_{\text{Leipzig}}$ als Punktwert aus denselben Gewichten. Leipzig gewinnt, 0,79 zu 0,57, also wird zuerst dessen Bestand genutzt. Morgen, wenn Hamburg seine Warteschlange abgearbeitet hat und die Kapazität wieder bei 0,9 liegt, kommt Hamburg auf 0,69, und der Abstand schrumpft. Die Regel hat sich nicht geändert. Die Welt schon.

Agentic dynamische Preise

Bei dynamischen Preisen werden Agenten mächtig, und ohne Leitplanken gefährlich.

Ein Preisagent beobachtet Preise der Konkurrenz, Nachfrage, Bestand, Margenziele und Saison und passt Preise auf ein Ziel hin an: Umsatz, Marge oder Marktanteil. Ohne Grenzen können sich zwei Preisagenten gegenseitig nach unten jagen und beide Margen vernichten, oder einer treibt die Preise bei einem Nachfrageschub hoch und beschädigt Vertrauen. Genau diese Art von Konflikt zwischen mehreren Agenten bearbeite ich mit GrowCentric.ai, und ich habe darüber in wenn deine KI gegen sich selbst kämpft geschrieben.

Die Antwort sind klare Grenzen, in der richtigen Reihenfolge geprüft:

class PricingAgent
  GUARDRAILS = {
    min_margin: 0.15,          # nie unter 15 % Marge
    max_daily_change: 0.10,    # höchstens 10 % am Tag
    approval_above: 0.20       # ein Vorschlag über 20 % geht an einen Menschen
  }.freeze

  def propose_price(variant)
    current = variant.price
    optimal = calculate_optimal_price(variant)
    proposed_change = ((optimal - current) / current).abs

    if proposed_change > GUARDRAILS[:approval_above]
      PricingApprovalQueue.enqueue(variant:, current:, proposed: optimal, reasoning: @reasoning)
    else
      update_price(variant, constrain(variant, current, optimal))
    end
  end

  private

  def constrain(variant, current, optimal)
    step = current * GUARDRAILS[:max_daily_change]
    price = optimal.clamp(current - step, current + step)
    floor = variant.cost_price / (1 - GUARDRAILS[:min_margin])
    [price, floor].max
  end
end

Die Reihenfolge entscheidet. Die frühere Fassung dieses Codes hat den Preis zuerst auf die Tagesgrenze von 10 % gekappt und erst danach gefragt, ob die Änderung über 20 % liegt. Nach dem Kappen ist sie das nie, also konnte die Freigabeschleife nie greifen. Die Prüfung auf Freigabe muss auf das schauen, was der Agent wollte, nicht auf das, was die Leitplanke erlaubt hat.

Rechenbeispiel: eine Preiserhöhung bei Geschenksets

Die Zahlen des Beispiels: Ein Geschenkset von Fleetblick kostet im Einkauf 12 € und wird für 20 € verkauft.

Der Agent schlägt 23 € vor. Die Änderung beträgt $(23 - 20) \div 20 = 15\,\%$, liegt also unter der Freigabegrenze von 20 %, und der Agent darf allein handeln. Die Tagesgrenze ist $20 \times 0{,}10 = 2$ €, also geht der Preis auf 22 €, nicht auf 23 €. Die Untergrenze für die Marge liegt bei $12 \div (1 - 0{,}15) = 14{,}12$ €, weit unter 22 €, sie greift also nicht. Morgen darf der Agent den nächsten Schritt gehen, wenn die Daten es weiter hergeben.

Hätte er 26 € vorgeschlagen (eine Änderung um 30 %), wäre der Vorschlag mit der Begründung des Agenten an einen Menschen gegangen, und der Preis hätte sich nicht bewegt, bis jemand zustimmt.

Wie das auf Rails und Solidus passt

Wenn du schon mit Ruby on Rails und Solidus baust, hast du für agentische Muster eine gute Ausgangslage, aus vier Gründen.

Events sind die Wahrnehmung. Solidus veröffentlicht Events auf einem eigenen Bus, Spree::Bus, gebaut auf der Bibliothek Omnes, die seit Solidus 3.2 der Standard ist. Ältere Versionen nutzten ein System auf Basis von ActiveSupport::Notifications.⁶ Zu den Kernevents gehören order_finalized, carton_shipped und order_canceled, und ein Agent abonniert sie so:

# app/subscribers/fleetblick/agent_subscriber.rb
module Fleetblick
  class AgentSubscriber
    include Omnes::Subscriber

    handle :order_finalized, with: :route_order
    handle :carton_shipped, with: :track_delivery

    def route_order(event)
      OrderReviewJob.perform_later(event.payload[:order].id)
    end

    def track_delivery(event)
      DeliveryWatchJob.perform_later(event.payload[:carton].id)
    end
  end
end

# config/initializers/omnes.rb
Rails.application.config.to_prepare do
  Fleetblick::AgentSubscriber.new.subscribe_to(Spree::Bus)
end

Die Subscriber stellen nur Jobs in die Warteschlange. Der Checkout darf nie darauf warten, dass ein Agent nachdenkt.

Hintergrundjobs sind die Schleife. Agenten laufen nach Zeitplan, ohne den Shop zu blockieren. Seit Rails 8 ist Solid Queue das Standardbackend für Active Job, und es liest wiederkehrende Aufgaben aus config/recurring.yml.⁷ Sidekiq und GoodJob erledigen dieselbe Aufgabe. Eine wiederkehrende Aufgabe ist sicherer als ein Job, der sich am Ende selbst neu einplant, weil ein fehlgeschlagener Lauf keine zweite Kette neben der ersten starten kann.

# config/recurring.yml
production:
  inventory_agent:
    class: InventoryAgentJob
    schedule: every 15 minutes

class InventoryAgentJob < ApplicationJob
  queue_as :agents

  def perform
    agent = InventoryAgent.new
    agent.act(agent.reason(agent.perceive))
  end
end

Der Code gehört dir. Solidus ist Open Source unter einer BSD Lizenz,⁸ du kannst also jedes Modell und jeden Service lesen und ersetzen: den Sortierer für Lagerorte von oben, die Zustandsmaschine der Bestellung, die Regeln für Aktionen, den Checkout. Auf einer gehosteten Plattform arbeitest du mit den Erweiterungspunkten, die der Anbieter bereitstellt. Für viele Shops ist das ein fairer Tausch, für einen Agenten, der tief in die Maschine greifen muss, eine Einschränkung.

Die API ist da. Solidus bringt eine REST API mit, dokumentiert in OpenAPI.⁹ Eine GraphQL API gibt es als eigene Erweiterung, solidus_graphql_api, deren letzte Version 0.3.1 im August 2023 erschien.¹⁰ Für neue Arbeit ist sie damit eine dünnere Basis als die REST API im Kern, die für Agenten als eigene Services völlig ausreicht.

Agentische Systeme in einem SaaS bauen: GrowCentric.ai

Meine Arbeit an GrowCentric.ai ist von diesen Mustern geprägt. GrowCentric ist eine SaaS Plattform, die mit maschinellem Lernen Marketingkampagnen im eCommerce optimiert, und im Kern ist sie ein System aus mehreren Agenten.

Der Analyseagent beobachtet die Leistung der Kampagnen, erkennt Ausreißer und Trends und meldet sie, wenn sie passieren, statt in einem Wochenbericht.

Der Agent für die Budgetverteilung verschiebt Budget von schwächeren zu stärkeren Kampagnen, hält Tages und Monatsgrenzen ein und rechnet mit abnehmendem Ertrag bei wachsender Größe.

Der Zielgruppenagent analysiert das Verhalten der Kundschaft, findet wertvolle Gruppen und ähnliche Muster und empfiehlt neue Ausrichtungen.

Der Agent für Konfliktlösung kümmert sich um das Problem, dass konkurrierende Shops dieselben Optimierungsalgorithmen nutzen und gegeneinander bieten. Er erkennt, wenn Kunden um dieselben Zielgruppen konkurrieren, segmentiert, um die Überschneidung zu verringern, und sucht mit Spieltheorie nach Lösungen, die für alle funktionieren.

Alle sind auf Rails gebaut, mit den Mustern aus Events, Hintergrundjobs und API, die ich oben beschrieben habe. Die wichtigste Entscheidung war, jeden Agenten als eigenständigen Service mit klaren Eingaben, Ausgaben und Grenzen zu entwerfen. Sie stimmen sich über einen gemeinsamen Eventbus ab (ActiveSupport::Notifications innerhalb des Monolithen, Message Queues für die verteilten Teile), und jede Entscheidung wird protokolliert.

Die ehrlichen Grenzen, und warum Leitplanken zählen

Ich würde dir einen schlechten Dienst erweisen, wenn ich weglasse, was schiefgeht. Die Fehlerbilder sind real.

Fehler, die sich fortpflanzen. Eine schlechte Entscheidung breitet sich schnell aus. Ein Lageragent, der die Nachfrage falsch liest, bestellt zu viel. Ein Preisagent, der einen Wettbewerber falsch liest, ruiniert die Marge. Der Fehler eines Menschen fällt meist in einer Prüfung auf. Ein Agent kann Hunderte machen, bevor jemand hinschaut.

Die Antwort ist abgestufte Autonomie:

Lies es von oben: Eine Entscheidung, die wenig kostet und sich rückgängig machen lässt, läuft allein, eine innerhalb der Grenzen läuft mit Meldung, alles andere wartet auf einen Menschen. Welcher Weg es auch ist, er endet im Protokoll.

Kein gesunder Menschenverstand. Ein Agent optimiert innerhalb seiner Parameter, ohne den Zusammenhang, den ein Mensch hat. Er bewirbt vielleicht ein zurückgerufenes Produkt, schickt Pakete in eine Region, die gerade unter Hochwasser steht, oder schickt ein Upsell an jemanden, der sich vor einer Stunde beschwert hat. Die Antwort ist mehr Kontext und ausdrückliche Sperrlisten: Gib den Agenten den größeren Zustand des Geschäfts, und benenne die Situationen, in denen automatisches Handeln aus ist.

Zu viel Vertrauen und verlorene Fähigkeiten. Wenn Agenten alles machen, vergisst das Team, wie man den Shop ohne sie führt. Und ausfallen werden sie manchmal, durch einen Ausfall einer API, ein schlechteres Modell oder einen Sonderfall. Die Antwort ist ein geordneter Rückzug auf einfachere Regeln. Fällt der Lageragent aus, übernehmen feste Meldebestände. Fällt der Preisagent aus, frieren die Preise ein. Fällt der Router aus, gehen Bestellungen ins Standardlager.

Regulierung. Wie ich in meinen Beiträgen zum Cyber Resilience Act und zur NIS2 Richtlinie beschrieben habe, haben Unternehmen, die in Europa verkaufen, wachsende Pflichten rund um Sicherheit und Daten, und die EU KI Verordnung bringt eigene dazu. Ein Agent, der Preise festlegt, Kunden schreibt oder personenbezogene Daten verarbeitet, muss prüfbar und erklärbar sein. Das heißt: jede Eingabe, jede Entscheidung und jede Ausgabe protokollieren, eine Möglichkeit für Menschen, einzugreifen, und eine klare Dokumentation, wie jeder Agent entscheidet.

Der Einstieg: ein praktischer Fahrplan

Wenn du einen Shop auf Rails und Solidus betreibst und anfangen willst, ist das der Weg, den ich empfehlen würde.

Fang mit Beobachten an, nicht mit Handeln. Bau einen Agenten, der beobachtet und meldet, und sonst nichts. Lass ihn Bestand, Versandzeiten und die Stimmung der Kundschaft beobachten. Vertrau seiner Wahrnehmung, bevor du ihn handeln lässt.

Wähl einen Bereich mit geringem Risiko und hohem Nutzen. Die Rückgewinnung abgebrochener Warenkörbe ist ein guter erster Agent. Eine schwache Mail kostet wenig. Eine gute zahlt sich aus.

Bau die Leitplanken am ersten Tag. Bau keinen völlig autonomen Agenten, um ihm später Grenzen anzuschrauben. Leg fest, was er allein darf, was er mit Meldung tut und was eine Freigabe braucht, und mach diese Grenzen zu Konfiguration statt zu Code.

Protokollier alles. Jede Wahrnehmung, jede Entscheidung und jedes Ergebnis. Du brauchst das für die Fehlersuche, für die Compliance und um den Agenten besser zu machen.

class AgentAuditLog < ApplicationRecord
  belongs_to :agentable, polymorphic: true, optional: true

  validates :agent_name, :action_type, :decision_payload, presence: true

  scope :recent, -> { where(created_at: 24.hours.ago..) }
  scope :by_agent, ->(name) { where(agent_name: name) }
  scope :escalated, -> { where(escalated: true) }
end

Miss die Wirkung ohne Gnade. Bevor ein Agent live geht, leg fest, woran du ihn misst: Umsatz, eingesparte Kosten, Zufriedenheit der Kundschaft. Wenn er in angemessener Zeit keinen Wert zeigt, schalte ihn ab.

Rechenbeispiel: lohnt sich ein Agent für abgebrochene Warenkörbe?

Die Annahmen des Beispiels: Fleetblick sieht 400 abgebrochene Warenkörbe im Monat mit einem Durchschnittswert von 45 €, der Agent holt 5 % davon zurück, und die Bruttomarge auf Tee liegt bei 40 %.

Zurückgeholte Warenkörbe: $400 \times 0{,}05 = 20$ Bestellungen im Monat.

Zurückgeholter Umsatz: $20 \times 45 = 900$ € im Monat.

Marge: $900 \times 0{,}40 = 360$ € im Monat, also 4.320 € im Jahr.

Kosten Bau und Betrieb des Agenten im ersten Jahr weniger als das, hat er seinen Platz verdient. Liegt die echte Quote am Ende bei 2 %, ist die Marge $400 \times 0{,}02 \times 45 \times 0{,}40 = 144$ € im Monat, und die Entscheidung kann anders ausfallen. Deshalb misst du, bevor du skalierst. Dieselbe Logik, mit Wahrscheinlichkeiten für jedes Ergebnis, ist der Erwartungswert.

Der Wechsel vom klassischen zum agentischen Handel passiert nicht über Nacht, aber er passiert. Ein Shop, der jetzt anfängt, auch mit einem einzigen kleinen, gut abgesicherten Agenten, ist vorn, wenn es zur normalen Art wird, einen Shop zu führen.

Footnotes

1. Mark Brohan, McKinsey forecasts up to $5 trillion in agentic commerce sales by 2030, Digital Commerce 360, 20. Oktober 2025, über McKinsey and Company, The agentic commerce opportunity, Oktober 2025, https://www.digitalcommerce360.com/2025/10/20/mckinsey-forecast-5-trillion-agentic-commerce-sales-2030/

2. Amanda McGrath und Amanda Downie, What is agentic commerce?, IBM Think, 23. Januar 2026, mit Verweis auf eine Studie des IBM Institute for Business Value von 2026, https://www.ibm.com/think/topics/agentic-commerce

3. Melvin Hipolito, AI agents to power 40% of enterprise apps by 2026, says Gartner, IT Brief Australia, 27. August 2025, über die Pressemitteilung von Gartner vom 26. August 2025, https://itbrief.com.au/story/ai-agents-to-power-40-of-enterprise-apps-by-2026-says-gartner

4. Solidus, core/lib/spree/core/stock_configuration.rb, GitHub, abgerufen im November 2026, https://github.com/solidusio/solidus/blob/main/core/lib/spree/core/stock_configuration.rb

5. Solidus, Spree::Stock::LocationSorter::Base, GitHub, abgerufen im November 2026, https://github.com/solidusio/solidus/blob/main/core/app/models/spree/stock/location_sorter/base.rb

6. Solidus Guides, Subscribing to events, abgerufen im November 2026, https://guides.solidus.io/customization/subscribing-to-events

7. Ruby on Rails Guides, Active Job basics, abgerufen im November 2026, https://guides.rubyonrails.org/active_job_basics.html

8. Solidus, LICENSE, GitHub, abgerufen im November 2026, https://github.com/solidusio/solidus/blob/main/LICENSE

9. Solidus, solidus_api README, GitHub, abgerufen im November 2026, https://github.com/solidusio/solidus/blob/main/api/README.md

10. Solidus, solidus_graphql_api repository and releases, GitHub, letzte Version v0.3.1, 25. August 2023, https://github.com/solidusio/solidus_graphql_api