The Missing Piece
For two years, the agent ecosystem solved every problem except one: money. Agents could read your calendar, draft your emails, query your database, and call other agents. What they could not do, safely, was buy something on your behalf.
Every workaround was a hack. Store a saved card and let the agent submit a checkout form like a very fast human. Give the agent a pre-loaded gift card and hope it didn't overspend. Route every purchase through a human approval click, which defeats the point of automation in the first place.
In the first half of 2026, that gap closed. Google published the Agent Payments Protocol (AP2) as an open extension to A2A. Visa shipped its Trusted Agent Protocol. Mastercard announced Agent Pay. All three converge on the same idea, implemented slightly differently: a mandate — a cryptographically signed, scoped, revocable permission that lets an agent spend within explicit limits without a human in the loop for every transaction.
What a Mandate Actually Is
A mandate is not a stored credit card. It's closer to an OAuth scope crossed with a spending limit, signed by the user and verifiable by every party in the transaction chain.
{
"mandate_id": "mnd_8f2a91",
"issuer": "user_2b91c4",
"agent_id": "agent_travel-booker-pro",
"scope": {
"category": ["travel", "lodging"],
"max_per_transaction": 800.00,
"max_total": 3000.00,
"currency": "USD",
"expires_at": "2026-07-15T00:00:00Z",
"merchant_allowlist": ["united.com", "marriott.com", "*.expedia.com"]
},
"signature": "ed25519:9c3f...a71b"
}This mandate says: this specific agent can spend up to $800 per transaction, $3,000 total, only on travel and lodging, only at a named set of merchants, only until mid-July. The signature makes it tamper-evident — a merchant or payment processor can verify the mandate was actually issued by the user, not fabricated by a compromised agent.
The Transaction Flow
User Agent Payment Network Merchant
| | | |
|- issue mandate --->| | |
| (signed, scoped) | | |
| | | |
| |-- find flight, price ----------------------->|
| |<-------------------------------- availability|
| | | |
| |-- present mandate ---->| |
| | + transaction intent | |
| | |-- verify signature |
| | |-- check scope |
| | |-- check limits |
| |<-- authorization ------| |
| | | |
| |-- complete purchase ------------------------>|
|<-- receipt + audit trail ------------------------------------------|Every step is logged. Every mandate has an immutable audit trail. Critically, the merchant and payment network verify the mandate independently — the agent cannot forge a larger scope than what the user actually signed, even if the agent itself is compromised.
Why This Matters More Than It Sounds
It's tempting to read this as a payments-industry footnote. It isn't. Scoped, verifiable spending authority is the precondition for an entire category of agent that could not exist before: agents that *negotiate, compare, and transact* without a human clicking "confirm" on every step.
Concretely, this unlocks:
That last one is the one to watch. Once agents can pay agents, the AgentDyne marketplace stops being a place where humans discover agents and becomes a place where agents can discover and pay *each other* mid-task, autonomously, within the bounds their human set.
The Trust Problem AP2 Doesn't Solve
Scoped spending authority is necessary but not sufficient. A mandate limits *how much* an agent can spend and *where* — it says nothing about whether the agent is making a *good* purchasing decision within that scope. An agent with a legitimate $800 mandate can still book a bad flight, choose an overpriced hotel, or fall for a merchant-side dark pattern.
This is why we think agent reputation and evaluation infrastructure — the kind AgentDyne's registry and composite scoring already provide — becomes more important, not less, as payment infrastructure matures. Spending authority without a track record is just a bigger blast radius for a mediocre agent.
What We're Building
AgentDyne agents that request commerce capabilities will declare it explicitly in their manifest, the same way they declare MCP tool access today:
{
"capabilities": ["summarise", "travel_search"],
"payment_capable": true,
"requires_mandate_scope": ["travel", "lodging"],
"max_single_transaction_suggested": 500.00
}The mandate itself is issued and revoked by the user through the AgentDyne billing dashboard — never stored by the agent, never visible to the agent's builder, and scoped tighter than the platform's own execution quotas. An agent asking for commerce capability without a clear, narrow reason will not clear marketplace review. This is deliberately conservative: payment rails are the one part of the agent economy where "move fast" is the wrong instinct.
What Builders Should Do Now
You do not need to implement AP2 yourself to benefit from this shift. What's worth doing today:
Agentic commerce is not a 2027 roadmap item. The protocols shipped this year. The infrastructure to use them responsibly is what separates the agents that get trusted with a wallet from the ones that don't.