Hi — the comparison matrix is genuinely the best neutral reference I've seen on agent payment protocols. I'm working on OM World, an open spec for a decentralized intent economy, and the matrix has been useful as we figure out where our Agent Mandate and Execution Proof primitives sit relative to existing work.
Three questions about axes that either aren't in your matrix yet, or that I think would sharpen what's already there:
1. Shared mandate primitive across the 5 protocols
Your matrix tracks per-protocol delegation: AP2 has IntentMandate/CartMandate/PaymentMandate, ACP has the Delegate Payment Allowance, UCP inherits AP2 mandates. Across all 5, is there a shared abstraction you noticed — "a signed object specifying what the agent is permitted to do, for whom, under what bounds" — or are they fundamentally incompatible shapes that can't be normalized?
I ask because our Mandate primitive is trying to be exactly that shared shape (capability scope tokens with expiry, principal-signed, agent-countersigned). If there's already an emergent commonality I'd like to align rather than invent a 6th model.
2. Cross-protocol budget tracking — why does everyone say "No"?
Your matrix shows cross-protocol budget tracking is "No" across all 5. Is this an inherent limitation (each protocol owns its own settlement state), a coordination failure (nobody's gotten around to it), or an active design choice (each protocol wants its principal to be ignorant of spend on other rails)? If a neutral primitive surfaced — "here's an attestable spend record this protocol emits, here's the verifier" — could the cross-protocol view emerge as a layer above?
3. Proof of execution as a separate axis
Your matrix tracks delegation and budgets very well. There's a related axis I don't see: what proof does the merchant/tool/provider emit that the action actually happened as the principal intended? This is distinct from "settlement happened" (your matrix covers that). For OM World we're specifying a per-step Execution Proof envelope (input_hash, output_hash, tool attestation, optional context_hash for stateful tools). I'm curious whether you've seen any of the 5 protocols surface a proof-of-execution primitive vs. treating settlement as implicit proof — and if you think it's a useful axis to add.
Happy to be wrong on any of these — your matrix is closer to the ground truth than our spec right now. Thanks for the neutrality, it's hard to find on this topic.
Hi — the comparison matrix is genuinely the best neutral reference I've seen on agent payment protocols. I'm working on OM World, an open spec for a decentralized intent economy, and the matrix has been useful as we figure out where our Agent Mandate and Execution Proof primitives sit relative to existing work.
Three questions about axes that either aren't in your matrix yet, or that I think would sharpen what's already there:
1. Shared mandate primitive across the 5 protocols
Your matrix tracks per-protocol delegation: AP2 has IntentMandate/CartMandate/PaymentMandate, ACP has the Delegate Payment Allowance, UCP inherits AP2 mandates. Across all 5, is there a shared abstraction you noticed — "a signed object specifying what the agent is permitted to do, for whom, under what bounds" — or are they fundamentally incompatible shapes that can't be normalized?
I ask because our Mandate primitive is trying to be exactly that shared shape (capability scope tokens with expiry, principal-signed, agent-countersigned). If there's already an emergent commonality I'd like to align rather than invent a 6th model.
2. Cross-protocol budget tracking — why does everyone say "No"?
Your matrix shows cross-protocol budget tracking is "No" across all 5. Is this an inherent limitation (each protocol owns its own settlement state), a coordination failure (nobody's gotten around to it), or an active design choice (each protocol wants its principal to be ignorant of spend on other rails)? If a neutral primitive surfaced — "here's an attestable spend record this protocol emits, here's the verifier" — could the cross-protocol view emerge as a layer above?
3. Proof of execution as a separate axis
Your matrix tracks delegation and budgets very well. There's a related axis I don't see: what proof does the merchant/tool/provider emit that the action actually happened as the principal intended? This is distinct from "settlement happened" (your matrix covers that). For OM World we're specifying a per-step Execution Proof envelope (input_hash, output_hash, tool attestation, optional context_hash for stateful tools). I'm curious whether you've seen any of the 5 protocols surface a proof-of-execution primitive vs. treating settlement as implicit proof — and if you think it's a useful axis to add.
Happy to be wrong on any of these — your matrix is closer to the ground truth than our spec right now. Thanks for the neutrality, it's hard to find on this topic.