[ARCHIVED → Ch 33] PRD — Agentic Payments and the Protocol Wars

Status: Draft PRD — pending placement decision (Part VII tail vs Part VIII tail)

Created: April 7, 2026

Source material: David Kakauridze LinkedIn post (April 7, 2026); see News Articles DB

Why This Chapter Exists

In the last 12 months, five distinct categories of agentic payments infrastructure have shipped — Stripe × OpenAI's ACP, Google's AP2, Coinbase's x402, card-network agent identity frameworks, and AI-scoped virtual card issuance. None of them compose cleanly. The book has no chapter that maps this landscape, and within 18 months it will be impossible to write a credible payments reference work without one.

The chapter is also a natural payoff for two threads already running through the book: the orchestration thesis from Part VIII (bridges capture the value the protocols leave on the table) and the stablecoin micropayment thesis from Part VII (programmable settlement at the HTTP layer becomes practical when the rail is on-chain).

Placement Options

Recommendation: End of Part VIII. The chapter's thesis is fundamentally about orchestration and middleware capturing value from fragmented protocols — that is the Part VIII argument extended one step forward in time.

Running Scenario

Reuse an existing scenario where possible. Recommended: NovaPay — Priya and Kai are already evaluating how to expose NovaPay's payment capabilities to AI agents acting as merchants and as buyers. This continues the thread from Chapter 26 (where NovaPay's stablecoin corridors were already touching x402-adjacent use cases) and Chapter 28/29 (where Kai is already building routing logic).

A secondary scenario worth introducing: a buyer-side AI agent (e.g., a procurement agent at a mid-sized merchant) trying to pay an unknown supplier across all five categories of infrastructure, hitting the integration wall, and being forced to choose one. This dramatizes the 'no clean composition' problem the chapter is built around.

Chapter Outline

Opening (≈400 words)

Reveal-pattern open: Kai watches an AI agent in a NovaPay test environment try to complete a purchase. The agent has a virtual card, it can authenticate via the network's agent ID framework, the merchant supports ACP, and the supplier-side micropayment for an API call routes through x402. Four categories. Three vendors. Two failed handoffs. One transaction that takes nine minutes to complete what a human card payment does in three seconds. The hook: the protocols all exist, and they all work in isolation, and none of them compose.

Section 1: What 'Agentic Payments' Actually Means (≈600 words)

Define the term carefully. An agentic payment is not just 'an AI making a purchase' — it is a payment where one or more authorization, intent, or settlement decisions are delegated to a software agent acting on behalf of a human or another agent. Distinguish from:

• Recurring payments (already covered in Part IV) — these are pre-authorized, not agent-decided
• API-driven B2B payments — these are programmatic but not agentic in the delegation sense
• Card-on-file purchases — these are stored credentials, not delegated authority

Introduce the four open questions every agentic payment has to answer: Who is the agent acting for? What are its spending limits? How is its identity verified to the merchant? What rail does the actual money move on?

Section 2: The Five Categories of Agentic Payment Infrastructure (≈1,500 words)

The core map. Walk through each category in prose with one comparison table at the end.

1. Checkout protocols (ACP) — Stripe × OpenAI's Agentic Commerce Protocol, live in ChatGPT, connected to 1M+ Shopify merchants. What it standardizes: how an AI agent presents intent to a merchant checkout. What it leaves open: identity, settlement rail, dispute handling.
2. Authorization frameworks (AP2) — Google's Agent Payments Protocol, 60+ partners including major networks, PSPs, and wallets. What it standardizes: agent authorization, audit trails, intent-to-payment binding. What it leaves open: the actual payment rail (it is rail-agnostic by design).
3. HTTP-native micropayments (x402) — Coinbase's revival of the HTTP 402 status code, machine-to-machine micropayments settled in stablecoins on Solana. ~35M transactions, integrated by Cloudflare and AWS. What it standardizes: paying for API calls, content, and compute at the HTTP layer. What it leaves open: identity, dispute handling, anything above the protocol layer.
4. Agent identity (network-issued) — Visa, Mastercard, and Amex agent authentication frameworks for verifying that an agent is acting for a legitimate cardholder. What it standardizes: identity attestation. What it leaves open: settlement, intent capture, multi-rail routing.
5. Virtual card issuance for agents — single-use cards with scoped spending limits issued specifically for AI assistants by Marqeta, Lithic, Stripe Issuing, and others. What it standardizes: bounded financial authority. What it leaves open: how the agent finds the right merchant, how the merchant knows it is an agent, how disputes work.

Close this section with a 5×4 matrix: rows = categories, columns = (what it solves / what it leaves open / who controls it / where the value capture sits).

Section 3: Why None of Them Compose (≈800 words)

The core argument. Each category solves a real slice of the problem. None of them solve adjacent slices. The integration burden falls on whoever is building the actual end-to-end agentic payment experience — and that is currently the application developer, not the protocol owner.

Use a concrete walkthrough: trace an AI agent purchase from intent → identity → authorization → settlement → reconciliation, and show which protocol owns which step and where the handoffs break. Include a Mermaid sequence diagram of the failed-handoff scenario from the opening.

Note the early signs of recognition: AP2 already includes x402 as an extension. But this is the exception, not the pattern.

Section 4: The Bridge Pattern — How Payments Always Resolves Fragmentation (≈900 words)

This is where the chapter earns its place in Part VIII. The argument: every previous wave of payments fragmentation has been resolved by middleware that bridged the protocols. The protocol wars come first, then someone builds the bridge, then the bridge becomes the platform.

Three historical bridges as evidence (use existing book material where possible — these have all been touched on earlier in the book and can be cross-referenced rather than re-explained):

• Plaid (~$13B) — bridged fragmented bank data into one API. The protocols underneath (OFX, screen scraping, FDX, OAuth) never composed. Plaid was the bridge.
• Stripe (~$65B) — bridged fragmented payment methods behind one API. The card networks, ACH rails, and APMs never composed at the merchant integration layer. Stripe was the bridge.
• Adyen (~$40B+) — bridged cross-border acquiring into one platform. Domestic acquirers, schemes, and local rails never composed for global merchants. Adyen was the bridge.

The pattern is consistent: the protocol owners do not capture the value. The bridge owners do. This is the same argument made in Part VIII Chapter 28 about why orchestration captures value from PSP fragmentation — it is the same shape, one layer up.

Section 5: What the Agentic Payments Bridge Looks Like (≈700 words)

The forward-looking section. What would a credible bridge for agentic payments need to do?

• Translate between checkout protocols (ACP, AP2, future entrants)
• Carry identity from one framework to another (network agent ID → merchant verification)
• Route settlement across rails based on cost, speed, and compliance constraints (cards for high-value, x402/stablecoin for micropayments, virtual cards for capped agent budgets)
• Provide a unified dispute and reconciliation surface across all of the above
• Be regulated enough that merchants and banks will trust it

Note the open question: does this look like a protocol (lightweight, neutral, governed by a consortium) or a middleware company (vertically integrated, profit-motivated, eventually a platform)? David K.'s bet — and the historical evidence — is that it looks more like middleware than a protocol. The company that builds it probably does not exist yet, or is a current orchestration player (Spreedly, Primer, Gr4vy, or one of the existing PSPs) repositioning.

Tie back to NovaPay: Kai's question is not 'should we build the bridge' — it is 'which bridge do we bet on, and how much do we hedge.'

Section 6: Three Persona Takeaways (≈400 words)

• Newcomers: Agentic payments is not science fiction. Five categories of infrastructure have shipped in the last 12 months. The thing to watch is not the protocols themselves — it is who builds the bridge that makes them compose.
• Merchants: Becoming 'agent-ready' means picking which combination of these protocols to support, knowing none of them are complete and the integration burden currently falls on you. The safest move is to wait for the bridge — but the merchants who move early will be in the agent-driven discovery channels first.
• Architects: The five-category map is the vendor evaluation matrix. Understand which category each of your prospective vendors actually solves, where their gaps are, and which of your competitors is going to be forced to build internally what should have been a bought capability.

Closing (≈200 words)

Close with the line from David K.: the bridge looks more like middleware than a protocol. Then transition: in Part IX, we look at how each of the three personas — founder, operator, architect — should actually use everything we have covered, including this frontier.

Required Diagrams

1. Five-categories map — visual landscape showing the five categories with current major players (Mermaid, similar to the existing Ch 26 stack diagram)
2. Failed-handoff sequence — Mermaid sequence diagram of an AI agent purchase that breaks at the handoff between categories (used in opening and Section 3)
3. Bridge pattern timeline — Mermaid timeline showing Plaid → Stripe → Adyen → ??? as a recurring shape (Section 4)
4. Optional: Composed end-state — Mermaid diagram showing what an agentic payment looks like when a bridge layer exists, contrasted with the failed-handoff diagram

Required Tables

1. Five categories matrix — rows: categories; columns: what it solves / what it leaves open / who controls it / where value accrues (Section 2)
2. Bridge pattern historical analogues — rows: Plaid, Stripe, Adyen, [agentic bridge TBD]; columns: fragmented protocols underneath / what the bridge unified / approximate value captured (Section 4)

Cross-References

• Chapter 26 (Stablecoins as Payment Rails) — for x402 and stablecoin micropayment context, especially the Triple-A/CPN bridge model which is the institutional analogue of what an agentic bridge needs to do
• Chapter 27 (Stablecoin Cards) — for the virtual card issuance layer
• Chapter 28 (Why Orchestration Exists) — for the bridge/value-capture argument structure
• Chapter 29 (Routing, Retries, and Smart Fallbacks) — for the routing logic an agentic bridge would need to extend
• Chapter 30 (Payments in a Fragmented World) — geopolitical fragmentation as the macro analog of agentic protocol fragmentation

Style Guide Compliance Notes

• Reveal pattern open (concrete failed-handoff scenario, then map)
• Prose-first, two tables maximum, four Mermaid diagrams maximum
• All three personas addressed in Section 6
• American English, 'you'-addressed, NovaPay continuity
• No PlantUML (Mermaid only)
• Sourced claims: every vendor stat (transaction counts, valuations, partner counts) needs verification before final draft

Acceptance Criteria

Verification Tasks (do these before drafting)

1. ACP — current status, transaction volume, merchant count (Stripe and OpenAI announcements)
2. AP2 — current partner count, scope (Google announcements, partner press releases)
3. x402 — current transaction count, chains supported, integration partners (Coinbase docs and announcements)
4. Network agent identity frameworks — Visa, Mastercard, Amex official docs
5. Virtual card issuance for agents — Marqeta, Lithic, Stripe Issuing announcements
6. Bridge analogues — verify current valuations for Plaid, Stripe, Adyen at time of drafting
7. Cross-check whether AP2's x402 extension is still the only acknowledged composition or whether others have emerged

Supplementary Source: Citrini Research — "The 2028 Global Intelligence Crisis" (Feb 22, 2026)

Added April 13, 2026. Logged in News Articles DB.

Link: https://www.citriniresearch.com/p/2028gic

What it is: A scenario piece (explicitly "not a prediction") written as a June 2028 macro memo looking back at an AI-driven intelligence crisis. Co-authored by Citrini and Alap Shah (LOTUS). Widely read in finance and tech circles. ~9,000 subscribers engaged, ~1,800 shares at time of logging.

Why it matters for this chapter: The piece is the most vivid articulation in circulation of the exact thesis this chapter is built around — that agentic commerce, once it scales, targets card interchange as the next obvious rent-extraction layer to eliminate, and routes M2M settlement through stablecoins on Solana / Ethereum L2s. It takes the chapter's core argument and runs it forward to its macro conclusion.

Key beats to mine

• "Friction was going to zero" — one of the cleanest framings of the core thesis in prose form. The phrase is usable as a section heading or pull quote (with attribution).
• Habitual intermediation as the first casualty — DoorDash case study. "The DoorDash moat was literally 'you're hungry, you're lazy, this is the app on your home screen.' An agent doesn't have a home screen." Directly supports the Section 3 argument about why the protocols don't compose matters more than it looks — because the downstream consequence is that whoever owns the bridge owns the agent's routing decision, and the agent's routing decision kills the incumbent app.
• Machine-to-machine commerce routes around interchange — explicit claim that once agents control the transaction, eliminating the 2-3% card fee is the biggest repeatable saving. Settlement via stablecoins on Solana / L2s framed as the inevitable answer. This is the bear case for cards and the bull case for x402-style HTTP-native micropayments.
• Fictional Mastercard Q1 2027 headline — "purchase volume growth slows to +3.4% Y/Y from +5.9%... management notes 'agent-led price optimization' and 'pressure in discretionary categories.'" Framed as the "point of no return" where agentic commerce goes from product story to plumbing story. Usable as an epigraph or sidebar — but must be clearly labeled as hypothetical from the scenario, not a real print.
• Card issuer fallout — AmEx, Synchrony, Capital One, Discover hit hardest because rewards programs are funded by merchant interchange subsidy. Their moats were made of friction. Directly relevant to the Section 2 map of where value accrues and who is most exposed.
• Why Visa holds up better than Mastercard in the scenario — "stronger positioning in stablecoin infrastructure." Useful datapoint for the networks-as-bridge-candidates discussion in Section 5.

Proposed usage

Option A — Opening "Stakes" sidebar (recommended). Keep the existing reveal-pattern open (Kai watches the failed-handoff), but add a short boxed sidebar or epigraph in the opening citing Citrini/Shah's line that "friction was going to zero" and the scenario's claim that M2M commerce targets interchange first. Frames the stakes without hijacking the scenario-first open.

Option B — Bear-case callout in Section 2 or 5. Use the piece as a cited viewpoint in the card-networks discussion: "The most aggressive version of this thesis, articulated by Citrini Research and Alap Shah in a widely-circulated February 2026 scenario piece, holds that..." Then 2-3 sentences summarizing the M2M-targets-interchange argument.

Option C — Closing cross-reference to Part IX. The piece's macro framing (labor share of GDP, white-collar displacement, mortgage stress) is out of scope for this chapter but provides a natural bridge to any Part IX or epilogue discussion of what happens when payments infrastructure change is a macro event, not just a technology story.

Preferred combination: A + B. A gives the chapter emotional stakes in its opening without breaking the NovaPay/Kai reveal pattern; B grounds the bear case for cards in a named, cited source rather than leaving it as authorial assertion.

Caveats for drafting

• This is a scenario, not reporting. Every reference must be framed as "Citrini Research's scenario piece argues..." or "in a thought exercise published in February 2026..." Never cite the fictional Mastercard Q1 2027 print as if it were a real earnings print.
• The piece's macro claims (10.2% unemployment, 38% S&P drawdown, mortgage stress, etc.) are out of scope. The chapter should only borrow the payments-specific arguments, not the broader macro scenario.
• Attribution matters. Both Citrini (anonymous Substack author, Citrinitas Capital Management) and Alap Shah (LOTUS Investment Management, co-author) should be named.

Supplementary Source: Simon Taylor — "Agentic Payments Has at Least 10 Different Protocols" (April 24, 2026)

Added April 27, 2026. Logged in News Articles DB.

Author: Simon Taylor (Founder, FintechBrainfood; GTM at Tempo; Advisor, Sardine)

Link: LinkedIn feed post, April 24, 2026 — profile

Why it matters for this chapter: Taylor's post is now the most circulated public taxonomy of the agentic payments landscape. It supersedes the David Kakauridze five-category framework this PRD was built around — adding five more protocols and an entire layer (agent communication) the original framework left out. Taylor's framing is also more useful structurally because it splits what (transaction coordination) from who (mandate collection) from trust (identity attestation), which is closer to how the actual technical handoffs work.

This section reframes Section 2 of the chapter outline using Taylor's framework, surfaces two strategic observations from the post that should run as their own sub-sections, and lists the additional verification tasks the new protocols introduce.

Updated Map: Five Layers, Ten-Plus Protocols

The agentic payments stack is not one problem. It is at least three jobs that keep getting lumped together: agents buying from merchants on behalf of consumers, agents paying invoices on behalf of businesses, and agents paying each other for compute and data at machine speed. Different jobs need different protocols, and the protocols sort cleanly when you stop asking "which one wins" and start asking "which layer of the stack does each one sit on."

Taylor's five layers, restated:

1. Agent communication — how agents talk to each other and to the tools they wield
2. Agent trust — whether the merchant should believe the agent is who it claims to be
3. Mandate collection — what the agent is authorized to do, and on whose behalf
4. Transaction coordination — what the agent and the merchant are agreeing to pay for
5. Transaction authentication — whether the payment instrument itself is legitimate at the network level

Each layer answers a different question, and each one needs its own protocol because no single standard can plausibly cover all five. The reason there are now ten-plus protocols is not that the industry has failed to converge — it is that the problem has at least five orthogonal sub-problems, and each one is being claimed by different incumbents.

Layer 1 — Agent communication

Before any payment can happen, two agents — or an agent and a tool — need a common language. MCP (Model Context Protocol) is Anthropic's standard for an agent to discover and call tools, retrieve data, and use external capabilities. MCP is the most widely adopted of the agent-layer standards: it ships in the major model providers' clients, has an open server ecosystem, and is what most enterprise agent integrations are now built on. A2A (Agent-to-Agent) is Google's parallel standard for agents to communicate with other agents, designed for multi-agent workflows where one agent delegates a sub-task to another.

Neither protocol is a payment protocol. Both are prerequisites for payments. The reason they belong on the map is that everything above them assumes an agent is already talking to either a tool or another agent, and the choice of communication standard determines which payment standards plausibly compose with it. AP2 plus A2A is a coherent stack because both are Google. AP2 plus MCP is workable but requires bridging.

Layer 2 — Agent trust

Once two agents are talking, the next question is should I, the merchant, treat this counterparty as a legitimate agent acting for a legitimate principal? This is the identity attestation problem.

Visa TAP (Trusted Agent Protocol) is the permissioned approach: Visa tells the merchant "yes, this agent is registered, vetted, and carrying real payment credentials issued under our network's rules." Trust is bilateral — the merchant trusts Visa, Visa attests to the agent. This is the agent-era extension of the same trust model that lets a Visa card work at any merchant on the network.

ERC-8004 is the permissionless approach: an Ethereum standard for on-chain agent identity, reputation, and validation. Anyone can register an agent. Reputation is read from chain history rather than vouched for by a network operator. This is the same shape as the difference between a bank-issued card and a self-custodied wallet — and the same trade-offs apply: ERC-8004 is more open and more composable, but offers no recourse if an agent misbehaves.

Both are first attempts. Neither has the merchant adoption to be the answer yet.

Layer 3 — Mandate collection

This layer answers a different question: not "who is this agent" but "what is this agent allowed to do, and on whose behalf?" AP2 is currently the only protocol on the map at this layer. It is Google's framework for capturing the authorization a human gives an agent — spending caps, merchant restrictions, time bounds, intent description — and binding that authorization to the eventual payment.

AP2 is rail-agnostic by design: the mandate it captures is independent of how the money actually moves. That makes it a candidate to be the universal upstream layer regardless of which transaction-coordination protocol wins downstream. It is also one of the reasons Google's stack (covered below) is taken seriously — AP2 is the only mandate protocol, and Google owns it.

Layer 4 — Transaction coordination

The most contested layer on the map. Five protocols, four of them shipped in the last twelve months, each solving a slightly different shape of "what are we paying for and how do we agree."

ACP (Agentic Commerce Protocol) — OpenAI and Stripe's standard for shopping carts and payment tokens. The only one of the five with meaningful real-world traffic: live in ChatGPT, integrated by Etsy and Instacart. ACP is optimized for agent-as-buyer flows where the merchant exists, the cart exists, and the agent just needs a clean way to push intent and a token through to checkout.

UCP (Universal Commerce Protocol) — Google and Shopify's framework. Where ACP is buyer-led ("agent presents cart"), UCP is merchant-led: merchants publish a manifest describing what they sell, what discovery looks like, and what negotiation rules they accept. Agents discover merchants and negotiate within those rules. UCP is the more ambitious design — it tries to handle the part of commerce that happens before a cart exists.

MPP (Merchant Payments Protocol) — Tempo and Stripe's protocol for agent-to-agent or HTTP payments. The distinguishing feature is rail polymorphism: MPP is designed to settle over cards, stablecoins, or Lightning depending on the situation, with the protocol carrying the same payment intent across rails. This is the protocol Taylor is closest to — he is GTM at Tempo — and is the most architecturally aligned with the bridge thesis from Section 4 of this chapter.

x402 — Coinbase and Cloudflare's. An agent makes an HTTP request to a gated resource, receives a 402 response with a stablecoin payment prompt, sends payment, and gets the resource. Settlement is on-chain, typically on Solana. x402 is the protocol for the case where there is no cart and no merchant relationship — just a resource priced per access.

AXTP — early-stage, focused on agents paying for MCP servers. Useful conceptually because it makes the recursive case visible: agents need to pay for the tools they use to act on behalf of users, which means MCP servers themselves need a billing model, which is what AXTP is for. Much smaller in adoption than the other four.

Layer 5 — Transaction authentication

Coordination decides what is being paid for. Authentication decides whether the payment instrument is legitimate at the network level.

VIC (Visa Intelligent Commerce) and MAP (Mastercard Agent Pay) are the card-network answers: secure, card-like tokens minted specifically for agents on each network. The agent presents the token to the merchant, the network authenticates it, the merchant treats it like a card payment for clearing and settlement purposes. The networks' bet is that the existing card rails — interchange, dispute rights, chargeback protection, reward economics — are too valuable to reinvent, and that the right move is to extend the rails to agents rather than let agents bypass the rails entirely.

Stablecoins are the alternative: the agent does not need a token issued by a network because the on-chain payment is itself the authentication. The trade-off is no universal standard yet — different stablecoins, different chains, different settlement guarantees, and no clean equivalent to chargeback rights or dispute resolution. The card networks have the rails. Stablecoins have the programmability. Whether merchants ultimately need rails more or programmability more is the question whose answer determines a large fraction of the next decade's payment economics.

Strategic Observation 1 — A Google Stack Is Quietly Forming

One of Taylor's sharpest observations is that A2A → AP2 → UCP composes into a coherent end-to-end Google stack:

• A2A for agent-to-agent communication
• AP2 for capturing the human's authorization
• UCP for merchant discovery and transaction coordination

All three are Google-led. All three are designed to interoperate. None of them is rail-locked: a Google-stack transaction can settle over cards, ACH, or stablecoins, depending on what the merchant accepts.

Google has shipped internet-scale standards before — HTTP/2, QUIC, Protocol Buffers. Most succeeded technically; some succeeded commercially. The pattern that matters here is not whether each individual protocol wins, but whether the stack composes cleanly enough that an agent built on Google's clients (Gemini and successors) can transact end-to-end without leaving Google-blessed protocols. If yes, Google's stack becomes the default for a meaningful share of agent-initiated commerce — the same way Apple Pay became the default for a meaningful share of mobile checkout, not because it was the best protocol but because it was the path of least resistance from inside the Apple ecosystem.

The competitive question is who builds an equivalent stack. OpenAI has ACP and a partnership with Stripe but no mandate-collection protocol of its own. Anthropic has MCP — the lower-layer communication piece — but no payments protocol. Coinbase has x402 but only at the transaction-coordination layer. The two firms most able to compose competing stacks (OpenAI and Anthropic) would each need at minimum a mandate-collection protocol and a merchant-coordination protocol they do not currently own.

This sharpens the chapter's bridge thesis. The original PRD assumed the bridge would look like a neutral middleware company in the Plaid / Stripe / Adyen tradition. The Google stack is a credible alternative future: the bridge is not neutral middleware, but a vertically-integrated stack from a single hyperscaler. Both shapes need to be addressed in Section 5.

Strategic Observation 2 — HTTP 402, the Sleeper Code

In 1997, the HTTP/1.1 specification reserved status code 402 for one purpose: "Payment Required." Then it left the code undefined. For nearly thirty years, every web server in the world has had a slot for charging money built into the protocol — and nobody used it. Browsers did not implement it. Servers did not return it. The code sat dormant.

Agents are forcing the issue. MPP and x402 are both, in different forms, the implementation of HTTP 402 that the 1997 working group declined to specify. MPP carries payment intent inside an HTTP exchange. x402 returns the literal status code with a stablecoin payment prompt. Today, both are tiny — millions of transactions a year, in a world that processes hundreds of billions.

In a decade, agent-native payments may be the majority of all payments, and the protocols that get there first will be sitting on the most valuable real estate in the payment stack — the layer between any two pieces of software that need to exchange value. The card networks understand this, which is why VIC and MAP exist. The stablecoin issuers understand this, which is why x402 settled on Solana and not on a credit card rail. Most merchants do not yet understand this, which is why none of the protocols at Layer 4 has a dominant share of merchant integration.

This is not a forecast. It is a structural claim: the layer at which agentic commerce settles is currently being claimed, and the firms claiming it are not the firms that won the previous wave. Whoever controls the protocol that the median agent uses to pay the median merchant will be able to do at agent scale what Visa did at card scale — and they will do it without paying the existing card networks for the privilege.

This observation is the chapter's sharpest reveal-pattern hook. The recommended opening change: lead with the 1997 HTTP 402 reservation as the historical setup, then cut to the NovaPay failed-handoff scenario as the present-day reveal of why the dormant code is finally being implemented.

All the Protocols at a Glance

Note on count: Taylor's headline says "at least 10" because three of the entries above (Visa TAP, AP2, the network identity frameworks) were grouped together in earlier framings. Counting the layer-discrete protocols, there are thirteen — and more are likely to ship before this chapter is finalized.

Implications for the Chapter Outline

This material updates the existing PRD in three concrete ways:

1. Section 2 is replaced. The five-category map becomes the five-layer / ten-plus-protocol map. The layer framing is more useful than the category framing because the layers correspond to actual technical handoffs, not just functional categories. The 5 × 4 matrix originally specified at the end of Section 2 is replaced by the comparison table above.
2. Section 3 ("Why None of Them Compose") is reinforced, not replaced. Taylor's framework actually makes the composition problem more visible: there are now five protocols competing for Layer 4 alone, none of them cross-implement, and the bridge to Layer 3 (AP2) is acknowledged only by the Google-stack subset. The failed-handoff sequence diagram should be updated to use Taylor's layer names and show at least one cross-layer break (e.g., ACP at L4 trying to consume an AP2 mandate from L3 with no defined binding).
3. Section 5 ("What the Bridge Looks Like") gains a concrete competitor. The Google stack (A2A + AP2 + UCP) is itself a candidate bridge, except it is vertically integrated rather than neutral. The chapter should now address: does the bridge look like (a) neutral middleware in the Plaid / Stripe / Adyen tradition, or (b) a vertically-integrated hyperscaler stack in the Apple Pay tradition? Taylor's post makes (b) feel more plausible than the original PRD allowed.
4. Opening rewrite. The strongest reveal-pattern open is now the HTTP 402 historical reservation (1997, dormant code) cut to the NovaPay failed-handoff in 2026. This is more powerful than the original "Kai watches an agent fail" open because it grounds the urgency in a thirty-year-old structural fact rather than a single demo failure.

Verification Tasks Added

Add to the existing verification list before drafting:

• MCP — current adoption metrics (clients shipping it, server count); Anthropic's docs
• A2A — current adoption metrics, partner list; Google's announcements
• Visa TAP — official protocol documentation, adoption claims, distinction from VIC
• ERC-8004 — current standardization status (draft / final), early implementations
• UCP — official Google / Shopify joint documentation, distinct from ACP
• MPP — Tempo + Stripe joint announcements; verify rail support claims (cards / stables / Lightning); current production status
• AXTP — find primary source; appears earliest-stage of the ten
• Cross-check whether Taylor's "Google stack" framing (A2A → AP2 → UCP) is something Google itself is positioning, or only an observed pattern from outside
• Confirm the HTTP 402 reservation date (RFC 2068, 1997, vs RFC 2616, 1999) before using as opening hook

#

• Final placement: end of Part VIII, end of Part VII, or new sub-part?
• Should this be one chapter (~5,000 words) or split into two (one mapping, one bridge thesis)?
• Reuse NovaPay scenario or introduce a new running scenario for the agentic theme?
• Is there an executive interview opportunity here to ground the bridge thesis (e.g., one of the orchestration players, or someone working on AP2 or ACP integration)? Update April 27: Simon Taylor (Tempo, MPP) is now the obvious first call — his post is the canonical taxonomy and Tempo is one of the protocols.
• Given the protocol count has gone from five to thirteen, does the chapter still fit in ~5,000 words, or does it need to split into a mapping chapter and a bridge-thesis chapter?
• Does the reveal-pattern opening change to lead with the 1997 HTTP 402 reservation, or stay with the NovaPay scenario? (Recommendation: blend — open with the 1997 line as a one-paragraph epigraph, then cut to NovaPay.)
• Should the Google stack be addressed as a sidebar in Section 5, or promoted to its own sub-section under "What the Bridge Looks Like"? (Recommendation: own sub-section. It is a credible alternative future, not a footnote.)