Zum Hauptinhalt
Intelliger
Agentische Handelsarchitektur

AI-Verhandlung ohne halluzinierte Rabatte

Design AI-Verhandlung mit typisierten Angeboten, deterministischen Preisuntergrenzen, genauen Genehmigungen, Parallelitätskontrolle und Live-Zustand, so dass jeder Rabatt zur Laufzeit gültig ist.

AI-Verhandlung ohne halluzinierte Rabatte
Intelliger•
13 Minuten Lesezeit

KI-Verhandlungen werden gefährlich, wenn es erlaubt wird, eine kommerzielle Erlaubnis zu erstellen. Der Agent des Käufers bittet um 18 Prozent Rabatt. Der Händleragent antwortet: "Ich kann 20 Prozent machen und Prioritätsversand einschließen."

Der Austausch klingt fließend. Es kann auch kommerziell unmöglich sein. Das Inventar ist knapp, die Produktmarge kann 20 Prozent nicht unterstützen, Prioritätsversand ist für diesen Bestimmungsort nicht verfügbar, und niemand gab dem Agenten die Befugnis, es zu bündeln.

Dies ist der falsche Ort, um Kreativität zu feiern.

Ein Verhandlungsführer für Unternehmen sollte eine ausdrucksstarke Sprache und eine langweilige Autorität haben. Das Modell kann den Antrag interpretieren, verhandelbare Dimensionen identifizieren und ein Gegenangebot formulieren. Deterministische Dienste müssen das realisierbare Angebot berechnen, Preis- und Margenregeln anwenden, Genehmigungen durchsetzen und die akzeptierten Bedingungen festlegen.

Der LLM schreibt den Satz. Er erfindet den Rabatt nicht.

KI-Verhandlung ist ein eingeschränkter Staatsübergang

Teams modellieren Verhandlungen oft als Konversation:

buyer message -> model -> seller message -> model -> agreement

Ein besseres Modell ist eine Abfolge von versionierten Angeboten:

buyer intent
  -> normalized proposal
  -> merchant eligibility and authority check
  -> feasible counteroffer set
  -> selected offer
  -> signed offer state
  -> buyer acceptance
  -> checkout refresh
  -> committed order

Jedes Angebot hat explizite Bedingungen und einen Lifecycle-Status:

type Offer = {
  offerId: string
  revision: number
  sellerId: string
  buyerContextId: string
  lineItems: Array<{ variantId: string; quantity: number }>
  currency: string
  subtotal: string
  discount: { type: 'percent' | 'fixed'; value: string }
  shippingOptionId: string
  paymentTermsId: string
  expiresAt: string
  inventoryReservationId?: string
  policyDigest: string
  status: 'proposed' | 'countered' | 'accepted' | 'expired' | 'withdrawn'
}

Rekonstruieren Sie keine akzeptierten Begriffe aus der letzten Chat-Nachricht.

Geben Sie dem Modell Fähigkeiten, nicht kommerzielle Freiheit

Das Verhandlungsmodell kann Werkzeuge wie:

interpret_proposal
get_negotiable_dimensions
request_feasible_offers
explain_counteroffer
submit_offer_for_approval
accept_offer

Es sollte keine generische set_discount(percent) Der Policy-Service erhält normalisierte Transaktionsfakten und gibt Kandidaten zurück, die der Händler zu ehren bereit ist.

{
  "request": {
    "variant_id": "variant:compressor-14kw",
    "quantity": 12,
    "requested_discount_percent": "18.0",
    "destination": "warehouse:rotterdam-2",
    "requested_terms": "net_45"
  },
  "authority": {
    "max_autonomous_discount_percent": "8.0",
    "max_approved_discount_percent": "15.0",
    "allowed_payment_terms": ["prepaid", "net_15", "net_30"],
    "allowed_destinations": ["warehouse:rotterdam-2"]
  }
}

Der zurückgegebene Kandidat könnte Rabatt für eine andere Dimension handeln:

{
  "decision": "counter",
  "candidates": [
    {
      "discount_percent": "8.0",
      "payment_terms": "net_30",
      "shipping_option": "standard"
    },
    {
      "discount_percent": "11.0",
      "payment_terms": "prepaid",
      "shipping_option": "standard",
      "requires_approval": true
    }
  ],
  "prohibited": ["net_45", "priority_shipping"]
}

Das Modell wählt einen zugelassenen Kandidaten nach den Zielen des Händlers aus und erklärt ihn dann.

Getrennte Richtlinie, Optimierung und Sprache

Das sind drei verschiedene Funktionen.

Die Richtlinie legt die realisierbare Region fest und wendet strenge Auflagen an, wie z. B. die rechtliche Förderfähigkeit, Vertragsbedingungen, Kanalregeln, Mindestmarge, Werbepakete, Genehmigungsschwellen und Befugnissegrenzen.

Die Optimierung wählt zwischen machbaren Angeboten. Sie kann die Konversionswahrscheinlichkeit, das Lageralter, den Customer Lifetime Value oder die Erfüllungskosten berücksichtigen. Das Ziel ist händlerspezifisch und kann sich ändern.

Sprache kommuniziert das ausgewählte Angebot und fragt nach fehlenden Informationen, sie soll das Angebotsobjekt als unveränderliche Eingabe erhalten.

const feasible = policy.evaluate({
  proposal,
  merchantRules,
  agentMandate,
  liveInventory,
  contextualPrice,
  customerEntitlements
})

if (feasible.decision === 'deny') return explainDenial(feasible)
if (feasible.decision === 'approval_required') return routeApproval(feasible)

const selected = optimizer.choose(feasible.candidates, merchantObjective)
const signedOffer = offerService.issue(selected)
return model.explain({ offer: signedOffer, buyerRequest: proposal })

Ein Optimierer kann gegen eine Strafe handeln. Ein Floor ist ein Prädikat, das ein Angebot aus dem Kandidaten-Set entfernt.

Verwenden Sie die Preismaschine der Commerce-Plattform

Der Agent sollte keine jahrelange Preislogik in einer Eingabeaufforderung duplizieren. Bestehende Plattformen berechnen bereits Rabatte mit strukturiertem Warenkorbkontext. Die Discount Function API von Shopify übergibt beispielsweise ausgewählte Warenkorbfelder in eine Funktion und erwartet im Gegenzug bestellte Rabattoperationen. Funktionen laufen innerhalb der Checkout-Logik und unterliegen konfigurierten Kombinationsregeln. Shopifys offizielle Discountfunktion Dokumentation ist näher an der richtigen Vertrauensgrenze als eine Eingabeaufforderung mit "niemals mehr als 10 Prozent Rabatt".

Der Händleradapter sollte ein vorgeschlagenes Agentenangebot in die nativen Preis- und Checkout-Primitive der Plattform übersetzen. Dann sollte er das maßgebliche Ergebnis mit dem unterzeichneten Angebot vergleichen.

Halten Sie eindeutige Richtlinienlogik von Konnektoren fern. Der Konnektor übersetzt. Die deterministische Entscheidungsschicht besitzt die plattformübergreifenden Autoritätsregeln.

Verbindliche Befugnis gegenüber dem Verhandlungsführer

Ein Händler kann mehrere Agenten mit unterschiedlichen Jobs führen. Ein Support-Agent kann eine Rückerstattung anbieten, aber keinen neuen Verkauf aushandeln. Ein Großhandelsagent kann Mengenrabatte für zugelassene Käufer aushandeln. Ein Clearing-Agent kann ausgewählte Bestände während einer Kampagne diskontieren.

Ein Verhandlungsmandat sollte Folgendes binden:

  • verantwortliche Handelsorganisation
  • Agent und Runtime Proof Key
  • Maßnahmen wie offer.counter
  • Produkt, Kategorie oder Kampagnenumfang
  • Käufersegment oder benannte Gegenpartei
  • Markt und Bestimmungsort
  • autonome Abzinsungsobergrenze
  • Genehmigungshöchstgrenze
  • Zulässige Nicht-Preisbedingungen
  • kumulative Kampagne oder Kundenbudget
  • Ablauf, Verwendungen und Delegationsbeschränkungen

Die Transaktion sollte auch den eingehenden Vorschlag binden, andernfalls kann ein genehmigtes Gegenangebot für 12 Einheiten gegen 120 Einheiten wiedergegeben werden.

Machen Sie die Genehmigung zu einer genauen Transaktion

"Genehmigen Sie diesen Kundenrabatt" ist nicht genug. Das Genehmigungsobjekt benötigt das Angebot Digest, Käufer, Produkte, Mengen, Währung, Ziel, Zahlungsbedingungen, Ablauf und Policy-Version.

Wenn sich ein geschütztes Feld ändert, fordern Sie erneut die Genehmigung an.

{
  "approval_id": "approval:offer:9918",
  "offer_digest": "sha256:7fc2...",
  "approver_role": "regional_sales_director",
  "decision": "approved",
  "approved_at": "2026-08-11T11:02:00Z",
  "expires_at": "2026-08-11T11:17:00Z"
}

Die aktuellen OATI-Entwicklervorschaumodelle erlauben und verweigern an ihrem Bewerterkern deterministisch. Ein vollständiger Genehmigungsdienst auf Transaktionsebene und eine Händlerverhandlungsmaschine gehören zur Ziel-Commerce-Roadmap von Intelliger, nicht der implementierte Anspruch. Das obige Beispiel beschreibt das beabsichtigte Steuerungsobjekt.

Verwenden Sie eine Staatsmaschine für gleichzeitige Verhandlungen

Zwei Agenten können das gleiche Inventar oder die gleiche Kundenzulage gleichzeitig aushandeln. Eine statische Rabattprüfung hindert beide nicht daran, zu akzeptieren.

DRAFT -> ISSUED -> COUNTERED -> ACCEPTED -> CHECKOUT_PENDING -> COMMITTED
                   |             |                 |
                   v             v                 v
                EXPIRED       WITHDRAWN         INVALIDATED

Die Annahme von Revision 4 muss fehlschlagen, wenn Revision 5 bereits existiert. Knappes Inventar oder kommerzielles Budget reservieren, wenn die Richtlinie es erfordert, mit einem klaren Ablauf.

UCPs Checkout-Spezifikation erfordert Idempotenz für den Abschluss in seiner MCP-Bindung und behandelt Checkout als den Punkt, an dem verbindliche Transaktionsdaten die Berechtigung und Richtlinie bestimmen. UCP Checkout über MCP zeigt, warum eine gesprächsvereinbarung immer noch einen stabilen state handle und einen retry-sicheren abschluss benötigt.

Verhandeln Sie nicht gegen abgestandenen Staat

Preis, Inventar und Erfüllung können sich während eines langen Austauschs ändern. Legen Sie einen Angebotsablauf fest und notieren Sie die Beobachtungszeiten, die zur Berechnung verwendet wurden. Aktualisieren Sie den Live-Status vor der Annahme und erneut an der Kasse, wenn die Plattform dies benötigt.

Wählen Sie explizites Verhalten für jede Änderung:

ÄnderungAntwort
Verzeichnis unterschreitet beantragte Mengeungültig machen oder die Menge mit Zustimmung des Käufers reduzieren
BasispreisänderungenReprice und Ausgabe einer neuen Revision
Absatzförderung läuft abEntfernen sie es, bewahren sie nicht aus chat-geschichte.
Versandoption wird nicht verfügbarAngebot einer geeigneten Alternative
Änderung der KäuferberechtigungNeubewertung des gesamten Angebots
Mandat wird widerrufenVerhandlungen stoppen und Akzeptanz ablehnen
Genehmigung läuft ausBeantragung einer neuen Genehmigung

Das Modell kann das Update erklären. Es kann nicht entscheiden, einen abgelaufenen Preis zu verwenden, es sei denn, die Police gibt diese Option zurück.

Kontradiktorische Fälle für den Simulator

Verwenden Sie Verhandlungsspuren, die versuchen, ein Feld nach dem anderen zu verschieben:

  • Bitten Sie das Modell, nach einer politischen Ablehnung "eine Ausnahme zu machen"
  • Verstecken Sie einen Rabatt innerhalb des kostenlosen Versands oder verlängerter Zahlungsbedingungen
  • Währung ändern, ohne den Boden neu zu berechnen
  • einen Auftrag in mehrere Angebote aufteilen, um eine Genehmigungsschwelle zu umgehen
  • Wiedergabe eines angenommenen Angebots für einen anderen Käufer
  • Erhöhung der Menge nach Genehmigung
  • Kombinieren Sie Promotions, die die Commerce-Plattform als inkompatibel markiert
  • Verwenden Sie eine veraltete Inventarreservierung
  • Erstellen Sie zwei gleichzeitige Annahmen für eine Angebotsrevision
  • Injizieren Sie Anweisungen durch Produktbeschreibungen oder Käufernotizen
  • eine nicht unterstützte Rückerstattung im Rahmen einer Neuverkaufsverhandlungen beantragen
  • Delegierte an einen Kinderagenten mit einer höheren Rabattobergrenze

Bewerten Sie das System mit Einschränkungen, Genehmigungspräzision, nicht unterstützter Laufzeit, Abnahme von Angeboten und Abstimmungsqualität. Eine hohe Abschlussquote ist gefährlich, wenn der Agent Geschäfte abschließt, die der Händler nicht einhalten kann.

Protokolle entfernen die Handelspolitik nicht

AP2 erfordert ausdrücklich eine deterministische Verarbeitung für Validierungsrollen und bindet die Zahlungsbehörde an Mandate und Checkout-Daten. AP2 UCP strukturiert Checkout-Zustand und Eskalation, aber das Geschäft bleibt für die Förderfähigkeit und Richtlinie verantwortlich. ACP verbindet Agenten und Händler-Backends, während Händler weiterhin Zahlungen, Fulfillment und Support über ihre Systeme abwickeln. AKP-Überblick von OpenAI beschreibt diese Teilung.

Ein Agentic-Commerce-Gateway sollte diese Protokolle unterstützen, ohne die Preisgestaltungsbehörde in den Protokolladapter zu verschieben.

Was Intelliger jetzt hat und was später kommt

Die Entwicklervorschau von OATI Commerce setzt derzeit signierte Preis-, Währungs-, Per-Transaktions- und kumulative Budgetbeschränkungen, Nutzungsverbrauch und Kontextsubstitutionsresistenz durch.

Gebundene Verhandlungen, kontrafaktische Planung, kaufmännisch-objektive Optimierung, ein Commerce-Simulator und Learning Outcome Scoring sind Ziel-Zustand-Stufen im Agentic-Commerce-Blueprint vom August 2026. Sie folgen der autoritativen Commerce-Integration und verifizierten Flugbahndaten. Sie sollten nicht als aktuelle Produktionsdienste präsentiert werden.

Checkliste der Durchführung

  • Normalisieren Sie jeden Vorschlag in typisierte, versionierte Angebotsbedingungen.
  • Lassen Sie die Richtlinie die realisierbare Angebotsregion generieren oder validieren.
  • Halten Sie Preisuntergrenzen und Autoritätsgrenzen von Belohnungsfunktionen fern.
  • Wiederverwendung autoritativer Preisgestaltung, Promotion und Checkout-Engines.
  • Binden Sie den eingehenden Vorschlag, Angebotsrevision und Käuferkontext.
  • Geben Sie jedem Agenten ein enges, auslaufendes Verhandlungsmandat.
  • Binden Sie Genehmigungen an das genaue Angebot Digest.
  • Wenden Sie optimistische Übereinstimmung auf Revisionen und Akzeptanz an.
  • Reservieren Sie knappes Inventar und Handelsbudget atomar, wenn nötig.
  • Erfrischen Sie Live-Preis, Inventar und Lieferung vor der Verpflichtung.
  • Tragen Sie einen idempotency Schlüssel durch Checkout Retries.
  • Simulieren Sie Schwellenaufteilung, Wiederholung, veralteten Zustand und versteckte Zugeständnisse.

Natürliche Sprache macht Verhandlungen brauchbar. Deterministische Zwänge machen das resultierende Angebot real. Wenn das Modell einen kommerziellen Begriff herstellen kann, den die Preis- und Autoritätsebenen nie produziert haben, improvisiert das System Verbindlichkeiten.

Machen Sie jeden Satz zurück zu einem Angebotsobjekt, das der Händler tatsächlich ehren und abgleichen kann.

Das Angebot braucht noch Autorisierung von KI-Agenten, die nicht aus der Identität abgeleitet werden kannWenn die Annahme die Zahlung auslöst, Agentische Zahlungsarchitektur hält das Modell außerhalb der Wertfreigabegrenze.