[Covenant0028]

> Agents, while leveraging similar systems, are serving a site's end consumer. When I use an agent to shop, I'm still the customer of the shop. As the shop owner, I want to give the best experience therefore it's in my best interest to provide an AX that supports them providing a good experience to the end user.

This is fine until the agent decides to order something the customer did not want. This is inherent to the concept of an agent. Due to the probabilistic nature of LLMs, and the fact that no agent will ever be perfectly able to predict exactly what you want at the time you want, this scenario is inevitable.

As the shop owner, this would result in an increased numbers of returns. You could recommend that the user must approve the purchase, but given that you do not define these agents, there is no way for you to ensure that the user is actually following your advice.

[javasquip]

There are ways to ensure that the end user provides authorization. While the shop owner does not control the agent it does control purchase authorization - primitively that could look like requiring a pin/cvv, confirming via text sent code, etc. This concept can recursively assume that an agent can do these things on the user's behalf but this is where limits come in, compliance regulations, etc. It's not in the shop's or the agent's interest to integrate poorly within these flows. That said, this is where we should establish the conventions that we can enforce consistency and compliance as well as validate them. It wouldn't be hard to imagine that an agent must prove they are operating correctly before they can initiate actions such as purchase requests and then the agent's authority is known and can be held accountable for misuse.