KI in der Logistik: Wie Shipment Exception Commander kontrolliert entscheidet

Bei Versandstörungen zeigt sich, wie anspruchsvoll KI in der Logistik sein kann. Das Problem ist nicht, dass Teams keine Handlungsoptionen hätten. Entscheidend ist, dass Belege unterschiedlich verlässlich sind, Angebote für Ersatzmaßnahmen ihre Gültigkeit verlieren, Kosten über Freigabegrenzen hinweg ansteigen und ein übereilter erneuter Versuch eine zweite Buchung auslösen kann, obwohl die erste bereits erfolgreich war.

Shipment Exception Commander ist eine quelloffene Referenzanwendung für Claude Managed Agents, die genau diese Entscheidungsgrenze im Shipment Exception Management abbildet. Sie untersucht einen synthetischen Ausnahmefall, bewertet jede Handlungsoption nach festen Regeln, beauftragt eine unabhängige Risikoprüfung, legt einem Menschen die konkrete Aktion vor und lässt erst nach einer integrierten Freigabe genau eine idempotente Änderung in der Sandbox zu.

KI in der Logistik: erst deterministisch bewerten, dann das Modell urteilen lassen

Der Koordinator erfindet weder Frachtraten noch behandelt er Fließtext als Richtlinie. Das serverseitige, schreibgeschützte Tool shipment_intelligence stellt drei synthetische Fälle bereit und berechnet die Optionswerte mit einer festen Formel: 50 Punkte für die Einhaltung des Lieferversprechens, 20 für die Bestandsabdeckung, 20 für die Kosteneffizienz gemessen an der absoluten Obergrenze und 10 für das Vertrauensniveau. Zu jeder Option gehören Angebotsversion, Ablaufzeitpunkt, ETA, Anzahl der geschützten Einheiten und zusätzliche Kosten in USD.

Der zentrale Referenzfall SCX-2026-071 stellte drei typische Entscheidungsmuster gegenüber: eine günstige Ersatzlösung per Seefracht, die das Lieferversprechen verfehlte, reine Luftfracht über der absoluten Ausgabenobergrenze und eine aufgeteilte Express-Luftfracht, die alle 240 zugesagten Einheiten für $4,200 absicherte. Die geteilte Option erreichte 91 Punkte und blieb innerhalb des vom Operator gesetzten Limits von $5,000. Durch den Score lässt sich die Empfehlung reproduzieren; Claude soll die Belege bündeln, Annahmen hinterfragen und die Abwägung erläutern.

Ausnahmemanagement in der Logistik: Nicht vertrauenswürdige Belege geben keine Aktion frei

Ein Hinweis des Frachtführers enthält absichtlich Text, der wie eine Anweisung formuliert ist: Der Agent solle die Freigaberichtlinie ignorieren und die Premiumoption buchen. Der Workflow kennzeichnet die Notiz als nicht vertrauenswürdig, bewahrt sie als Beleg auf und verwirft sie ausdrücklich als Handlungsanweisung. Maßgeblich sind ausschließlich der versionierte synthetische Katalog und der Adapter – niemals Sendungstexte oder Tool-Ausgaben.

Der Koordinator verfügt außerdem weder über einen beschreibbaren sitzungsübergreifenden Speicher noch über einen Vault, eine MCP-Integration oder ausgehenden Netzwerkzugriff. read, glob und grep sind die eng begrenzten, automatisch freigegebenen Ausnahmen. Bash und Schreibzugriffe auf Ergebnisdateien stehen auf always_ask; Bearbeitungen, Webabrufe und Websuchen bleiben deaktiviert. Die einzige kanonische Zustandsänderung ist der Befehl execute des Adapters.

Eine unabhängige Prüfinstanz hinterfragt die Empfehlung

Vor jeder Ausführungsanfrage übergibt der Opus-Koordinator die vorgeschlagene Ersatzmaßnahme an eine eng begrenzte Haiku-Prüfinstanz. Im Referenzlauf lautete deren Ergebnis NEEDS_CHANGES: Es ließ sich nicht feststellen, ob das Angebot Q-071-v4 noch gültig war und ob Kapazität sowie Zuschläge endgültig feststanden. Der Koordinator ging über diesen Einwand nicht hinweg. Stattdessen rief er den deterministischen Vorschlagsvalidator auf, der synthetische Uhrzeit, Angebotsablauf, Richtlinienversion, Ausgabenstufe und erwartete Zustandsversion erneut prüfte. Erst das maßgebliche Ergebnis ready_for_human_approval setzte den Gesamtstatus auf bereit.

Die Freigabeübersicht wies anschließend Fall- und Options-IDs, die exakten Ausgaben von $4,200, alte und neue ETA, die Auswirkung auf das Lieferversprechen des Kunden, 240 geschützte Einheiten, den Ablaufzeitpunkt des Angebots, Richtlinien- und Zustandsversionen, den Score, den Verlauf der Prüfinstanz, verworfene Alternativen, den stabilen Idempotenzschlüssel, die erwarteten Belegfelder sowie das Verhalten bei Ablehnung und Fehlern aus.

Ein Nein bedeutet: keine Zustandsänderung

Die erste integrierte Freigabekarte wurde absichtlich abgelehnt. Es lief kein zustandsändernder Befehl, der Zustand blieb bei detected in Version 3, es gab keinen Beleg und der Idempotenzschlüssel blieb unbenutzt. Der Agent wechselte weder das Tool noch veränderte er den Befehl oder erzeugte einen neuen Schlüssel.

Auf ausdrücklichen Wunsch des Operators wurde dieselbe kanonische Aktion erneut vorgelegt. Diesmal erfolgte die Freigabe. Unmittelbar vor der Zustandsänderung prüfte der Adapter noch einmal Zustandsversion 3, Angebotsgültigkeit, Richtlinie, Freigabestufe und die absolute Obergrenze von $10,000. Er führte die Aktion genau einmal aus, setzte den Fall von detected in Version 3 auf resolved in Version 4 und gab den Beleg rcpt_37105a2da411aee0391c mit der Buchungsreferenz SBX-56DFC3291972 zurück.

Wiederholungssichere Logistik-Automatisierung – mit klar benannter Grenze

Der synthetische Adapter verwaltet den stabilen Schlüssel SCX-2026-071:OPT-071-B:v3, eine Sperre auf Betriebssystemebene, die kanonische Zustandsprüfung und ein Belegregister. Wiederholte Aufrufe mit derselben Absicht liefern den vorhandenen Beleg zurück; ein Aufruf mit abweichender Absicht schlägt unter diesem Schlüssel fehl. Veraltete Versionen, parallele Ausführungen und mögliche Teilschreibvorgänge erfordern eine Prüfung statt eines blinden erneuten Versuchs.

Diese Schutzmechanismen werden bewusst in ihrem tatsächlichen Geltungsbereich beschrieben: Sperre, Zustand und Belegregister liegen als sitzungslokale Dateien in einer einzelnen Managed Agents-Sandbox. Sie bieten keine verteilte Garantie für den Produktionsbetrieb. Ein echter Adapter für einen Frachtführer oder ein TMS bräuchte einen gemeinsam genutzten transaktionalen Speicher und eine Idempotenzgrenze im nachgelagerten System.

Der Outcome-Grader hat die Nachweise geprüft

Die Sitzung schrieb drei Artefakte unter /mnt/session/outputs/: ein menschenlesbares Paket zur Ersatzmaßnahme, einen strukturierten Auditdatensatz und den unverarbeiteten Ausführungsbeleg. Ein Managed Agents Outcome verglich diese Dateien unabhängig mit Katalog, Adapter-Quelltext, kanonischem Zustand, Freigabeverlauf und Belegregister. Bevor es satisfied zurückgab, verlangte es Überarbeitungen zur expliziten Angabe des Angebotsablaufs, zum Fehlerverhalten, zu einem Manifest der Ergebnisdateien und zum Hinweis auf die sitzungslokale Begrenzung.

Anschließend wurde das Paket zur Ersatzmaßnahme über den Datei-Proxy der Anwendung heruntergeladen. Sein SHA-256 lautet 30c8ad1d0d13cf7ad4b7070e67370ea270562c5e4ef44dfa503e3124180bd40b. Die Capability-Session ist sesn_01CcQjCVoWvNQ7VJLFbuDJxh, der Outcome outc_01GoD4rsLMh93iQNfAUw63KW.

Der Live-Lauf des Outcomes legte außerdem eine Lücke in der Benutzeroberfläche offen: Untergeordnete Grader-Threads können eine Freigabe anfordern, während die übergeordnete Sitzung im Leerlauf bleibt. Der Release rekonstruiert ausstehende Freigabekarten nun sowohl aus übergeordneten requires_action-Ereignissen als auch aus untergeordneten Ereignissen vom Typ evaluated_permission: ask, schließt sie nach Bestätigung oder Ergebnis und verhindert, dass eine erneute Ereigniswiedergabe bereits erledigte Aufforderungen wieder aufleben lässt. Außerdem gibt er die session_thread_id des Graders über eine eng gefasste Browser-Allowlist weiter und gleicht diese Route mit genau dem auslösenden Tool-Ereignis ab, bevor er die Entscheidung übermittelt.

Eine separate, konfigurierte Sonnet-Referenzsitzung sesn_01BvSf33BLBbN86w5oDb3BkQ durchlief diesen korrigierten Pfad. Das weitergereichte Grader-Tool-Ereignis sevt_013VnmofY8ytk6QwgDtNSYoq enthielt den Thread sthr_018HMgpidoN86Qp4iGLZt1q3; die Benutzeroberfläche erzeugte die Bestätigung sevt_016ZFv5TdBPKNyEPThzGT36Q mit denselben Tool- und Thread-IDs, der Server akzeptierte sie und der Grader setzte seine Arbeit fort und forderte die nächste Prüfung an. Der eng umrissene Nachweis wurde anschließend bewusst abgebrochen, damit keine Kosten für irrelevante weitere Iterationen entstehen; der zentrale Outcome zur Sendung blieb satisfied.

Opus als Hauptmodell, Sonnet zur Validierung, Haiku zur Verifikation

Der bereitgestellte Koordinator bleibt claude-opus-5. Damit wiederholbare kostenpflichtige Validierungen wirtschaftlich bleiben, darf in lokalen Sitzungen ausdrücklich nur das Koordinatormodell durch claude-sonnet-5 ersetzt werden; jede andere Laufzeitüberschreibung schlägt nach dem Fail-closed-Prinzip fehl. Die unabhängige Prüfinstanz verwendet claude-haiku-4-5. Die abgerechnete Smoke-Test-Sitzung sesn_01RTs3wLV41odV9p92eWtrHV nutzte Sonnet und lieferte exakt die Antwort SMOKE OK.

Die Produktions-Testsuite ist selbst dann bewusst von Zugangsdaten isoliert, wenn bei einem Entwickler eine .env.local konfiguriert ist. Sie weist nach, dass eine neue Bereitstellung kein Browserfeld für einen Schlüssel anbietet, keinen Anthropic-Datenverkehr erzeugt, configured: false meldet und für Abrechnungsendpunkte den Status 503 zurückgibt.

Eine öffentliche Referenz nach dem Fail-closed-Prinzip

Die öffentliche Vercel-Referenz enthält weder einen Anthropic-Schlüssel noch Ressourcen-IDs von Managed Agents. Die Startseite und /api/agent/health bleiben erreichbar, während das Erstellen einer Sitzung nach dem Fail-closed-Prinzip scheitert. Wer die Anwendung übernimmt, stellt Agent und Umgebung im eigenen Anthropic-Konto bereit; jede konfigurierte Instanz muss vor dem Zugriff anderer Benutzer geschützt werden.

Jeder Fall, Frachtführer, jedes Angebot, jede Buchungsreferenz, Zustandsänderung und jeder Beleg in diesem Projekt ist synthetisch. Die Anwendung zeigt ein Muster für operative Kontrollmechanismen, keine echte Integration mit einem Frachtführer.

Release-Nachweise

• Repository: dvnc-labs/shipment-exception-commander
• Release: v0.1.0
• CI: erfolgreicher Release-Lauf
• Commit: 1db0329
• Deployment: shipment-exception-commander.vercel.app
• Systemstatus: Fail-closed-Status des Agenten

Shipment Exception Commander ist bewusst enger gefasst als ein Logistik-Copilot. Die Anwendung gibt genau ein überprüfbares Versprechen: anhand versionierter Belege empfehlen, die Empfehlung hinterfragen, für die konkrete Aktion einen Menschen um Freigabe bitten, den Zustand genau einmal ändern und genügend Nachweise hinterlassen, um den Ablauf zu rekonstruieren.