What a Buyer's AI Sees When It Looks at Your Checkout
Every GoCushy offer publishes a machine-readable contract as JSON at its own URL, fetchable by anyone without a key, plus a live quote endpoint that returns the real total for a given country using the same server-side code that charges the card. So a buyer's AI can state your price as a fact instead of inferring it from a sales page. What that does not mean: an AI cannot complete a purchase by itself here. The buyer-facing path hands back a checkout link for a human to authorise, and there is no cross-merchant search — an agent has to be pointed at a seller it already knows about.
Someone asks their assistant to look at your offer and tell them what it costs. There are two ways that question gets answered, and the difference between them is the whole subject of this post.
The first way is the one that happens by default today. The assistant fetches your sales page. That page is HTML written for human eyes — a headline price, a struck-through number beside it, an order bump described in a sentence halfway down, a coupon mentioned in a section that has been stale since last year, and a tax line that says nothing because tax depends on where the buyer lives. The model reads all of that and picks a number. It is a reasonable guess. It is still a guess.
The second way is that the assistant asks the server. That is what I built, and it is unglamorous in exactly the way infrastructure should be.
Every offer publishes a contract
Each GoCushy offer has a machine-readable contract published as JSON at its own address. No key, no application, no partnership call. Anyone can fetch it, and so can any AI.
The contract states, in plain fields:
- The offer name and currency, whether it is currently available, and if it is not, why not.
- The checkout address and the quote address.
- The product name and description, the price in cents, the billing type, and how the product is delivered.
- The headline and bullet content a human would see on the page, so the machine and the person are reading the same claims.
- Any order bump and its price, and whether coupons are available at all.
- Which payment rails are live, the tax position, and the seller's legal name and tax details.
- A plain statement that charges settle on the seller's own account, that GoCushy is not the merchant of record, and that we never hold funds.
That last line is there because an agent evaluating a purchase should be able to see who it is actually transacting with. The answer is you, not me.
The quote endpoint is the part that matters
A static contract still leaves the hardest number unanswered, because the real total depends on the buyer. So there is a live quote endpoint alongside it. Send it a country and it returns the subtotal, any discount, the tax, and the real total.
Those are not modelled numbers. They are computed by the same server-side code that computes what the buyer gets charged at checkout. Prices on GoCushy are always calculated on the server — the client never decides what something costs — which means the quote an agent fetches and the amount that hits the card come out of one code path. There is no second implementation to drift.
Here is why I care about this so much. A guessed price is a support ticket. Somebody's assistant told them $49 including tax, they arrive at a checkout that says $56.35, and now you are answering an email about a discrepancy you did not create and cannot see. A fetched price is a fact. It either matches or the system is broken, and if it is broken it is broken in one place that I can fix.
What this is not, said clearly
I want to be careful here, because the agentic-commerce conversation runs well ahead of what anybody has actually shipped, and the credibility of a claim like mine is destroyed by one exaggeration.
Publishing a machine-readable offer is not the same thing as an AI completing a purchase autonomously. On GoCushy today, the buyer-facing path returns a checkout link for a human to authorise. Payment stays buyer-authorised. An agent can research, compare, quote, and hand over a link — it cannot spend money on someone's behalf without them.
There is also no cross-merchant search. A buyer's agent cannot browse GoCushy looking for offers. It has to be pointed at a seller it already knows about — from a link, an email, a conversation, a page it was reading. What I have built is a way for your offer to answer honestly when it is asked. It is not a distribution channel, and I would rather say that than let you infer otherwise.
The other direction: your AI, your store
The buyer's side is only half of it. GoCushy's MCP server exposes 57 tools for merchants, and connects to Claude and ChatGPT as a first-class connector using standard OAuth. That means your own AI can operate your store — the offers, the pricing, the day-to-day work — while the buyer's AI reads the contract from outside. Same system, two audiences, one set of numbers underneath.
If you want the field-by-field detail rather than my summary of it, it is written up in the developer docs.
Why I shipped this before anyone asked for it
Almost nobody is fetching these contracts yet. I built them anyway, because the cost of publishing structured truth about your own prices is close to zero and the cost of being unreadable later is not. The sales page will keep doing its job for humans. The contract does the job for everything else that shows up asking.
GoCushy is $295 one-time for lifetime access, with 0% platform fees on that plan. Every offer you build on it publishes its contract and its quote endpoint by default — there is no setting to switch on, and no tier where the machine-readable version costs extra.