What Is Agent-to-Agent Commerce? How It Works, With Examples

Agent-to-agent commerce is a commercial exchange in which software agents represent both sides of a purchase or sale. A buying agent might request a service, compare an offer, or place an order with a selling agent acting for another operator. People set the goals and authority; agents handle some or all of the exchange.

Imagine your operations agent arranging a translation for tomorrow's product launch. It sends the brief to a translation provider's agent, receives a quote, and asks for approval before placing the order. The provider's agent schedules the work and returns the finished files.

The retailer gets its order arranged without copying the brief between chats and checkout screens. People can still approve the expense and review the translation.

What makes the exchange agent-to-agent?

The defining feature is representation on both sides. The buyer's agent works toward the buyer's goal. The seller's agent handles requests within the seller's rules, such as the services it can offer, prices it can quote, or delivery dates it can accept.

It helps to separate three situations:

• A person shops with an AI assistant. The assistant recommends a product, but the person completes the purchase. AI helped with shopping; another agent may never have participated.
• An agent buys from an ordinary service. It pays for an API result or submits an order through a merchant's checkout API. This is agent-led commerce, even if the seller uses conventional software.
• Agents represent buyer and seller. They exchange requirements and offers, arrange the transaction, or coordinate the purchased work. This is the agent-to-agent case discussed here.

These are useful working distinctions, not a universal certification scheme. A service accepting machine payments does not establish that an AI agent operates the selling side.

A translation order, from brief to delivery

Consider this fictional example. A small retailer needs five product descriptions translated into Thai. Its operations agent can collect quotes, but a person must approve the purchase.

The buying agent contacts a provider whose agent handles translation requests. It supplies the source copy, target language, required format, and deadline. The selling agent asks whether product names should remain in English, then returns a fixed-price offer.

The retailer approves those terms. The buying agent submits the order through the provider's supported interface, and the payment system processes the authorized charge. The provider might use people, models, or both to produce the translation. Its selling agent does not have to perform every part of the work itself.

When the files arrive, the buying agent checks that all five descriptions are present and returns them for review. The retailer still needs to assess translation quality before publication.

The useful outcome is a completed order with fewer manual handoffs. Finding a provider, receiving a quote, paying, and accepting the work are still separate events. Our guide to payment receipts and delivery evidence explains how to keep them connected.

Has agent-to-agent commerce happened outside a demo?

Anthropic's Project Deal experiment provides a concrete example. Agents represented 69 employees in a private marketplace, negotiating purchases and sales of real belongings. In the run used for actual exchanges, they agreed 186 deals worth just over $4,000.

Participants exchanged the physical goods afterward, and the experiment handled payouts. The result demonstrates agent negotiation on behalf of people. It does not establish that agents independently handled every payment and delivery step, or that the same results would hold in an open marketplace.

Does it require A2A, AP2, MPP, or x402?

There is no single required protocol bundle for agent-to-agent commerce. Choose interfaces that the participating systems can actually use.

The Agent2Agent protocol, A2A, supports communication and collaboration between agents. Commerce is one possible use. Agents can also collaborate without buying anything, and a commercial exchange can use other interfaces.

x402 supports programmatic payment for HTTP resources. MPP, the Machine Payments Protocol, lets compatible agents pay for web services. Neither requires the seller to be an AI agent.

AP2 supplies an authorization framework with checkout and payment mandates for participating systems to verify. It supports flows with a person approving the transaction and flows using authority delegated beforehand.

Our x402, AP2, and MPP comparison covers implementation choices. Being able to send a request, having permission to buy, and successfully paying for the order are separate questions.

Where Headless Domains helps the relationship continue

Suppose the retailer wants to use the translation provider again. The provider now has a different API host and appears in another directory. A maintained public name gives the buyer a consistent reference for finding its current service information.

Headless Domains gives an agent that name. Its public records can connect operator information, service endpoints, machine-readable manifests, and supporting links. Compatible clients can inspect those records through HTTPS APIs; your agent's runtime and existing website can stay where they are. Our manifest documentation describes the published records.

A .agent name can identify the agent representing the provider. A .bpo name may suit a business process sold as a service. The name helps customers recognize what they are returning to, while the operator maintains the registration and updates its records.

The commerce integration still verifies credentials, purchase authority, and payment details. Registering a name does not connect those systems automatically. It supplies a public reference they can use alongside verified internal identities. The Agent Identity Stack explains that broader architecture.

Common questions

Do both agents have to be fully autonomous?

No. One might only collect offers while another can issue quotes. A person can approve the purchase or review the result. Explain which steps the agents handle rather than treating autonomy as an all-or-nothing label.

Do agents have to negotiate the price?

No. A seller can offer a fixed price. The agents may instead clarify the task, select an available service, or coordinate delivery.

Does it require cryptocurrency or a new domain extension?

No. Payment depends on the systems the parties support, and conventional domains can host agent-facing services. A Headless Domains name is useful when an agent needs a maintained public identity across those services.

How much authority should a buying agent have?

Start with the specific work you want it to arrange. Decide which purchases it may complete and which need approval, then enforce those limits in the responsible systems. Our agent commerce trust guide helps you make that decision.

Give the agent doing the work a name

Choose one existing agent that buys a service or represents something you sell. Describe its job, identify its operator, and connect its public name to the service information customers need.

To get started, give your agent the Headless Domains skill file and ask it to explain the naming options and registration cost before taking action. Ask for approval before payment. Build around the useful work your agent already does.