SAAX Protocol: A Commitment Layer for Agentic Commerce

When an AI agent buys something and the purchase goes wrong, the parties usually discover the same problem: there is no structured record of what was actually committed.

The authorization was valid. The credentials were real. The merchant fulfilled a legitimate order. The buyer is looking at a charge for something they never intended to purchase. Card networks were built for a two-party dispute. Stablecoin rails were built for instant, irreversible settlement. Neither was designed to answer the question that matters here: what did the agent actually commit to, and did the merchant deliver it?

I've been building a protocol layer for this problem. It's called SAAX Protocol — Solvent Applied Autonomous Exchange Protocol. A vendor-neutral commitment lifecycle for autonomous commerce.

The gap in the stack
Most agent commerce infrastructure handles two layers:

Authorization — proves that a party with valid credentials authorized a specific transfer of value. This is what AP2, ACP, and the card networks handle.

Settlement — moves the value on the specified rail. This is what x402, MPP, and payment processors handle.

Between them, there's a missing layer: the commitment. What the agent actually agreed to, what counts as fulfillment, what proves it, and what happens when it fails.

Without the commitment layer, the payment layer is trying to do work it was never given the terms for. It approves transactions it should not approve and disputes transactions it cannot evaluate.

What a SAAX commitment records
A commitment binds five things before execution begins:

Authority — who authorized the agent to act, under what scope, with what limits

Terms — what was agreed: price, deliverable, deadline, conditions

Acceptance criteria — what objectively counts as fulfillment

Evidence requirements — what proof must be submitted

Recovery policy — what happens if fulfillment fails

The commitment is issued before payment. Evidence is attached as references. Outcome and finality states are recorded against the same commitment.

The in-flight state
The hardest case is what happens when the agent's first attempt leaves the machine and never returns a response. The commitment ID is on the wire. Settlement may already be in flight. A naive retry with the same ID races the merchant's accept path.

The protocol rule: an unknown outcome is a status check, not another POST.

The agent queries the commitment state before retrying. not_found means safe to retry. in_flight means wait. fulfilled means stop. failed means retry with a fresh commitment ID.

On the merchant side, the rule is equally clear: write in_flight to durable storage before processing the request. The write is the lock. A second request with the same commitment ID returns in_flight — it isn't processed again.

Both sides need both rules. Neither alone closes the gap.

What's live
The protocol has a working reference implementation:

Spec: saax-protocol.com/spec

Conformance suite: saax-protocol.com/conformance — 61/61 vectors passing

Docs: saax-protocol.com/docs

MCP endpoint: https://www.saax-protocol.com/mcp — 10 tools, free to test, no signup

Registry listing: io.github.bryantrudy24/saax-protocol version 1.0.3

The protocol is vendor-neutral and open for comment. The Router is one implementation of it — the settlement layer uses x402 and MPP, but the Protocol itself doesn't require any specific rail.

Why I'm sharing this
I'm not pitching a token or a product. I built this because the commitment gap is real, and the infrastructure being built around agent commerce (AP2, x402, MPP, UCP, ACP) doesn't include it. If you're building agents that transact, I'd like to know whether a shared commitment layer is useful to your stack — and where the spec is thin or unclear.

The MCP endpoint is live. The conformance suite is public. The spec is open. If this solves a problem for you, I'd want to hear how. If it doesn't, I'd want to hear that too.