Agent commerce is often described as a payment problem. An AI agent finds a service, receives a price, pays, and receives the result. That description is useful, but it hides the architecture that makes the transaction safe enough to repeat.
A workable stack for agent commerce needs at least four layers: wallet, identity, payment, and settlement. Each layer answers a different question. The wallet asks what the agent can do. Identity asks who the agent or service is. Payment asks whether value should move for this request. Settlement asks what actually happened after value moved.
When these layers blur together, agent commerce becomes fragile. A wallet with no policy becomes a risk. Identity with no payment binding becomes decoration. Payment with no settlement record becomes hard to support. Settlement with no delivery state becomes accounting without trust.
The useful design principle is simple: keep the layers separate, then bind them at the transaction.
Layer 1: Wallet as the Execution Surface
The wallet is where the agent's financial capability becomes real. It may be a custodial wallet, embedded wallet, smart account, delegated account, prepaid balance, internal credit account, or payment account connected to card or stablecoin rails.
The wallet should not be treated as a blank spending key. In agent commerce, the wallet is an execution surface with constraints.
A production wallet layer should answer:
Which assets can the agent use?
What maximum amount can it spend?
Which destinations are allowed?
Which actions require confirmation?
Which keys or credentials can sign?
How are approvals revoked?
What happens if the agent loops or retries?
This layer is where many teams first underestimate risk. They focus on whether an agent can pay, not whether it can only pay within a defined policy. Autonomous execution without spending limits is not a product feature; it is an operational failure waiting to happen.
The wallet layer should make capability narrow, inspectable, and reversible where possible.
Layer 2: Identity Makes Agents Legible
Identity gives the transaction a subject. It tells the system which agent, service, wallet, merchant, operator, or organization is involved.
In human commerce, identity can be distributed across accounts, cards, device fingerprints, merchant records, and user sessions. In agent commerce, identity needs to be more explicit because software may act across many services without a human checking every step.
An identity layer may include:
agent identifier
service namespace
wallet address or payment account
signing key
operator metadata
allowed action scope
reputation references
revocation status
Identity does not prove that a counterparty is trustworthy. It makes the counterparty evaluable. Without identity, the payment layer only sees an amount and destination. With identity, the agent can check whether the recipient is known, allowed, reputable, and relevant to the task.
Identity should also be bound to context. An agent authorized to buy one data snapshot should not silently become authorized to buy unrelated services from the same counterparty.
Layer 3: Payment as the Authorization Moment
The payment layer is where a request becomes a value transfer decision.
For agent commerce, payment is not only the movement of funds. It is the moment when a price, resource, recipient, asset, policy, and user intent are evaluated together.
A payment request should tell the agent:
what resource is being sold
how much it costs
which asset or rail is accepted
who receives payment
when the quote expires
what proof is required
what delivery condition follows payment
what refund or recovery path exists
HTTP-native flows such as x402 are relevant here because they let a service return a machine-readable payment requirement at the request layer. That can work well for paid APIs, content, data, tools, and other digital services. But payment still needs wallet controls, identity checks, and settlement records around it.
The payment layer should not approve a transaction just because the agent can afford it. It should approve only when the request matches policy and intent.
Layer 4: Settlement Proves What Happened
Settlement is where the system records whether value moved and what state follows.
In simple payment systems, settlement may be treated as the end of the process. In agent commerce, it is only part of the outcome. A transaction is not complete until the paid resource is delivered, the service state is updated, and any failure path is recorded.
Settlement should answer:
Was payment submitted?
Was payment confirmed?
Which rail or ledger recorded it?
Was the requested service delivered?
Was the result accepted by the agent?
Did the service fail after payment?
Is a refund, credit, cancellation, or retry needed?
The hardest state is paid but not delivered. If the settlement layer says payment succeeded but the service never returns the API response, generated file, data record, or tool output, the buyer sees a broken transaction. The system needs a recovery state, not just a transaction hash or receipt.
Settlement is therefore both financial and operational. It connects money movement to service delivery.
Why the Four Layers Should Not Collapse
It is tempting to combine layers for speed. A wallet provider may offer identity. A payment protocol may imply settlement. A marketplace may bundle reputation. A service provider may hide everything behind one API.
Bundling can improve developer experience, but the architecture still needs separate responsibilities.
If wallet and payment collapse, a policy error can become a direct loss of funds. If identity and reputation collapse, a familiar name may hide poor task-specific performance. If payment and settlement collapse, a successful charge may be confused with a successful delivery. If settlement and reputation collapse, a temporary failure may permanently damage trust without context.
The layers should be composable, but not conceptually identical.
How the Layers Work in One Agent Purchase
Consider an agent buying a market data snapshot from another agent-operated service.
First, the wallet layer checks whether the agent has funds or credits and whether this class of purchase is allowed. Second, the identity layer checks whether the data service is a known counterparty with a recognizable service identity. Third, the payment layer evaluates the quote: price, asset, recipient, expiration, and requested resource. Fourth, the settlement layer records payment confirmation and whether the data snapshot was delivered.
If the data service times out after payment, settlement does not simply mark success. It records paid but not delivered, then triggers retry, credit, refund, or support review according to the service rules.
This is the difference between a demo and a system that can support real users.
Reputation Runs Across the Stack
Reputation is not one of the four layers, but it depends on all four.
Wallet history can show whether an agent respects spending limits. Identity history can show whether a service is stable and recognizable. Payment history can show whether quotes match outcomes. Settlement history can show whether paid services are delivered and disputes are resolved.
Good reputation is built from events across the stack:
policy approvals and blocks
successful payments
failed payments
delivery success
paid-but-not-delivered cases
refunds and credits
counterparty feedback
repeated task performance
This is why reputation should be task-specific. A service that delivers fast content summaries may not be reputable for compliance checks. A low-value payment history may not justify high-value automation. The stack needs enough context to make that distinction.
Infrastructure Around the Four Layers
GOAT Network is relevant to this architecture because its agent-oriented stack includes AgentKit developer tooling, x402 payments, and ERC-8004 identity and reputation concepts. Those map naturally to the four-layer view: controlled wallet actions, identifiable agents and services, machine-readable payment requirements, and settlement or execution records.
This does not make x402 exclusive to GOAT, and ERC-8004 should not be described as a token standard. Developers should verify current SDK support, supported assets, production availability, and implementation details before building a live product.
The broader lesson is portable: agent commerce needs execution, identity, payment, and settlement to work as one system without becoming one unbounded permission.
Build Order for Developers
The safest build order is not to start with every rail, every marketplace, and every agent identity system.
Start with one controlled wallet action. Add one identity model for the agent and the paid service. Add one payment flow with a clear quote and policy check. Add one settlement record that proves payment and delivery state. Then test failed payment, expired quote, policy rejection, duplicate request, paid-but-not-delivered, and refund or credit handling.
Only after that works should the system add more services, dynamic pricing, broader discovery, multi-agent negotiation, or automated reordering.
The first version should prove that the four layers can bind one transaction correctly.
FAQ
What is the stack for agent commerce?
The stack for agent commerce is the infrastructure that lets agents hold or access value, identify counterparties, authorize payment, and record settlement or delivery outcomes. A practical minimum is wallet, identity, payment, and settlement.
Why does agent commerce need identity?
Identity lets the paying agent understand who is requesting payment, which service is involved, and whether the counterparty matches policy. Without identity, a payment request is difficult to evaluate safely.
Is payment the same as settlement?
No. Payment is the authorization or movement of value. Settlement is the confirmed state after value moves, and in agent commerce it should also connect to service delivery, retry, refund, or recovery state.
Where does reputation fit in the stack?
Reputation is derived from events across the stack. It may use identity history, payment history, delivery outcomes, disputes, refunds, and task-specific performance to help agents decide whether to transact again.
The Four-Layer Test
A stack for agent commerce is ready only when it can answer four questions for every transaction.
What is the agent allowed to do? That is the wallet layer.
Who is the agent or counterparty? That is the identity layer.
Should this request be paid? That is the payment layer.
What happened after value moved? That is the settlement layer.
If any answer is missing, the stack may still process a payment, but it cannot reliably support agent commerce. For teams building controlled agent execution, machine-readable payment flows, identity-aware services, and settlement records, the next step is simple: Explore AgentKit.
