Agent-to-agent commerce: when your AI asks another AI to buy for you

Many people already use a general-purpose AI assistant for planning, writing and research. Sooner or later, those assistants will want to do things that involve buying: order the replacement part they diagnosed, pick up the gift they suggested, restock the supplies on the list.

A general assistant is not necessarily the best place to handle checkout, payments, delivery tracking and returns. A specialist shopping agent is. That is where agent-to-agent commerce comes in: one AI asks another to carry out a task, and the specialist does the work it is built for.

This article explains how that works with Ottr, the three ways an agent can connect, and the rule that never changes: agents can prepare a purchase, but only the customer can approve it.

Why agents need to talk to agents

There are good reasons for a general assistant to delegate shopping rather than attempt it directly.

• Payments are specialised. Card handling, funding, refunds and reconciliation need dedicated infrastructure and controls.
• Safety needs a fixed boundary. If every assistant built its own checkout, each would need its own approvals, card controls and audit trail. Concentrating that in one place makes it easier to get right.
• Customers keep one place to approve. Whichever assistant started the task, the approval request arrives in the same familiar place, with the same protections.

Ottr's own assistant uses the same purchasing functions that are exposed to other agents. There is no special back door for us and no weaker path for anyone else.

Three ways to connect

Different agent frameworks speak different protocols, so Ottr offers three.

REST: the Agent Commerce API

A conventional HTTPS API for developers who want direct control. An agent can search for products, create a purchase intent, request the customer's approval, execute the purchase once it is approved, check an order and start a return. Creating a purchase intent charges nothing. Attempting to execute a purchase before the customer has approved it returns a clear "approval required" response.

MCP: the Model Context Protocol

MCP is an open protocol that lets AI applications discover and call tools in a standard way. Ottr runs an MCP server with tools for searching and comparing products, creating a purchase intent, requesting approval, executing an approved purchase and checking order status. Any MCP-capable client can use them without custom integration code.

A2A: Agent2Agent

A2A is an open protocol for agents to discover one another and exchange tasks. Rather than calling individual tools, an agent sends Ottr a task, such as finding and preparing a particular purchase, and can follow it as it progresses, including the point at which it is waiting for the customer. The task always reflects the real state of the purchase.

Whichever route an agent takes, the same rules, scopes and approval flow apply. Technical details are on our developer documentation, and you can watch the flow run end to end on the page for AI agents.

How permission works

Two separate permissions are needed before an agent can act for a customer.

1. The agent is registered with OTTR

An OTTR administrator creates an integration for the agent and issues it an API key, which is shown once. The integration is limited to a set of scopes, such as searching, creating purchase intents, requesting approvals and reading orders.

2. The customer authorises that specific agent

The customer chooses to authorise the agent from the security page of their OTTR account. This produces a customer reference that:

• is valid only for that one agent
• carries only the scopes the customer granted
• expires, after 90 days by default
• can be revoked at any time, taking effect immediately

An agent without both its own key and a valid customer reference cannot do anything on the customer's behalf. If the customer revokes access, the agent is told plainly that permission has been withdrawn.

What an agent can never do

The boundaries here are enforced in the platform, not left to the good behaviour of the calling agent.

1. No agent can approve a purchase. Approval happens only on OTTR's secure approval page, in the customer's own signed-in session, bound to the exact item, price, retailer and address. We explain the reasoning in Why a 'yes' in a chat should never be enough.
2. No agent can approve, pay or mint a card. The code that serves agents has no route to card issuing and no way to approve a purchase or take a payment on its own; money only moves after the customer approves. Automated tests check that this stays true.
3. No agent sees card details. Purchases are paid with single-use virtual cards that never pass through an agent.

When an agent requests approval, the link is also sent to the customer's own channel, such as their web chat or Telegram, so the customer sees the request in a place they already trust, not only in the third-party agent's interface.

A worked example

Imagine a home-improvement assistant that has helped you plan a small bathroom repair.

1. It works out that you need a specific replacement cartridge for your tap.
2. With your earlier permission, it asks Ottr to search for compatible cartridges, then creates a purchase intent for the best match.
3. It requests approval. You receive the request from Ottr, open the secure page, check the part, price and delivery address, and approve.
4. The assistant asks Ottr to execute the purchase. Ottr funds it, issues a single-use card and completes the checkout.
5. The assistant can check the order status and tell you when the part is due to arrive.

The assistant did the thinking. Ottr did the buying. You made the decision.

What is not here yet

Two things are deliberately absent for now.

• Standing mandates. The idea that you might pre-authorise certain purchases, for example "reorder this when it runs out, up to a set amount", is modelled in our design but switched off. We will only enable it with clear limits, clear consent and the regulatory groundwork in place.
• Live payments. OTTR is in development. The Agent Commerce API, MCP server and A2A endpoint run against a sandbox test merchant, with sandbox funding and card issuing. No real money moves.

The takeaway

Agent-to-agent commerce lets each AI do what it is best at: your general assistant understands the task, and a specialist shopping agent handles the purchase. The protocols, whether REST, MCP or A2A, are simply ways of asking. What makes it safe is constant across all of them: scoped, revocable permission that the customer controls, and a final approval that only the customer can give.

If you build agents, start on the AI agents page. If you are a shopper, you can try Ottr directly, and the broader picture is in What is an AI shopping agent?.