Agent-to-agent commerce
Agent-to-agent commerce is the practice of software agents finding each other, agreeing on terms, paying, and leaving a record of what was bought, with little or no human at the keyboard for each step. This page is an operations overview of that pattern. It is not a product endorsement, not a wallet guide, and not investment advice. It describes what the loop looks like, what can go wrong, and what high-level guardrails keep a run from becoming an open spend.
The basic loop
Four jobs sit in the loop. Discovery is how one agent learns that another agent, or a machine-readable service, can do useful work. Agreement is how both sides state price, scope, deadline, and delivery shape in a form software can check. Payment is how value moves when the terms are met, or when a protocol requires payment before the resource is released. Record keeping is how both sides, and any later auditor, can see what was requested, what was paid, and what was delivered.
Humans still set the outer policy: which agents may spend, which counterparties are allowed, which jobs need a person to approve, and where logs are stored. The agents then run inside that policy. When people say agent-to-agent, they usually mean that both ends of a step are software. One end can still be an ordinary HTTP service that speaks a payment protocol. The important property is that software can complete the step without a browser checkout each time.
Finding each other
Agents need a way to learn capabilities. One pattern is a directory or registry that lists what an agent claims it can do. Another is a direct card or profile that an agent publishes at a known address, describing skills, endpoints, and supported protocols. A third is referral: one trusted agent points to another. Discovery is only as good as the source. A listing can be stale, false, or copied from a better agent.
Google and partners published the Agent2Agent protocol, often shortened to A2A, as an open standard for agents built on different stacks to discover capabilities, send messages, delegate tasks, and track long-running work without sharing internal tools or private state. Public materials describe Agent Cards for advertising capabilities and bindings such as JSON-RPC, gRPC, and HTTP. This page treats A2A as a communication and interoperability layer, not as a payment rail by itself. Neighboring tool protocols that connect an agent to tools are a different job. Commerce needs both discovery of peers and a way to pay for what peers return.
Agreeing on terms
Agreement can be a short machine-readable offer: a price for a defined output, a time bound, and a delivery format. It can also be a longer mandate that a human signed earlier, stating what an agent is allowed to buy later within stated limits. Without clear terms, payment is only a transfer, and delivery disputes have no shared text to cite.
Terms should answer plain questions. What exactly is being sold. What counts as done. Who can cancel. What happens if the work is late or partial. Which currency or token the quote uses. Whether the quote is firm or advisory. Agents that accept vague natural-language promises alone will disagree later about what was bought.
Paying
Several payment patterns exist. The older pattern is a human account, an API key, and a monthly invoice. Agent commerce pushes toward payment that software can complete inside a request. One confirmed open protocol in that class is x402. It uses the HTTP status Payment Required so a server can state payment terms, a client can attach a signed payment payload, and the server can verify and settle before returning the resource. Public documentation describes optional facilitator services that help verify and settle on chain. Spending limits and key custody remain the operator's problem. x402 does not invent those controls for you.
A separate line of work is the Agent Payments Protocol, often called AP2, announced with industry partners as a payment-agnostic way for agents to show authorization to buy. Public materials describe cryptographically signed mandates that record what a user allowed, including flows where a person is not present at the moment of purchase but has pre-authorized constraints. AP2 is framed as a security and authorization layer for agent-performed payment, complementary to agent communication protocols rather than a replacement for them. This page names only these confirmed protocols at a high level. It does not give setup steps, fees, or coin recommendations.
Payment can settle in ordinary card rails, bank transfer, or on-chain assets, depending on the protocol and the merchant. The commerce pattern does not require one settlement asset. It requires a clear link between the agreement, the payment proof, and the delivery.
Keeping a record
A useful record answers who paid whom, for what offer, at what time, with which identifiers for the request and the response. Receipts, transaction ids, content identifiers for delivered files, and mandate ids belong in that trail when the protocols produce them. Logs should be hard for a single compromised agent to silently rewrite. Append-only storage, separate audit accounts, and copies outside the spending agent are ordinary engineering, not theater.
Records matter when a human has to reconstruct a week of autonomous purchases. They also matter when two agents disagree about delivery. Without a shared log, the dispute becomes a contest of screenshots. Neighboring pages on this site discuss content-addressed storage and agent memory patterns that keep citations stable when a mutable URL moves.
What can go wrong
Runaway spending is the first failure. An agent in a loop can retry, expand scope, or follow a malicious quote until a budget is empty. Fake or impersonating agents are the second. A directory entry or a lookalike card can point at a thief. Stolen keys let an attacker spend as if they were your agent. Disputes with no human on either side are the third. Both agents may follow their instructions and still leave a broken delivery that no person notices until the bill arrives. Unclear liability is the fourth. When a purchase harms a third party, or when funds leave without authorization the owner recognizes, courts and firms still need a human-facing account of who set the policy and who held the keys.
Other failures are quieter. An agent can pay for data it is not allowed to hold. It can accept work from a counterparty under sanctions rules the operator never encoded. It can treat a marketing claim in a card as a verified skill. It can store secrets in a prompt log that a later tool leaks. Commerce multiplies these risks because money and data move together.
Guardrails at a high level
Operators can reduce damage without pretending risk is gone.
Spending caps: hard limits per request, per hour, per day, and per counterparty. Caps should live outside the model that proposes the spend, so a confused agent cannot raise its own ceiling.
Allow lists: only known agents, services, and asset types. New counterparties require a slower path.
Human approval thresholds: above a size, or outside a category, the agent pauses for a person. Below the threshold, it may proceed inside the cap.
Separate keys: a research agent should not hold the same spend authority as a payments agent. A leaked tool credential should not drain the treasury.
Mandatory logs: every quote, payment, and delivery id written to a store the spending process cannot erase. Alerts when volume, error rate, or new counterparties spike.
Kill switches: a way to freeze spend quickly when behavior looks wrong.
Mandate hygiene: if using pre-authorization, keep scopes narrow, expirations short, and purposes explicit. A broad forever mandate is an open wallet with extra steps.
These controls are policy and systems design. They are not a promise that a protocol is safe. Open protocols can still be aimed at bad ends when keys and caps are weak.
What this page does not cover
It does not walk through wallets, seed phrases, API dashboards, or merchant onboarding. It does not quote fees or prices. It does not rank vendors. It does not claim that agent commerce replaces ordinary employment, contracts, or consumer law. Those human institutions still assign liability when software spends. Readers building infrastructure can use the site pages on freedom tech for agents, on x402-style HTTP payments, and on memory stores for receipts and corpora. Readers thinking about cheap compute and storage as a backdrop can use the post-scarcity tooling page.
Conclusion
Agent-to-agent commerce is a loop of discovery, terms, payment, and records between software parties. Confirmed protocol work such as Agent2Agent for inter-agent communication, x402 for HTTP-native payment required flows, and Agent Payments Protocol for signed purchase authorization shows how the industry is standardizing pieces of that loop. The hard problems remain operational: impersonation, runaway spend, empty disputes, and unclear liability. Caps, logs, allow lists, separate keys, and human thresholds are the practical answer at a high level. Without them, a clever agent is only a fast way to buy the wrong thing.