Protocol adapters are one of the easiest places for agent-commerce architecture to drift.
An adapter begins with the narrow responsibility of translating an external protocol request into something the commerce platform understands. For example, an MCP-style tool may ask for return terms, an ACP-style interaction may ask whether checkout can be prepared, an AP2-related flow may carry payment authority information, and an internal feed may publish product capabilities.
Those are adapter concerns at the boundary.
The problem starts when the adapter does more than translate. It checks product availability from catalog fields. It interprets policy text. It decides whether checkout is ready. It treats a payment artifact as authority. It turns a domain blocker into a softer protocol response.
Each shortcut may solve an integration problem locally, but it also creates a second place where commercial meaning is decided.
