Lab experiment
Universal Commerce Protocol
Exploring how open commerce protocols could let agents act through standardized capabilities instead of platform-specific integrations.
This diagram is a working model, not a deployed architecture.
observations
A protocol boundary in front of a mature platform
The question I keep coming back to is how an agent-facing commerce protocol could sit in front of an existing ecommerce platform without the catalog, pricing, checkout, payment, identity, and order systems being redesigned around AI.
That is interesting to me because it approaches boundaries I already know from a new direction. Instead of every AI platform needing a custom integration, commerce capabilities could be exposed through a common protocol while the merchant platform keeps owning its business logic and its commerce state.
system flow
Where the boundary would sit
- 01Agent
An AI platform acting on behalf of a person.
- 02Capabilities
Discovery, catalog, identity, checkout, orders.
- 03Mapping
Capabilities resolved onto existing platform APIs.
- 04Platform
Commerce logic, payments, and order state stay put.
next questions
Open questions
- Where should the agent-facing boundary sit in an existing architecture?
- Which capabilities map cleanly onto current APIs, and which need orchestration?
- How should identity and authorization cross the agent-to-commerce boundary?
- How would agent-facing checkout coexist with an existing hosted checkout?
- How do payment responsibilities stay clearly separated?
- How does a protocol surface coexist with REST, GraphQL, and MCP-style integrations?
- How do merchants keep control while agents still perform useful actions?
observations
Current scope
The current scope is how an agent-facing protocol could map onto real commerce architecture and where that interface would meet existing platform APIs.
Still exploring
Thinking about the same problem?
I'm always interested in what works, what fails, and how to test the difference.