Das eigentliche Problem in der Handelsplanung liegt längst nicht mehr darin, das Modell zu lösen, sondern darin, zu sagen, was man will – und ein am 3. September auf arXiv veröffentlichtes Paper beziffert diesen Unterschied. Die Autoren legten bei einem großen Handelspartner eine Klartext-Ebene über eine Lagerhaus-Pipeline und bewerteten dann jede Anweisung zweifach: einmal danach, ob die resultierende Änderung zulässig, ausführbar und auf das vorgesehene Modul angewendet war, und ein zweites Mal danach, ob sie die Kennzahl verbesserte, die die Anforderung eigentlich bewegen sollte. Die Korrektheitsraten fielen über die drei getesteten Basismodelle hinweg mit 89–96 % hoch aus. Diese Zahl fragt nur, ob eine Änderung gültig war, nicht, ob sie funktioniert hat. Der End-to-End-Erfolg – ob die Änderung die angepeilte Kennzahl tatsächlich bewegte – stieg unter dem Framework von einer Baseline von 72–76 % auf 79–83 %, und die Lücke zwischen diesen beiden Fragen ist die Spezifikation: der Teil der Anfrage, den niemand zu Ende geschrieben hat und für den in dieser Architektur niemand die Verantwortung trägt.

Das Design gesteht ein, was ein reines Texteingabefeld allein nicht leisten kann. Frühere Arbeiten richteten Sprachmodelle auf ein einzelnes Optimierungsmodell aus; dieses Lagerhaus betreibt drei gekoppelte Modelle für Preprocessing, Packing und Dispatching, bei denen eine vorgelagerte Änderung die Eingaben und die nachgelagert verfügbaren Entscheidungsmöglichkeiten verändert. Jedes Modul veröffentlicht deshalb, was die Autoren admissible reformulation interfaces nennen – ein festes Menü an Änderungen, die es akzeptiert –, und ein zentraler Prozessor durchsucht begrenzte Pfade durch diesen Graphen, statt das Modell schreiben zu lassen, was es will. Überlebende Kandidaten werden ausgeführt und anhand nachgelagerter KPIs verglichen. Die Sprachebene nimmt die Anfrage entgegen; der Graph entscheidet, welches Modul sie beantworten darf.

Eine Anforderung aus der Studie zeigt, warum Routing kein bloßer Verwaltungsschritt ist. Sie lautet: “Complete the packing and dispatching process of the third store before 10:30, where the warehouse starts processing at 8:00 a.m.” Der Satz benennt ein Ergebnis, aber keinen Mechanismus. Drei Module könnten es jeweils liefern: die Dispatch-Reihenfolge neu ordnen, die Load Units so umbauen, dass die Cages des dritten Stores früher fertig werden, oder verändern, was das Preprocessing weiter unten in der Kette übergibt. Die Formulierung der Autoren selbst ist die treffendste Zusammenfassung: “several locally valid reformulations may satisfy the requirement but lead to different system-level outcomes after downstream re-execution.”

Eine Anforderung mit drei rechtmäßigen Antworten ist keine Anfrage, sondern eine unfertige Entscheidung, die an das Modul weitergegeben wird, das der Router zuerst erreicht.

Die Schwierigkeitsaufteilung der Studie zeigt, wo sich Orchestrierung wirklich lohnt – und das ist nicht dort, wo die Demos inszeniert werden. Bei Anforderungen mit einer einzigen offensichtlichen Maßnahme schnitt das Routing durch den Graphen geringfügig schlechter ab als die direkte Anfrage an das Modell, was in der Regel passiert, wenn Maschinerie zu einem Problem hinzugefügt wird, das sie gar nicht braucht. Wo mehrere plausible Änderungen konkurrierten, stieg der End-to-End-Erfolg mit DeepSeek als Basismodell von 54 % auf 72 %. Der Apparat existiert, um Unterspezifikation abzufangen, und er lohnt sich nur dann, wenn die Anfrage von vornherein unterspezifiziert war.

Die Leitplanke, die die Autoren eingebaut haben, ist der Punkt, an dem Verantwortlichkeit ganz konkret wird. Ihre Toleranzregel besagt, dass “no monitored system-level KPI may degrade by more than 10%”, und wenn kein Kandidat die Validierung besteht, “leaves the configuration unchanged and reports the collected diagnostics”. Das ist sorgfältiges Engineering, und es zieht zugleich die Grenze der Systemverantwortung genau um jene Kennzahlen, die jemand bereits für instrumentierungswürdig befunden hat. Eine schlecht spezifizierte Anforderung zahlt sich deshalb jenseits dieser Grenze aus: in der Kennzahl, die niemand beobachtet hat, bei einer Überprüfung, die niemand eingeplant hat.

Das Geld fließt schneller, als die Frage nach der Verantwortung gestellt wird. Gartner prognostiziert, dass die Ausgaben für Supply-Chain-Management-Software mit agentic AI von unter 2 Milliarden Dollar im Jahr 2025 auf 53 Milliarden Dollar bis 2030 steigen werden, erneut veröffentlicht von IT Supply Chain, und der Rat an Käufer in derselben Prognose lautet, “appropriate levels of human-in-the-loop for supply chain management decisions” aufrechtzuerhalten – Aufsicht, nicht Autorschaft. Die separaten 2026 supply chain technology trends von Gartner, aufgeführt von Inside Logistics, nennen Decision Governance als einen eigenständigen Trend, eingeordnet unter “trust and governance” statt unter das Thema “autonomy and agency”, in dem agentic AI und kollaborative Multiagentensysteme verortet sind. Einen Trend zu benennen ist nicht dasselbe wie die Zuständigkeit zuzuweisen.

Der stärkste Einwand lautet, dass dies ein Benchmark ist, kein laufender Betrieb. Hundert Anforderungen, gesammelt bei einem einzigen, nicht namentlich genannten Partner und bewertet vom eigenen KPI-Prüfstand der Autoren, sind ein Laborergebnis; wenn eindeutige Anforderungen die realen Planungswarteschlangen dominieren, ist eine Sprach-Frontend-Ebene lediglich eine Annehmlichkeit, mehrdeutiges Routing ein Grenzfall, und die Spezifikation wird nie tragend. Das ist die Bedingung, von der das Argument abhängt, und Apparel ist die Kategorie, die diese Bedingung am wenigsten wahrscheinlich erfüllt. Eine Chase Order gegen sechs Wochen laufenden Sell-through, eine Umverteilung von Store-Clustern, ein vorgezogener Markdown: Jede dieser Anforderungen kommt als Ziel mit mehreren rechtmäßigen Wegen durch Packing, Allocation und Dispatch an, und keine sagt dem System, welchen Weg es nehmen soll. Die schwierigere Gruppe in der Studie existiert, weil Praktiker genau solche Anforderungen produzierten, als man sie fragte, was sie tatsächlich verschicken.

Ein im April veröffentlichtes Konkurrenz-Framework beantwortet die Frage nach der Verantwortung, indem es eine Person benennt – was zeigt, wie wenig damit tatsächlich geklärt ist. Flowr, entwickelt zusammen mit einer großen Supermarktkette, bindet Supply-Chain-Manager in eine Orchestrierungsschleife ein, in der sie “supervise and intervene across workflow stages”, und behauptet, dies bewahre “accountability and organizational control”. Aufsicht ist ein Veto über Schritte, die bereits vorgeschlagen wurden. Das in der Lagerhaus-Studie gemessene Versagen tritt früher ein, in dem Moment, in dem ein Satz mit drei rechtmäßigen Lesarten in ein System eintritt, das darauf ausgelegt ist, eine davon auszuwählen und weiterzumachen.

Händler, die eine Sprachebene für die Planung kaufen, kaufen einen Übersetzungsdienst, und Übersetzungsdienste brauchen einen Lektor. Das Paper untersucht Lagerhaus-Packing und -Dispatching statt Apparel-Allocation, und der Partner bleibt ungenannt, aber die Struktur trägt überall dort, wo gekoppelte Module mit einem Chatfenster neu verkleidet werden: Das System tut, was der Satz gesagt hat, und der Satz wird jetzt von demjenigen geschrieben, der an der Tastatur sitzt. Solange Anforderungsänderungen selten und eindeutig bleiben, kann die Spezifikation weiterhin die Aufgabe von allen und von niemandem sein. Sollten sie so häufig eintreffen wie Apparel seine Meinung ändert, ist die Rolle, die sich zu finanzieren lohnt, nicht ein besserer Forecaster, sondern ein benannter Owner für die Anforderung – und der günstigste Moment, diese Rolle in den Prozess einzuschreiben, ist, bevor sich die erste nicht instrumentierte Kennzahl bewegt.