The Registry

The Registry / Specification

Negotiation Extension for Agentic Commerce

Version 2026-09-23-draft · Status: draft for review · Maintained by Bidit · Reference implementation: Bidit · Live index: The Bidit Registry

AI shopping agents can already discover products, compare prices and complete checkout through commerce protocols such as UCP. What they cannot yet do, in any standard way, is negotiate: make a merchant a private offer, receive a counter, and carry an agreed price into the merchant's own checkout. This document defines that missing capability.

The design goal is simple and strict: one customer, one price, one moment, never published. The merchant sets a floor the buyer never sees; the engine holds it on every round. Public prices stay intact. Agreed prices are private to the buyer who won them.

1. Roles

2. Discovery

A buyer agent MUST resolve negotiability before making or promising an offer. Two discovery paths are defined, checked in this order:

2.1 Merchant profile. A merchant that accepts offers declares this capability in its UCP business profile (/.well-known/ucp), naming the engine endpoint that handles offers.

2.2 Index lookup. Where no merchant profile exists, the agent queries a negotiability index. The Bidit Registry serves the whole market at /.well-known/negotiability.json and a single merchant at /api/merchants/<slug>. The index gives exactly two answers: yes (with the offer rules) or not yet (with an optional demand-registration recipe, section 7). There is no third state. An index MUST NOT describe a merchant as negotiable unless that merchant's engine will actually accept offers.

3. The six verbs

The full negotiation lifecycle reduces to six verbs:

  • · negotiable — the discovery answer: can this merchant, and this product, take an offer?
  • · offer — the buyer names a price for a product and quantity.
  • · counter — the engine proposes a different price back.
  • · accept — either side agrees; the price is locked for a hold period.
  • · decline — the engine passes; attempts remaining are reported.
  • · token — the proof of an agreed price, honoured at the merchant's own checkout.

4. The offer operation

make_offer(merchant, product_id, offer_amount, quantity, session_id) returns exactly one outcome:

  • · accepted — includes agreed_price, token, expires_at. The negotiation is closed: the buyer cannot re-offer lower afterwards.
  • · countered — includes counter_offer_price and a token for accepting it. Also closes the negotiation: checkout at the countered price, or walk away.
  • · declined — includes attempts_remaining. A final decline MAY lock the product for a cooling period (reference implementation: 24 hours).
  • · blocked — attempts exhausted or product excluded.

Attempt limits are engine-enforced per product per buyer session (reference implementation: 2). Sessions are stable identifiers supplied by the agent so attempts are counted honestly across a conversation. Engines SHOULD return a human-voiced say line so the agent can relay the merchant's answer in the merchant's own voice rather than system language.

Non-price levers. After a price is agreed or countered, the agent MAY pass an ask in the shopper's words (delivery, warranty, a bundled item). The engine answers each matched item: yes (included), no_but (available at a quoted price, optionally free above a stated total), or no. A higher offer against an agreed deal is a trade, not a new attempt, and cannot exceed the list price.

5. Token and checkout handoff

An accepted or countered outcome yields a token binding merchant, product variant, quantity, agreed price and expiry (reference implementation: 48-hour hold). Redeeming the token at the merchant's own checkout applies the agreed price with no extra step for the shopper. The merchant remains the seller of record; the engine never holds funds. Where the checkout is UCP checkout, the token travels as a discount application; on Shopify today it is a discount code scoped to the variant.

6. Invariants

  • 1. Two answers only at discovery: yes, or not yet. Never anything in between.
  • 2. The merchant's floor is never disclosed, in any response, error or hint.
  • 3. Agreed prices are private: never published, never shown to other buyers, never fed to price comparison.
  • 4. Attempt limits are enforced by the engine, not trusted to the agent.
  • 5. Accepted and countered outcomes close the negotiation; no lower re-offers.
  • 6. The ticket price is untouched: negotiation never changes public prices.
  • 7. An agent MUST relay outcomes truthfully and MUST NOT present a declined offer as pending or accepted.

7. Demand registration for non-participating merchants

When discovery answers not yet, the index MAY offer demand registration: the buyer's intended offer (product, price), contact address, and explicit consent to be contacted about that merchant. Consent is mandatory and MUST be enforced at storage, not just at the form. Registered contact details MUST never be exposed through any public interface; merchants see aggregates only. The Registry implements this at POST /api/intents; the per-merchant answer embeds the recipe.

8. Capability declaration

Declared in UCP capability form, in an agent profile, a merchant business profile, or an index entry:

{
  "au.com.bidit.shopping.negotiation": [
    {
      "version": "2026-09-23-draft",
      "spec": "https://registry.bidit.com.au/spec",
      "schema": "https://registry.bidit.com.au/spec/schemas/negotiation.json",
      "extends": [
        "dev.ucp.shopping.catalog.lookup",
        "dev.ucp.shopping.checkout"
      ]
    }
  ]
}

The machine-readable schema for every request and response in this document: /spec/schemas/negotiation.json

9. Conformance

  • · An engine conforms if it implements the offer operation with the four outcomes, enforces the invariants, and issues checkout-redeemable tokens.
  • · An index conforms if it answers negotiability with the two-answer rule and never overstates a merchant's participation.
  • · An agent conforms if it resolves discovery before promising negotiation, relays outcomes truthfully, and obtains explicit consent before any demand registration.

10. Status and feedback

This is a draft published for review. Bidit operates the reference implementation (live on 9 merchants at publication) and the Registry (1,000+ merchants indexed across 20 countries). Proposals, corrections and implementations are welcome via bidit.com.au.