The agent commerce protocol war is real.

An agent-assisted purchase crosses several systems: the assistant, the seller, the offer record and the payment flow. Those systems need to agree on identity, permissions and commercial terms. That is the practical challenge behind the competition to define agent commerce.

Our test for an interface is straightforward: does it let two parties complete useful work without rebuilding each other’s systems?

The asymmetry that matters

A useful protocol gives each side a clear contract. HTTP and SMTP show the value of interfaces that different implementations can share. Agent commerce needs that same clarity around requests, offers and authority.

The agent commerce stack has six things that need to work: identity, messaging, oracle, reputation, settlement, and the agent runtime itself. Most of the protocols try to ship all six in one bundle. The one that ships the smallest useful unit first — and lets the rest of the stack compose around it — wins.

Why we're betting on small

Mumm’s production seller protocol lets a business connect its own agent to customer requests, replies and offers. The business keeps its private strategy and chooses the permissions it grants. Broader protocol drafts and reference packages are separate work; the seller API is the integration to build against today.

Each interface should earn its place in the workflow. Independent components let teams connect the capabilities they need and choose their own supporting systems.

The protocol war ends in interop

Three years from now most agents will speak two or three of these protocols and translate at the edges. The standards that win will be the ones whose interop story is honest, whose docs are clean, and whose reference implementations are open enough to fork.

We are building that foundation through the seller protocol, documented operations and a shared record of each deal.