Questions about the planned cross-sell / upsell capability

[arjun2075]

I've been thinking about the cross-sell / upsell work on the roadmap, mostly from the buyer-agent and payments side.

One thing I like about the existing discount capability is that the important commercial details are structured, rather than something an agent has to infer from page copy.

That made me wonder if offers should follow a similar pattern.

1. Should an offer be its own object?

My instinct is that an offer probably needs to be its own object, rather than something the agent has to infer from merchant content.

At minimum, it seems useful to make the actual change explicit:

• what gets added or changed
• price delta
• whether it's one-time or recurring
• fulfillment impact
• expiry/version
• where the offer came from

Recurrence feels especially important.

A $20 accessory and a $20/month service might look similar if you only look at the immediate cart change, but they're obviously very different decisions for a buyer agent.

I'd rather have that distinction be explicit than something the agent has to figure out.

I'm also curious whether offers eventually need a stable ID, signature, or version so there's a clear record of exactly what the agent evaluated and accepted.

2. What about claims inside an offer?

Offers will probably contain claims like:

• "save $30 when bundled"
• "compatible with the product you're buying"
• "ships together at no additional cost"

Does UCP need any concept of evidence behind those claims?

I'm not suggesting every marketing statement needs to be cryptographically verified, but it seems useful if an agent can distinguish between:

• the merchant says this
• there's some structured evidence I can check
• a third party has attested to it

That feels especially useful for things like compatibility, savings, or fulfillment claims that might actually affect whether the agent accepts the offer.

3. I think decision data should stay separate from merchant copy

This seems important once the agent can actually spend money.

Merchant-originated offers are untrusted input, while the system reading them may also have purchasing authority. AP2's threat model already assumes prompt injection isn't something we can just make disappear.

So my bias is that anything the agent uses to make the purchase decision should be structured data.

The human-readable copy can still be there, but I wouldn't want the agent figuring out the actual transaction from merchant-written text.

For example, an agent shouldn't have to read:

"Great deal! Add two more and save..."

and infer what it's actually agreeing to.

Ideally the decision-relevant part is more like:

add X, price changes by Y, recurrence is Z, fulfillment changes in this way

and the marketing copy is just presentation.

Curious whether others think that separation should be part of UCP itself or left to implementations.

4. Where should the AP2 authorization boundary sit?

This is probably the part I'm most curious about.

Say a buyer agent is operating without a human present and accepts an upsell. The cart is now different from what it looked like before the offer.

How should that change relate back to the buyer's mandate?

For example, maybe the buyer has effectively said:

accessories are okay up to $25

A single $20 add-on seems straightforward.

But what if the merchant presents five separate $20 add-ons?

Each one individually fits the rule, but accepting all five probably isn't what the buyer meant.

That makes me think cumulative limits matter here, not just per-offer limits. Otherwise you can satisfy the authorization one offer at a time while still ending up somewhere the buyer probably never intended.

Maybe the mandate needs to be able to express things like:

• allowed categories
• max increase per offer
• max cumulative increase
• whether recurring items are allowed
• maybe a limit on how many modifications can be accepted

I'm less sure where that policy should live.

My guess is that UCP should make the offer and resulting cart change very explicit, while AP2 handles whether the buyer actually authorized that class of change.

But I'm curious how others see that boundary.

5. Could the buyer agent ask for offers too?

When we say cross-sell / upsell, is the expected flow mainly that the merchant notices the cart and proposes something?

Or could the buyer agent initiate it too?

For example:

I'm buying this laptop and also need a compatible travel charger under $40. Do you have anything?

That feels like a pretty natural agent flow, but it starts looking more like buyer/seller negotiation than traditional checkout upsell.

If that's eventually in scope, there's probably another question around disclosure.

The buyer agent might know the user's actual budget, urgency, preferred brands, acceptable substitutes, etc. It probably shouldn't reveal all of that just because it's asking for offers.

So I'm curious whether buyer-initiated solicitation is part of the longer-term model, and if so whether disclosure boundaries for the buyer agent are something UCP expects to handle.

Some of this may be early given where the roadmap is, but these seem like useful things to think through before agents are routinely accepting merchant-generated offers without a human in the loop.

Curious how others are thinking about this, especially where the UCP / AP2 boundary should sit.

[westonale]

On your second question, the evidence layer: that is being specified next door, and it is probably worth pointing at rather than building trust semantics into the offer object.

#534 and #535 define an envelope for exactly the distinction you drew. A third-party claim rides as a compact JWS, keyed by signal name, verified offline against a pinned JWKS. There are working profiles from three independent issuers across three signature algorithms on the registry today, with a conformance gate that verifies the committed vectors rather than regenerating them.

What that buys you is that your three tiers stay cleanly separated, and only one of them needs new protocol:

• the merchant says this: a field on the offer, no trust machinery required
• structured evidence I can check: a field the agent recomputes for itself, such as a price delta it verifies against the cart it already has
• a third party has attested to it: a signal in the envelope

Only the third needs anything new, and it is being written. Putting attestation semantics inside the offer object would duplicate that work, and worse, it would make the offer object a party to the claims it carries.

Where I would push back is on sequencing. You framed stable IDs and versioning as a maybe-later, after the evidence question. I think they come first, because evidence you cannot bind to a specific artifact is not much use in the dispute it exists for. If an agent accepted offer X at time T and the merchant later changes what X means, an attestation about "offer X" points at nothing in particular. Attestation needs something immutable to attest about, so the identifier is the dependency, not the polish.

Recurrence has the same property, and I would go further than your framing: it is not a display concern at all. A one-time $20 accessory and $20 a month are different authorizations, not different presentations of one. A buyer agent operating under a mandate has to check the offer against that mandate before it accepts, and if recurrence is inferable rather than declared, that check either does not happen or happens wrong. It also fails in the worse direction, with the agent committing to a recurring obligation nobody cleared, which is the class of error you find out about a month later.

[arjun2075]

This is really helpful — especially the point about evidence needing something immutable to bind to.

I was thinking about stable ID/versioning mostly as auditability, but I think you’re right that it’s more fundamental than that. If an attestation is going to say something about an offer, there needs to be an exact artifact that both the agent and verifier can identify later.

That pushes me toward something like an immutable offer revision, potentially with a digest over the decision-relevant fields, rather than treating offer_id alone as the thing evidence binds to. Curious if you’d see id + revision as sufficient here, or whether you’d bind the signal to a content digest directly.

Also agreed on not putting attestation machinery inside the offer itself. I hadn’t connected #534/#535 to this when I wrote the question, but the separation makes sense: merchant assertions stay on the offer, something deterministic like a price delta can be recomputed by the agent, and third-party evidence rides the Signals envelope.

Your recurrence point changes my thinking too. I was treating it as one of several fields an offer might expose, but for an autonomous buyer it’s really part of the authorization-relevant transaction semantics. $20 once and $20/month can’t be allowed to collapse into the same immediate price delta.

I still wouldn’t want the offer object to invent a separate subscription model, but I do think it should be required to make any recurring obligation explicit, using whatever recurrence semantics the underlying commerce object defines.

Thanks — this helps narrow the boundary quite a bit. I’m also narrowing this into a focused follow-up proposal, with identity/state binding as the core idea. I’ll link it back here once it’s ready.

[arjun2075]

Posted the narrowed follow-up proposal here: #702 — it makes the identity/state-binding discussed above the core of the design.