Letting software decide is only one part of the system. Identity, payment instructions, settlement and controls still have to hold together.
An AI agent can decide that a payment should happen. That does not mean the payment system around it is ready.
Money still needs an authorized source, a machine-readable instruction, a settlement asset and a reliable record of what happened. If any one of those layers is missing, the impressive part of the demo can hide the fragile part of the system.
That is why the most useful way to evaluate agentic payments is not to ask, “How smart is the agent?” Start with four more basic questions.
1. Who gave the agent authority?
An agent needs a defined permission boundary before it can move money.
That boundary should answer:
which account or wallet the agent may usewhich recipients or services are allowedhow much it may spend per action and over timewhich currencies or networks are in scopewhen a human review is requiredhow access can be suspended or revoked
A prompt is not a permission model. “Pay this invoice” describes an intended outcome. It does not establish who is authorized to use the funds, whether the recipient is legitimate or whether the amount falls inside policy.
Good systems separate the agent’s reasoning from the authority granted to it. The agent can propose or initiate an action, while deterministic policy checks decide whether that action is allowed.
2. How does the agent discover and describe the payment?
The agent needs a reliable way to learn what a service accepts, what it costs and how to call it.
This is partly a discovery problem and partly an interface problem. Machine-readable service descriptions can tell an agent which endpoint exists, which input it expects and which payment method unlocks it.
Coinbase’s x402 Bazaar MCP server is one current example. Its documentation describes tools that let agents find paid x402 resources and call them while handling the payment flow. That is useful infrastructure, but it is still one layer. Discovery does not prove that the underlying asset, recipient or settlement process is appropriate for a particular user.
Before trusting a discovery layer, check whether it exposes:
the real service ownerthe exact price and denominationthe network and settlement methodthe resource the payment unlocksan unambiguous result when payment fails
An agent should not have to guess what it is buying.
3. What actually settles?
The payment needs an asset and a rail.
That could involve commercial bank money, a regulated stablecoin or another supported settlement asset. These are not interchangeable merely because each can appear as a digital balance.
The Monetary Authority of Singapore’s BLOOM initiative is useful here because it treats settlement as infrastructure, not interface polish. BLOOM covers tokenized commercial bank money and regulated stablecoins while focusing on interoperability, cross-jurisdiction acceptance and programmable controls. Its stated use cases include agentic payments.
For any system, ask:
who issues the settlement assetwhat legal or contractual claim the holder hashow redemption workswhich network records the transferwhen the payment becomes finalwhat happens if the network, issuer or recipient is unavailable
The agent may be the component that requests the payment. It is not the asset, the issuer or the settlement network.
4. How is the payment controlled and reconciled?
The final layer is what makes the process operable after the demo ends.
A production system needs to prevent duplicate payments, record the result, connect it to the original instruction and make failures visible. It should also provide enough information for a person or another system to reconstruct what happened.
The minimum checklist includes:
a unique payment or request identifieran idempotency rule that prevents accidental repeatsa clear status such as proposed, authorized, submitted, settled or faileda receipt tied to the service that was purchasedlimits that are enforced outside the language modelan audit record that can be reviewed later
This is where programmable controls matter. MAS describes agents operating within predefined limits and conditions, with safeguards around the transaction. The important phrase is “predefined.” The control cannot depend only on the agent remembering a sentence from an earlier prompt.
A four-question test for any agentic-payment claim
When you see a new product or protocol, run this short test:
Authority: What is the agent explicitly allowed to do?Discovery: How does it know the recipient, price and service are real?Settlement: Which asset and network complete the payment?Control: How are limits, duplicates, failures and records handled?
If the answer to one layer is vague, the system may still be an interesting prototype. It is not yet a complete payment workflow.
Agentic payments will become useful when these layers become boring, inspectable and dependable. The intelligence of the agent matters. The infrastructure around it matters just as much.
Use the four-layer checklist when evaluating an agentic-payment system
Sources
Monetary Authority of Singapore: BLOOMMAS: Building Trusted Foundations for Digital FinanceCoinbase Developer Platform: x402 Bazaar MCP server
Educational infrastructure analysis only. This article does not recommend a payment asset, service or financial action.
Agentic Payments Need More Than an Agent: Four Layers That Must Work was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.