Agent-to-Agent Commerce: When Your Agent Buys From Their Agent
June 11, 2026 · Victor Young
The logical endpoint of agentic commerce isn't a human buyer using an AI assistant to shop. It's a buyer's agent negotiating directly with a seller's agent — two automated systems transacting with each other, with humans setting the parameters and reviewing the results. This is already technically possible in limited contexts, and the infrastructure required to make it broadly workable is being built now.
What Agent-to-Agent Commerce Looks Like
Start with a concrete example. A buyer's agent is tasked: "Reorder our monthly office supplies — same specs as last time, keep total under $200, flag anything that's increased in price by more than 10%." The agent queries a structured product catalog, finds matching items, checks prices against the previous order, and — if nothing triggers the price alert — submits purchase executions without asking the human to review each item.
On the other side, the seller's agent receives the order. It checks current inventory, confirms shipping availability for the buyer's address, and accepts or declines the order. If the item is backordered, it might send a counter-offer: "Item A is out of stock; Item B is equivalent and in stock at the same price."
Neither a human buyer nor a human seller needs to be in the loop for routine reorders that stay within established parameters. Humans set the parameters, review exceptions, and approve anything outside the norm. The agents handle execution.
This pattern isn't science fiction. The missing pieces are: a shared protocol both agents can use, a machine-readable product catalog the buyer agent can query, a programmatic trust layer (escrow, proof of action, audit trail), and human oversight at the money boundary.
Shared Protocols: Skill Files and Machine-Readable Surfaces
For two agents to transact, they need a shared language for capability declaration, product description, and order negotiation. This is where emerging conventions like SKILL.md and SELL.md matter.
A SKILL.md file is a plain-text or structured document that describes what an agent-accessible service can do — its available operations, required parameters, and expected outputs. It's readable by both humans and LLMs. A buyer agent can fetch a SKILL.md, understand what operations the service supports, and use that to form correct API calls.
Firestarter's /SKILL.md describes the buyer-side operations: how to submit a purchase intent, how to check execution status, how to approve or cancel, how to send a message to the execution. Firestarter's /SELL.md describes the seller-side operations: how to register a seller account, list products, manage orders.
The point of publishing both is that either side can be automated. A buyer can point their agent at /SKILL.md and it will know how to buy. A seller can point their agent at /SELL.md and it will know how to sell. Neither agent needs a human to mediate the protocol.
Alongside these skill files, Firestarter publishes:
/llms.txt— natural-language description of what the network does, for LLM context- OpenAPI 3.1 spec at
https://api.firestarter.network/.well-known/openapi.json— for agent frameworks that prefer formal API specs - An MCP server with five tools for Claude-compatible agents
Sellers who want their products discoverable by buyer agents need their catalogs in a structured, queryable form. This is distinct from a website — it's a machine-readable product feed with accurate attributes, pricing, and availability. Connecting a store to Firestarter (Shopify, WooCommerce, BigCommerce, Wix, or Squarespace auto-detected in about 30 seconds) creates exactly this: a live, queryable catalog that buyer agents can search. See the seller guide for details.
Programmatic Trust: Escrow, Proof of Action, and Audit Trails
The hardest problem in agent-to-agent commerce isn't protocol — it's trust. When a buyer agent and a seller agent transact without human involvement, what guarantees that the buyer pays and the seller ships?
The answer isn't agent reputation or AI-to-AI negotiation. It's the same infrastructure that makes any remote commerce trustworthy: escrow, proof of action, and audit trails. These are human institutions, not AI constructs.
Escrow. Payment is held by a neutral third party until the delivery condition is met. The seller's agent knows payment is secured before shipping; the buyer's agent knows funds won't release until delivery is confirmed. Firestarter holds payment in Stripe escrow from order creation until delivery confirmation. Neither agent has to trust the other's promise to pay or ship — they both trust the escrow mechanism.
Proof of action. Every execution produces a verifiable record: the order confirmation from the seller, the EasyPost shipping label and tracking number, and the delivery confirmation from the carrier. These artifacts are stored in the execution record and accessible via GET /v1/executions/:id. A buyer agent that surfaces these to a human isn't just saying "I bought the thing" — it's showing receipts.
Audit trail. Every operation against an execution — creation, approval, payment, status updates, exceptions — is logged in the execution record with timestamps. This is the audit trail that makes agent-to-agent commerce acceptable to procurement and legal teams. The question "what did the agent actually do?" has a documented answer.
Without these three elements, agent-to-agent commerce is a promise. With them, it's accountable infrastructure.
Human Oversight at the Money Boundary
Full autonomy in commerce — agents transacting without any human review — is technically achievable today for buyers and sellers with compatible systems. It's also probably not what most buyers want, at least not without a careful trust-building period.
The practical pattern that works is: agents handle research, comparison, and routine reorders automatically; humans review and approve anything at the money boundary, or anything outside established parameters.
Firestarter implements this as a configurable approval checkpoint. By default, every execution pauses before payment and presents the proposed order for human review. The buyer can approve, reject, or request changes. Within defined parameters — specific product categories, spend limits per execution, pre-approved sellers — buyers can configure executions to proceed automatically.
This is not a limitation on agent capability. It's the control structure that makes it safe to give an agent real spending power. An agent that can spend $10,000 on office supplies autonomously is useful. An agent that can spend $10,000 on office supplies with no audit trail and no approval gate is a liability.
The docs cover how to configure approval checkpoints and per-execution spend limits. The explainer covers the full execution lifecycle.
The Two-Sided Network
Agent-to-agent commerce requires both sides to be agent-capable. A buyer's agent with purchasing capability is useless if sellers don't have machine-readable catalogs and a programmatic order API. A seller's agent that manages inventory and processes orders is useless if there are no buyer agents to transact with.
Firestarter is designed as a two-sided network where both sides are agent-native. Buyer agents query the product catalog, submit purchase intents, and receive structured execution results. Seller agents — or sellers using the seller API directly — list products, receive orders programmatically, and confirm fulfillment via the seller API.
The seller's agent path, via /SELL.md, means a seller can fully automate their side of the transaction: product listing, order acknowledgment, inventory updates, and fulfillment confirmation — all without a human logging into a dashboard. Combined with a buyer's agent on the other side, the entire transaction from "we need to reorder" to "delivery confirmed" can run without manual steps at either end, with humans involved only at the review and exception points.
This is the two-sided future: not humans using AI assistants to shop, but agents transacting with agents within parameters that humans set and audit trails that humans can inspect.
For sellers interested in getting their agent stack set up on the seller side, the seller documentation covers the API in detail. For buyers building agent purchasing workflows, the developer docs and scenarios page are the starting points. For the broader context on what this category is, see what agentic commerce means.
Founding sellers get 0% commission for 12 months and priority placement in agent matching. Spots are capped at 10 per category. Standard pricing: sellers list free and pay a 3% commission on completed sales only. Buyers pay no transaction fees.
FAQ
Does agent-to-agent commerce require both sides to use Firestarter?
Yes, for transactions that run through Firestarter's network. The buyer's agent uses the Firestarter buyer API (or MCP server); the seller's inventory is listed in the Firestarter catalog. The point of a two-sided network is that both sides operate through shared infrastructure, which is what makes the escrow, audit trail, and proof of action possible.
What prevents a seller's agent from accepting an order it can't fulfill?
The execution lifecycle includes an inventory confirmation step before payment escrow is finalized. If a seller's system can't confirm availability, the execution moves to an exception state rather than proceeding to payment. The seller API's order management endpoints (GET /seller/orders) allow a seller's agent to respond to orders programmatically, including declining if the item is unavailable.
How does the approval checkpoint work when both agents are automated?
The approval checkpoint is on the buyer side. When it's enabled, the buyer's agent surfaces the proposed order to a human buyer for review before payment. If the buyer has configured the agent to proceed automatically within certain parameters, the checkpoint is bypassed for orders that fit those parameters. The seller's agent is not involved in the approval step — it sees the order only after the buyer has approved.
Can a seller's agent negotiate price with a buyer's agent?
Not in the current implementation. Firestarter's execution model is: buyer agent submits purchase intent, Firestarter matches against the seller catalog at listed prices, buyer agent approves or declines. Dynamic negotiation between agents is a future capability, not a current one.
What does "per-execution spend limit" mean in practice?
A spend limit is a cap set by the buyer on the maximum amount a single execution can charge. If the matched order total exceeds the limit, the execution pauses for explicit approval regardless of other checkpoint settings. This is configured per execution and is enforced before payment is released from escrow. See the developer docs for how to set spend limits in the API request.