At Silicon Store, our agent integrates against five protocols to do its job. Each one sits at a different layer of the agentic commerce stack, and getting the layer mapping right is most of the work.
This post is our integration-level read on the stack: what each protocol handles at our layer, what we've found works and what doesn't, and which layers we think will determine the shape of the category over the next twelve months. We're writing it because the protocol war is the actual story in agentic commerce right now — the agent at the top of the stack only works if the layer beneath it knows how to expose products, prices, policies, and payments in a way an agent can consume — and we've been integrating against every layer of it through the entire wave.
Short version: the layers are settling into a pattern. Tools, agent-to-agent, transactions, discovery, payments. We touch each one differently. Here's what we've found.
Why the protocol layer matters at all
Every previous wave of internet commerce was shaped less by the products and more by the protocols beneath them. HTTP defined how browsers and servers talked. OAuth defined how apps got user permission. Stripe's API defined what payment integration could feel like. The protocols won, the companies that built on them followed.
Agentic commerce is heading the same way. We've found this most clearly in the gap between what's possible at a demo level and what's possible at scale. The demo always works. The integration is where the protocol layer either lets us ship reliably or doesn't. The articles in this space that focus on the model usually miss this — the model is fine; the bottleneck has moved underneath.
Here's how the layers sit, top down, in terms of how our agent actually uses them.
MCP: the tool layer we call into
At the tool layer, our agent calls MCP — the model context protocol — every time it needs to fetch product data, check inventory, or run a structured task against a retailer's backend. We adopted it because it was the cheapest standard to add and it gave us a uniform interface across very non-uniform retailers.
What we use it for, concretely:
- Tool discovery — our agent can ask a retailer's MCP server what it offers without us shipping a per-retailer integration.
- Standardised request/response shapes — we get fewer per-retailer edge cases because the contract is shared.
- Permission scoping — tool calls can be gated per user, per session, per scope.
What MCP doesn't do for us: anything about transactions, payments, or product taxonomy. It's the pipe — what we put through the pipe is the actual commerce work. We've found that treating MCP as infrastructure rather than as a commerce protocol clarifies a lot of integration debates. It's the substrate.
ACP: how we hand off a buy intent
At the transaction layer, our agent issues a structured buy intent — a typed purchase request the retailer accepts or rejects — using ACP, the agentic commerce protocol. It's clean for the handshake itself: product, price, intent, accepted-order in a single structured exchange.
What we use it for:
- Buy intent — our agent surfaces a product and tells the merchant we'd like to transact under specific constraints (budget, variant, delivery window).
- Order confirmation — the merchant either accepts and returns an order, or rejects with a reason we can route back into the agent's reasoning.
- Payment delegation — the actual money movement happens through the payment rail attached to ACP rather than through our system.
What we've found at the integration level: ACP is great for the structural handshake and leans hard on a single payment rail. That's a non-issue for merchants who already process there and a friction point for everyone else. The version of the protocol that hits everywhere will eventually be rail-neutral, and we expect that's where the standard is heading.
ACP is also the protocol where the recent industry pivot toward retailer-controlled checkout matters most. Direct in-chat checkout — where the agent fully owns the purchase — has stalled in the broader industry for reasons we've described elsewhere. The pattern that's emerging is closer to discover-in-agent, transact-in-retailer-surface. ACP still defines the handshake; the question is just where the handshake terminates.
UCP: how we read the catalogue
At the discovery layer, our agent reads UCP — the universal commerce protocol — when a retailer publishes one. UCP is where we get the catalogue, real-time pricing, inventory state, and cross-merchant comparability.
This is the layer most directly aligned with what our agent does. Our job is to compare retailers and find the best option — UCP makes that comparison cleaner because the participating retailers speak the same schema. We've found that when a merchant publishes a UCP feed and that feed is fresh and complete, the merchant gets surfaced ahead of equivalent merchants who don't — not because we prefer them, but because the agent has higher confidence in the data and lower uncertainty in the recommendation.
What we use it for:
- Catalogue ingestion at scale, without scraping HTML.
- Real-time pricing and inventory at decision time.
- Cross-merchant comparison on a fair schema.
- Universal cart shapes that let our agent stage multi-merchant orders.
There is a tradeoff worth naming. UCP came out of a single ecosystem; its gravity tilts toward that ecosystem's surfaces. The protocol is technically open and we use it as if it were — but the optionality on which agentic surfaces a UCP-publishing merchant becomes legible to first isn't neutral. We've taken the view that we'd rather work with the protocol and read the catalogue cleanly than wait for a perfectly-governed alternative.
AP2: the payment layer we watch most closely
At the payment authorisation layer, our agent operates inside pre-authorised envelopes defined under AP2, the agent payments protocol. A user pre-authorises our agent with specific constraints — these brands, these categories, up to this spending cap, expiring on this date — and our agent transacts inside that envelope without re-prompting at every purchase.
This is the layer we watch most closely because it's the one we think will define the upper bound of agent autonomy for the next twelve months. Tools, discovery, transactions are infrastructure problems with known shapes. Payments are an authorisation problem, and authorisation is where trust either holds or collapses.
What we use it for:
- Pre-authorised purchase envelopes — the user defines the rules once, our agent transacts inside them.
- Verifiable authorisation signals to merchants — the merchant gets a structured assertion that this transaction was authorised by a real user, not a malicious bot.
- Disputes that map back to the original authorisation envelope — so when something goes wrong, the answer to "who authorised this" exists.
We've found that AP2-style envelopes are the single most useful primitive for getting from approval-required autonomy to genuine pre-authorised autonomy without burning user trust. The dispute-resolution layer underneath them is still early — but it's catching up faster than any other layer of the stack right now.
A2A: the layer we don't use yet
At the agent-to-agent layer, A2A defines how a buy-side agent (acting for the user) talks to a sell-side agent (acting for the merchant). This is the layer we don't use today and won't use much in the next year.
It matters less right now because most commerce is still buy-side-agent-to-merchant-backend, not agent-to-agent. The sell-side agents that would make A2A load-bearing don't exist at scale yet. But it's the protocol most likely to matter in 2027 and beyond, when both sides of the transaction are agents and the human role shifts up to setting policy rather than executing the trade.
We've been tracking the research carefully — the early experiments in agent-to-agent negotiation are interesting and the patterns they surface (agents under-performing when they have weaker models, humans not noticing the disadvantage) will be highly relevant once the sell-side agent is real. For now it's on our roadmap, not our integration path.
How the protocols actually fit together
The cleanest way to think about the stack — and the order we integrated against ourselves — is by layer:
- Tools: MCP — how our agent calls into a merchant's backend.
- Discovery: UCP — how we read the merchant's catalogue.
- Transactions: ACP — how a buy intent becomes an accepted order.
- Payments: AP2 — how the agent's transaction is authorised, audited, and disputed.
- Agent-to-agent: A2A — how the buy-side agent talks to a sell-side agent. Not in our path yet.
We've found that the order most merchants converge on for integration is similar to the order we did: MCP first because it's the cheapest to add and the most general, then UCP because the discovery surface unlocks the most agent traffic, then ACP and AP2 as the transaction and payment paths mature. A2A sits in research for almost everyone until the sell-side agent exists at scale.
Where the gaps still are
Three things the current stack does not solve cleanly. We hit each of them in production.
Async authorisation. Existing payment frameworks assume a human is present at the moment of authorisation. Our agent often runs hours after the user has gone to sleep, completing a long-running task that started in the morning. AP2's pre-authorised envelopes start to address this, but there's no industry-standard answer yet for how a payment network distinguishes a legitimate async agent transaction from a delayed fraud attempt. We've ended up running our async tier in narrow categories with extra safeguards while this layer matures.
Dispute mapping. When an agent buys the wrong product, the resulting dispute doesn't map cleanly to the existing categories — "unauthorised transaction" or "item not as described." The payment network rules don't yet say who is responsible: the user, the agent, the merchant, or the platform. We've found this is the single biggest open question in real production deployments, and it's not technically a protocol problem — it's a governance problem the protocols haven't been forced to answer yet.
Bot verification. Transaction and discovery protocols both assume the agent calling them is legitimate. We sign our agent's calls cryptographically so merchants can distinguish us from arbitrary automation, but the standard for this layer is still being negotiated. Until "Know Your Agent" is as routine as "Know Your Customer," merchants default to either trusting every agent or trusting none — and neither default scales.
What we've found navigating these layers
A few patterns we keep coming back to.
Protocols that solve agent-side problems get adopted faster than protocols that solve merchant-side problems. MCP and AP2 both add value to the agent without much cost to the merchant — they shipped widely. The protocols that require merchants to rewire their checkout move slower, regardless of how good the spec is.
Standards work better when they decouple identity from delivery. The protocols that are succeeding don't try to own the merchant relationship — they expose a uniform interface and let merchants and agents work out the details. The ones that try to bundle the payment rail or the merchant agreement into the protocol move slower because they're asking for a bigger commitment up front.
Protocol fidelity is a competitive advantage. When our agent decides which retailer to recommend, the single biggest signal is not price — it's whether the protocol-layer data is consistent across the user's session. A merchant whose discovery feed says one price and whose transaction handshake returns another loses ranking. We don't think most merchants have realised this yet, and it's the most actionable thing in this post if you're on the merchant side.
Looking ahead
Our prediction, from where we sit: the long-term stable shape is MCP at the tool layer, UCP plus ACP coexisting at the catalogue and transaction layers (with merchants supporting both), AP2 winning the payment authorisation layer because the payment networks are aligning behind it, and A2A becoming load-bearing once the sell-side agent is a real thing rather than a research demo.
We're confident on the tool, discovery, and payment layers. The transaction layer is the one most likely to evolve because the demands on it — multi-item, loyalty, configurators, async authorisation — keep growing and the current specs were sized for a simpler shape.
If you're a merchant trying to figure out where to invest first, our read from running an agent across this stack: MCP is the cheapest first step; UCP unlocks the most discovery surface; AP2 is the one to watch over the next twelve months because the answer to the authorisation question is going to determine how much agent autonomy your customers' agents end up having.
We'll keep writing about what we're learning at the integration layer as the specs evolve. If you're building against these protocols and reading them differently than we are, we'd love to compare notes — the parts of the stack we were most wrong about were the parts where someone else had already integrated and could tell us where the spec drifted from real merchant behaviour.