When should the EU swap its checkout-screen consumer rules for rules built into the shopping software AI agents actually use?

This explores when EU consumer rules written for screens and buttons should be rebuilt as rules inside the protocols that AI agents use to transact with each other. The core argument comes from Busch's CERRE paper Can EU consumer law rules survive agent-to-agent API transactions?. Much of EU consumer law assumes a human is looking at a page: a clearly labelled payment button, a disclosure shown before checkout, a withdrawal form you can find. When one agent buys from another through an API, there is no page, so these rules don't get weaker. They stop applying to anything at all. Busch's answer is to keep the right and move it to a new place: a withdrawal right becomes a withdrawal API, and a disclosure becomes a machine-readable field the buyer's agent has to receive. So the first answer to 'when' is: once a meaningful share of transactions never reaches a human-facing interface.

The corpus offers less on the next question, which is how early to act. O'Reilly argues that protocols are not neutral plumbing. They shape markets, and MCP shows how a shared standard can turn a winner-take-all race into a field where several vendors compete Do protocols reshape markets by enabling multi-vendor competition?. That cuts both ways for regulators. If they write obligations into protocols early, they can shape which standards win. If they wait, the rules may get set by whichever platform's protocol dominates. Boboev's map of agentic commerce standards (ACP, AP2, UCP, Visa's TAP, Mastercard's Web Bot Auth) shows these protocols stacking as layers for application, governance, discovery and identity rather than replacing each other Do agentic commerce protocols compete or complement each other?. That points to a practical timing rule: attach consumer obligations to the layer that has already settled. A withdrawal API belongs in the transaction or governance layer, not in a discovery protocol that may not survive. Research on coordination standards points the same way. Rules that wrap and bridge existing protocols get adopted, and rules that require a rewrite of the whole ecosystem don't Should coordination protocols wrap existing systems or replace them?.

The corpus also raises a warning a regulator might not expect: meeting a protocol rule is not the same as giving the protection the rule was meant to give. In the Honest Quorum work, validators can follow the protocol perfectly, reach consensus, and still approve an invalid result. Following the protocol proves the steps ran, not that the outcome was right Can a quorum of honest validators certify an invalid transition?, Can validator consensus guarantee both agreement and semantic correctness?. The same pattern shows up wherever every component passes its local check while the overall system still fails Can individual components pass safety checks if the system still fails?. Turned around, a correct outcome can also hide steps that were skipped Can a correct outcome hide protocol violations in multi-agent systems?. For consumer law, this means a withdrawal endpoint that answers properly is not proof that a consumer could actually withdraw. Protocol standards need outcome-level auditing alongside them, or they become the API version of a checkbox.

There is one more complication. Production teams often avoid standard protocols altogether. One practitioner study found MCP-mediated tool calls unreliable enough that teams switched to direct function calls, and 85% of surveyed teams build custom agents Why do protocol-based tool integrations fail in production workflows?. If obligations attach only to named protocols, a lot of agent commerce may route around them. That suggests writing the obligation as a duty to provide a function (such as 'a withdrawal must be machine-callable') that can be met by any protocol or none, rather than requiring a particular standard. A useful model is how MOISE+ separates who does what (roles and plans) from what is permitted or required Can separating structure and function improve multiagent organization design?. Rights can be defined as obligations that hold whatever technical structure carries them.

An honest caveat: the corpus has one paper aimed squarely at EU law (Busch), and none on regulatory timing, enforcement capacity, or how standards bodies would carry this out. Putting the pieces together, the answer looks like this: translate the rules when transactions leave the screen, attach them to protocol layers that have settled, write them as functions any system can provide rather than as named standards, and never treat protocol compliance as evidence that consumers were actually protected.