usbfork
AI & Automation 9 min read

Agent-to-Agent Commerce: When Your Stock System Buys From Your Supplier

Here's a scenario a client put to us recently. A dental clinic runs a stock control system. Composite resin drops below the reorder point. Instead of a nurse noticing three days later and phoning around, an AI agent notices immediately — checks availability and pricing with three local suppliers, compares lead times and freight, picks the best option, places the order and pays for it.

On the other side, the supplier's own agent does the mirror image: reads its inventory, quotes a price and an ETA, validates the payment authorisation, and books the delivery. Two machines transacting, no humans in the middle.

The question was simple: does a protocol for this actually exist? The answer is yes — several, in layers — but the honest version is more useful than the hype, especially if you run a business in Perth and want to know what you can build this quarter rather than this decade.

The Short Answer: Four Layers, Not One Protocol

There is no single "agent commerce protocol". What exists is a stack, each layer solving a different problem, backed by different consortiums. Mapped onto the dental clinic scenario:

Layer Protocol What it does in your business
Context & tools MCP Gives your agent safe, structured access to your stock table, your ERP and your purchase history
Agent to agent A2A Lets your agent discover the supplier's agent, ask for availability, price and ETA, and negotiate
Checkout ACP / UCP Builds the cart against the supplier's real catalogue and places the order
Payment & governance AP2 Cryptographically signed mandates — "spend up to $X on category Y without asking a human" — plus an audit trail

The canonical flow reads left to right: MCP supplies context and budget, A2A discovers and negotiates, ACP or UCP closes the order, AP2 authorises the payment. The supplier's agent runs the same sequence in reverse.

MCP — the agent's connection to your data

The Model Context Protocol is the layer that has genuinely won. It's how an agent gets a controlled window into a system: these tables, these actions, nothing else. In the clinic scenario, MCP is what lets the agent answer "how much resin do we have, how fast do we burn it, and what did we pay last time" without handing it your whole database.

A2A — one agent talking to another

Agent2Agent, originally from Google and now under the Linux Foundation, defines how an agent advertises what it can do (an "agent card") and how another agent discovers it and starts a conversation. This is the layer that makes "my agent asks your agent" a specification rather than a metaphor.

ACP and UCP — the actual checkout

Negotiating a price is not the same as placing an order. The Agentic Commerce Protocol (OpenAI and Stripe) and the Universal Commerce Protocol (Google and Shopify) handle the commercial mechanics: real catalogue, real cart, real order against the merchant's system.

AP2 — permission with a signature on it

The Agent Payments Protocol is the piece most business owners care about once they stop being excited and start being nervous. It introduces signed mandates: an intent mandate ("you may buy dental consumables up to $500 per order, $2,000 per month") and a cart mandate (this exact basket, at this exact price, authorised at this exact moment). The result is a spending limit your agent cannot argue its way around, and a record you can hand to your accountant.

Where It Breaks Down in Practice

Two problems, and the second one is the one that will actually stop you.

Agent identity is unsolved. No protocol yet gives an agent a durable, verifiable identity with attached permissions. There is no clean way for a supplier to prove that the agent knocking on its door genuinely represents your clinic and is acting inside its authority. AP2's signed mandates are the best mitigation available today — and they are a mitigation, not a solution.

The supplier has to play along. This is the real bottleneck, and in Perth it is decisive. The dental suppliers a local clinic actually buys from are not going to expose an A2A endpoint any time soon. Their catalogues are web portals behind a login, and if you're lucky there's a price list CSV and someone who will email you a stock file. The full four-layer stack assumes a counterparty that doesn't exist yet in most Australian supply chains.

That's not a reason to wait. It's a reason to build the half you control.

What You Can Actually Build in 2026

The pattern that works today is hybrid. Your side runs the full architecture. The supplier's side gets replaced by an adapter you write.

  1. Detection — a scheduled job watches stock levels against reorder points that account for real consumption rates, not static minimums
  2. Context — an MCP server exposes your inventory, supplier list, negotiated pricing and purchase history to the agent, read-only by default
  3. Sourcing — one adapter per supplier. A proper API where one exists. An authenticated portal integration where it doesn't. A structured email or EDI exchange as the fallback. You are, in effect, writing the supplier's agent as a shim
  4. Decision — the agent compares landed cost, lead time and stock position, and produces a recommendation with its reasoning attached
  5. Approval — a threshold. Under $500 and in-catalogue, it proceeds. Above that, or anything unusual, it lands in a human queue with one-click approve or reject
  6. Execution and reconciliation — the order is placed, the purchase order is recorded, and the receipt is matched back against your accounting system when it arrives

The important architectural point: the decision logic never touches the supplier integration. When a supplier eventually does expose an A2A agent or an ACP checkout, you swap one adapter and everything else stays where it is. You get the value now and the standards later, without rebuilding.

Start With Approval Thresholds, Not Autonomy

Every business we've discussed this with wants to know about the payment step, and our advice is consistent: keep a human in the loop at first, and let the thresholds widen as the agent earns trust. That is precisely the model AP2's mandates encode, and you can implement it without AP2 at all — a spend cap, a category whitelist, an approval queue and a log.

One Australian note worth stating plainly: there is no specific regulatory framework yet for agent-initiated payments. If your agent buys the wrong thing, liability sits with you as the account holder. Design your limits accordingly — the technology is ahead of the rulebook, and that gap is yours to manage.

The Prerequisite Nobody Advertises

None of this works if your stock levels live in a spreadsheet that someone updates on Fridays. An agent that reorders from stale data doesn't save you money — it buys the wrong quantity faster than a human could.

This is the same point we made in Before AI, Build Your Foundations First, and it's why system integration keeps turning out to be the actual project. Agentic procurement is a thin layer of intelligence sitting on top of accurate, real-time operational data. Get the data right and the agent is straightforward. Skip it and the agent is a liability.

Practically, the honest sequence for most businesses is: connect your inventory to your purchasing and accounting systems first, run automated reorder alerts for a month so you can see whether the recommendations would have been right, and only then let the agent act on them.

How We'd Approach It

At usbfork this sits across two of the things we do every week — connecting systems that weren't built to talk to each other, and deploying AI agents that do something operational rather than just chat. A build like this typically looks like:

  • An integration phase — inventory, suppliers, purchasing and accounting wired together with real-time sync and proper error handling. Our SaaS Platform Integration package starts at $3,150 AUD
  • An agent phase — an MCP server over your operational data, the decision logic, the supplier adapters, and the approval queue with its spend limits and audit log
  • A monitoring phase — because an autonomous purchasing agent that fails silently at 2am on a Saturday is worse than no agent at all

You can see the shape of the underlying work in our integration demos and our automated workflow demo.

So — Does the Mechanism Exist?

Yes. MCP for context, A2A for agent-to-agent negotiation, ACP and UCP for checkout, AP2 for signed payment authority. The specifications are real, the consortiums behind them are serious, and within a few years exchanging purchase orders between two agents will be as unremarkable as sending an invoice by email.

What doesn't exist yet is the other end of the wire. Your suppliers aren't ready, agent identity is an open problem, and the regulation hasn't arrived. So build the half you control, keep the decision logic clean of supplier-specific plumbing, put hard limits around anything that spends money, and be ready to swap an adapter when the standards land.

If you're running a clinic, a workshop, a warehouse or a trade business in Perth and you're tired of stockouts discovered too late and reorders done from memory, that's a build we can scope. Start a conversation and tell us what your stock system looks like today.

Written by the usbfork team

Perth, Western Australia

Start a Conversation