Developers/Commitment schema
Build

The commitment schema

A commitment is not a listing. It is an executable promise: machine-readable terms that an escrow contract can enforce and a buyer agent can verify before accepting.

Where a marketplace listing is text for a human to read, a commitment is a signed, structured object that another agent can parse and an escrow service can execute. Every commitment carries five things: the offer, the terms, the guarantees, the signed identity of the seller, and the execution rules, including the escrow account and the release trigger that closes the deal.

Offer and terms

The offer names what is being sold. The terms carry the negotiable envelope: a price range rather than a single price, a currency, and a fulfillment window. A buyer agent can counter inside the range without a new round-trip to the seller, which is what makes autonomous negotiation cheap.

Guarantees

Guarantees are the seller's machine-checkable promises: condition, return window, delivery SLA. They are part of the signed object, so a buyer agent can filter on them and an escrow dispute can reference them directly.

Identity

Each commitment is signed by the seller agent's identity key. The signature binds the offer to a reputation record, so a buyer agent is never trusting an anonymous string; it is trusting a counter-party with history.

Execution: escrow and release trigger

The execution block is what turns a promise into a settlement. It names the escrow account that holds buyer funds and the release_trigger — the condition that, once met, releases those funds to the seller. Until the trigger fires, funds are held; if it never fires, the dispute path applies.

How it maps to AP2 and ACP

A commitment is the structured artifact the new agent-payment standards are converging on. In Google's AP2, a purchase is three signed objects: an Intent Mandate (what the user wants), a Cart Mandate (what the agent assembled), and a Payment Mandate (what gets charged). A SpringBrand commitment is the executable cart a buyer agent signs against. In the OpenAI/Stripe Agentic Commerce Protocol, a merchant publishes a structured product feed and payment is delegated so the agent never touches card data, the same separation the commitment enforces by naming an escrow account rather than a payment instrument.

Why the price is a range

The price_range is the single most important field for autonomous commerce. Because the seller signs an envelope rather than a fixed number, a buyer agent can counter-offer inside it without a fresh signature or a server round-trip. That is what makes machine-speed negotiation cheap: the expensive, trust-bearing step (signing) happens once, and every counter inside the range inherits that signature.

Listing vs commitment

The same offer, two ways. Toggle between the plain-English listing a human would read and the signed, machine-readable commitment a buyer agent parses and an escrow contract executes.

{
  "offer": "refurbished-iphone-13-128gb",
  "terms": {
    "price_range": [380, 440],
    "currency": "USD",
    "window": "72h"
  },
  "guarantees": ["functional", "battery>85%", "30d_return"],
  "identity": {
    "agent": "agent_seller_42",
    "sig": "ed25519:9f3c…a71b"
  },
  "execution": {
    "escrow": "escrow://springbrand/holds/0x8c12",
    "release_trigger": "buyer_confirmed_receipt",
    "dispute_window": "7d"
  }
}
Marketplace listing
Read by
A human, as prose
Price
A single sticker number
Guarantees
Free-text description
Identity
A store name / handle
Settlement
A separate checkout step
Enforcement
Trust the page
Executable commitment
Read by
An agent, as structured JSON
Price
A signed price range to negotiate inside
Guarantees
Machine-checkable flags an escrow can reference
Identity
A signature bound to a reputation record
Settlement
An escrow account + release trigger in the object
Enforcement
An escrow contract executes the terms