An executive playbook on the agent-to-agent economy: autonomous procurement, algorithmic corporate wallets, machine-negotiated mortgage lending, and healthcare claims that argue with themselves. Five chapters -- one cross-cutting thesis, then four domains -- locate the Mandate Boundary in each: where software may decide alone, where a human still has to sign, and what to build by 2027 versus only position for by 2030. Free to read here and to listen to (102 minutes, synthetic voice); the typeset PDF is on Ko-fi.
This is an adapted edition of the original article. It preserves the section argument and evidence; use the source link for the published version and any interactive material.
When Software Hires Software
Every roadmap answers one question, whether it says so or not: who acts. For thirty years the answer was a person, and the software just carried the paperwork. That is the assumption breaking right now, and it is breaking on the buying side first.
Look at what actually shipped between April 2025 and April 2026, not what got keynoted. Mastercard built Agent Pay, tokens that bind a card to a specific agent, a specific merchant, and a specific consent policy 1. Visa built the Trusted Agent Protocol, a verified identity for an agent plus a signed consent record from the issuer 1. Google built AP2, which turns a purchase into three cryptographically signed contracts — an Intent Mandate for what you asked for, a Cart Mandate for what got assembled, a Payment Mandate for what gets charged 2. None of that is a chatbot feature. It is financial infrastructure for a counterparty that isn't a person, built by the companies whose entire business is knowing who is allowed to move money.
That is the fact this book is built around: the frontier of AI product work has quietly moved from can software understand something to can software be trusted to act on it, alone, with money and consequences attached. Call it what it is. Software is starting to hire software — to shop from it, negotiate with it, pay it, and increasingly, to answer to it when something goes wrong. Every domain chapter that follows is one industry's version of this same shift. This chapter is the shift itself, and what a leader does about it before the shape of 2030 is remotely settled.
The line that actually matters
Forget the debate about whether AI is "agentic" — that word is mostly marketing residue at this point (Gartner counted about 130 vendors with real agentic capability out of thousands claiming it, and predicts over 40% of agentic AI projects will be scrapped by the end of 2027 for cost, unclear value, or missing risk controls 3). The debate worth having is narrower and more useful: for a given decision, where does authority to act without a human in the loop currently sit, and how far are you willing to move it?
Call that the Mandate Boundary — the line separating decisions a system may execute unaccompanied from decisions that still require a human counter-signature. Every mandate protocol built in the last eighteen months is, underneath the branding, a machine for drawing this line precisely and making the drawing enforceable: AP2's Intent and Cart Mandates exist specifically to separate "what I authorized" from "what the agent decided" so the boundary survives a dispute 2. Visa's Trusted Agent Protocol exists to prove an agent's identity to a merchant before the boundary gets tested 1.
Your roadmap is not really a list of features. It is a series of bets about where you move the Mandate Boundary, for which decisions, on what evidence, and how fast you can move it back if the evidence turns bad. Once you see the roadmap this way, "what should we build for 2027 versus 2030" stops being a features question and becomes a governance question — which is a much more answerable one, because governance questions have precedent even when the technology doesn't.
The protocol for letting software transact is now mostly solved. What remains unsolved — and what every domain in this book is really fighting over — is who is accountable when the transaction is wrong.
The wave that keeps breaking roadmaps
Here is the uncomfortable part for anyone used to eighteen-month planning cycles: the frontier moved and reversed inside a single one. OpenAI launched in-chat Instant Checkout on the Agentic Commerce Protocol in September 2025, built with Stripe, aimed squarely at the "customer never leaves the chat" vision every 2025 keynote gestured at. By March 2026 — six months later — OpenAI retired it. Reported adoption topped out somewhere between "about a dozen" and "closer to thirty" live merchants, and Walmart found checkout inside ChatGPT converting roughly three times worse than a click-through to its own site 4. The pattern that survived wasn't "AI closes the sale." It was "AI helps you discover, and you still buy where you already trust the receipt."
That is not a story about a bad product. It is a story about the actual shape of this wave: pieces of it move immediately and permanently — protocol governance for MCP and A2A both landed with the Linux Foundation inside about a year of each launching 5 6 — while other pieces that looked equally inevitable in a demo (consumers letting an agent complete the whole purchase) stall on trust that hasn't been earned yet, and might not be earned on anyone's preferred timeline. Both things are true about the same eighteen months. A roadmap built on either "none of this is real yet" or "all of this is inevitable by next quarter" will be wrong regardless of which one you pick, because the wave doesn't move as one wave. It moves as several waves at different speeds, and the speed each one travels at is set by how expensive it is to be wrong, not by how good the technology has gotten.
That single fact is the whole argument for building flexibility into a 2030 plan instead of a fixed destination. Nobody who published a roadmap in early 2025 predicted that the most hyped consumer agentic-commerce feature of the year would be dead by its own six-month anniversary while the identity and payment rails underneath it kept right on standardizing. The rails were boring, so they shipped. The consumer-facing bet was exciting, so it got canceled. Build for the second pattern to repeat, because it will keep repeating: the plumbing keeps compounding quietly, the exciting front-end bets keep dying in public.
Where the moat still is, once the protocol is free
Here is the part that should reorganize how you think about differentiation. MCP and A2A are not proprietary technology anymore — they are Linux Foundation projects, governed the way Kubernetes is governed, built specifically so no single vendor can own them 5 6. If your 2027 plan is "we will expose an agent interface," you have described table stakes, not a strategy. Every competitor with an engineering team can expose the same interface by next quarter, and several already have.
The moat was never going to be in the interface. It has to be in what stands behind it when an agent — yours or someone else's — asks a hard question and needs an answer a court, a regulator, or an auditor will accept later. Three things sit behind a durable answer, and none of them are the protocol:
Verified facts with provenance. Not "the model's best guess," but a value with an evidence trail — which document, which page, which rule version, computed when, by what — attached to it permanently. This is expensive to build and boring to describe, which is exactly why it's defensible.
Warranted outcomes. A price attached to being right, not just to answering. The difference between a vendor who tells you a decision and a vendor who stakes something on that decision being correct is the difference between a feature and a business.
Accountable judgment. A specific party — a licensed underwriter, a named institution, a warranty-backed system — who absorbs the consequence when the decision is wrong. Software can execute a mandate. It cannot yet be the thing a regulator holds responsible when the mandate was a mistake, and nothing in any protocol shipped so far changes that.
Every domain chapter that follows names the version of these three things that applies to one industry, because "verified facts, warranted outcomes, accountable judgment" is not a slogan — it is the actual checklist for telling a real product from a demo in this wave. If your 2027 plan doesn't strengthen at least one of the three, it is decoration on top of someone else's infrastructure, and it will feel that way to your customers within a year.
The menu: how the winners actually get paid
Naming the moat is only half the roadmap. The other half is a pricing decision every one of these initiatives eventually forces, and getting it wrong is a common way to build the right infrastructure and still lose the business. Four patterns recur across every domain in this book, and the durable products almost always combine two of them rather than picking just one.
Metered access prices the thing closest to a commodity — a single tool call, a single check, a single page processed — by the unit, the way a document-extraction API bills per page or per credit. This is the right model for atomic, deterministic, low-stakes operations: cheap enough that volume is the business, and simple enough that a buyer can predict their bill before they commit to it. It is also the model most exposed to commoditization, because a metered price is trivially comparable to a competitor's metered price. Use it for the parts of your product that really are commodities, and stop pretending otherwise.
Outcome-warranted pricing charges for being right, not for answering — a fee per approved authorization, per closed loan, per resolved case, with an actual guarantee or fee-at-risk attached if the outcome turns out wrong. This is the model that only becomes available once you've built the "warranted outcomes" leg of the moat described above, and it is worth far more per transaction than metered access, because the buyer is no longer purchasing an answer. They're purchasing the transfer of a risk they used to hold themselves.
Tiered subscription with role-gated access sells a seat, not a call — a monthly or annual fee that unlocks a specific bundle of tools, data freshness, and volume, with the tier determining not just price but rate limits and which tools are even visible to that user. This is the commercial expression of the same progressive-disclosure logic that keeps a well-designed agent's tool count manageable: a junior role's seat exposes a handful of tools at a modest rate limit; a senior role's seat exposes more tools, deeper data, and a higher ceiling; an enterprise tier adds custom overlays and effectively uncapped throughput. Price the tier to the value of what a role can see and do, not to how much compute it happens to consume.
One-time integration plus recurring usage front-loads a fee for the unglamorous work of connecting to somebody else's system of record — a lender's loan-origination system, a payer's claims platform, a hospital's EHR — and then layers a recurring fee, usually one of the first three patterns, on top once the connection is live. Skip this and you'll underprice the hardest, least repeatable part of the sale: getting into the account at all.
Every domain chapter that follows names its own version of this menu, because the question "what do we charge for" deserves the same concrete answer as "what do we build," and a roadmap that only answers the second question will spend 2027 giving away, metered by the call, the exact thing it should have been warrantying by the outcome.
What to build now, and what to only prepare for
Treat 2027 and 2030 as two different kinds of bet, not two points on the same line.
2027 is a build horizon. The pattern already visible across every domain in this book is software recommends, a human authorizes — a mandate gets assembled with evidence, a specific accountable person signs it, and the system's job is to make that signature fast, well-informed, and cheap to defend later. This is buildable today with technology that already exists: evidence-bundled decisions, role-scoped tool access so a human reviewer sees exactly what they need and no more, and outcome-priced pilots that put your own money where your accuracy claims are. Build this now. It compounds — every decision it makes correctly becomes training data, a defensible track record, and one more data point in the warranty argument you'll need to expand the Mandate Boundary later.
2030 is a positioning horizon, not a build target. The pattern to prepare for, without betting the company on its exact timing, is software authorizes within a policy a human already set — continuous, standing mandates re-evaluated as facts change, rather than one-time approvals re-litigated from scratch every time. Mortgage lending's "always pre-approved" is a plausible version of this. Auto-locking a rate and closing a loan without a human touching it is not plausible on any near-term timeline, for the same reason full agentic checkout stalled: the cost of being wrong is high and the trust to be delegated hasn't been built yet. The organizations that win this horizon won't be the ones who guessed the date correctly. They'll be the ones who spent 2027–2029 accumulating the evidence trail, the warranty capacity, and the regulatory relationships that let them move the Mandate Boundary the moment the trust actually exists — while their competitors are still arguing about whether it exists yet.
Practically, that means every initiative on your roadmap should answer two questions before it gets funded. First: which side of the Mandate Boundary does this sit on today, and what evidence would move it? Second: if the specific bet inside this initiative turns out to be six-month-hype rather than durable infrastructure — the Instant Checkout pattern rather than the AP2 pattern — how much of what we built survives the pivot? Facts infrastructure, evidence schemas, and accountability relationships survive almost any pivot. Bets on a specific vendor protocol or a specific consumer behavior do not. Weight your 2027 spending accordingly, and you get the flexibility to pivot without having wasted the year finding out you needed it.
The rest of this book walks that same S-curve through four places where the money is already real, not speculative: procurement, where agents are starting to shop from other agents; banking, where the wallet itself is becoming an algorithm; mortgage lending, where a decision infrastructure is quietly replacing what used to be a document pipeline; and healthcare, where a claim is starting to argue with itself before a human ever sees it. Each chapter names the specific Mandate Boundary in that domain, where it sits today, and what it would take to move it. Start wherever your business already touches one of these four — the mechanics transfer faster than you'd expect, because underneath the industry-specific vocabulary, it's the same question every time: who is allowed to act, on what evidence, and who answers for it when they're wrong.
The Procurement Agent
Somewhere in your target account list right now, a piece of software is deciding whether your company is worth a human's time — and it is making that call faster than a person could finish loading your homepage. It does not watch your demo video. It does not read your case studies for tone. It checks whether your claims can be verified without picking up a phone, and if they can't, it drops you from the shortlist before anyone on your sales team learns you were ever being considered.
Call that check the Vendor Handshake: the exchange of signed, checkable claims — specs, security attestations, pricing, compliance status — that a buying agent runs against a vendor before it will do anything a human buyer used to do first, like shortlisting, comparing, or requesting a quote. Every domain in this book has its own version of the moment one piece of software decides whether to trust another before a person gets pulled in. In procurement, that moment is already happening, in production, at scale — just not in the form most vendor marketing sites were built to survive.
This chapter answers a narrower question than "will AI change B2B sales." It answers: when the buyer, the comparison-shopper, and increasingly the person drafting the RFP response are all software, what should a vendor build in the next twelve months, and what should it merely position for?
The Money Is Real. The Checkout Isn't. Not Yet.
Start with what's actually been funded, because procurement is one of the few corners of this wave where the capital allocation tells you more than the keynotes do.
Profound, a company that exists to make brands legible to AI answer engines rather than search engines, raised a \$96 million Series C at a \$1 billion valuation in February 2026, becoming the category's first unicorn. Seven months later, in September 2026, it raised a \$180 million Series D at \$1.8 billion, co-led by Sequoia and Kleiner Perkins, with revenue up roughly 3x over that same six-month stretch and more than 1,000 enterprise customers on the books, including Comcast, Estée Lauder, and Walmart 7. That is not hype-cycle money. That is a market that has already decided generative-engine optimization — GEO, the practice of making your company's facts legible to the models doing the summarizing — is worth real budget, twice, in under a year.
Incumbents are reading the same signal. Adobe agreed to buy Semrush, the SEO analytics platform, for \$1.9 billion in November 2025, explicitly to fold GEO capability into Adobe Experience Cloud before someone else owns the category 8. When a company with Adobe's balance sheet pays nearly \$2 billion for a bolt-on rather than building it, that's a company telling you the build-versus-buy math already favors moving fast.
And the demand side backs this up with actual commerce data, not just vendor claims. On Shopify's Q1 2026 earnings call, President Harley Finkelstein reported that AI-referred traffic to Shopify stores was up roughly 8x year over year, with orders from AI-powered search up nearly 13x — new buyers arriving through AI channels at close to twice the rate of other channels 9. By the Q2 2026 call in August, both AI traffic and AI-attributed orders had tripled year over year again, and Finkelstein noted that AI search running on Shopify's own structured catalog data converted at roughly twice the rate of AI search relying on scraped product pages 9. Read that last detail twice — it's the whole chapter in one sentence. The advantage wasn't "we're in more AI answers." It was "our facts are structured well enough for the answer engine to trust them without scraping."
Meanwhile, distribution is fragmenting into open warfare. Amazon expanded its robots.txt blocklist to keep OpenAI's ChatGPT-User and OAI-SearchBot crawlers off its product pages in late 2025, protecting an advertising business that depends on shoppers browsing Amazon directly rather than through a chat window that skips the ads 10. Then Amazon sued Perplexity, accusing its Comet browser of disguising its shopping agent as a regular human session to keep scraping after being blocked — and won a preliminary injunction in March 2026, before the Ninth Circuit vacated it in August on the technical grounds that it was the user, not Perplexity, accessing Amazon's servers under federal computer-access law 10. Nobody in that fight was arguing about whether agents will shop. They were arguing about who gets paid when they do.
Set all of that against the thing that was supposed to be the headline feature: OpenAI's Instant Checkout, launched in September 2025 to let a purchase complete entirely inside a chat window, retired roughly six months later after adoption topped out somewhere between a dozen and thirty live merchants and Walmart found in-chat checkout converting at about a third the rate of a click-through to its own site 4. Consumers, it turns out, still want to land on a page they recognize before money moves. That is the same trust gap this book's opening chapter identifies across every domain — protocol infrastructure compounds quietly while the consumer-facing bet dies in public.
So here is the honest 2027 map for procurement, and it is not the map most GTM decks are drawing. The wedge isn't consumer checkout autonomy — that stalled, and there's no evidence it's coming back on anyone's preferred timeline. The wedge is being legible and verifiable to the agents doing the comparing, whether those agents are consumer-facing answer engines or the buyer-side procurement agents inside your prospects' companies. GEO money is real because it answers a question every vendor already has: does an AI system, asked about my category, say my name accurately, or does it hallucinate my competitor's pricing into my slot. Verified-claims infrastructure is the underbuilt half of that same question: once you're mentioned, can a buying agent check what was said about you without a phone call — and will it trust the answer enough to shortlist you.
What a Buying Agent Actually Needs Before It Trusts You
Here is the mechanic underneath "software hires software," made concrete for procurement.
A human buyer on a vendor shortlist tolerates ambiguity because a human can ask a follow-up question, read tone, and build trust across a sales cycle. A buying agent doesn't get that luxury, and — more importantly — it isn't supposed to. Its whole value proposition to the human who deployed it is that it can shortlist, compare, and draft a recommendation without a six-week discovery process. That only works if the facts it's comparing are structured well enough to be checked mechanically rather than taken on faith. This is the Vendor Handshake in practice, and it has a fairly specific shopping list:
Signed specifications, not marketing copy — a machine-readable data sheet with a cryptographic signature tying the claim to the entity that made it and the date it was made, the B2B equivalent of the structured catalog data Shopify's own numbers show converting twice as well as scraped pages 9.
Security and compliance attestations exposed at a well-known, machine-queryable endpoint rather than buried in a PDF a salesperson emails after a discovery call — SOC 2 status, data residency, uptime history, the answers that used to live inside a security questionnaire a human filled out under deadline pressure.
Pricing and contract terms a buying agent can evaluate against its mandate without a call — not necessarily public list pricing, but structured enough that an agent operating inside a spend policy can determine fit or disqualification on its own, the same way Google's AP2 turns a consumer purchase into signed Intent, Cart, and Payment mandates precisely so a dispute can be resolved by checking a record instead of re-litigating a conversation 2.
A verification path that doesn't depend on the vendor's own say-so — third-party attestation, audit trail, or a protocol-level signature the buying agent's infrastructure can validate independently, the same trust-before-transaction logic Visa built into the Trusted Agent Protocol so a merchant can confirm an agent's identity before anything moves 1.
None of this requires a proprietary interface. MCP and A2A are Linux Foundation projects now, governed the way Kubernetes is governed, specifically so no single vendor can lock up the pipes 5 6. A vendor exposing an agent-readable endpoint next quarter is describing table stakes, exactly as the opening chapter of this book warns about any "we'll expose an agent interface" roadmap line. The differentiation was never going to be in having a feed. It's in whether anything you put on the feed can survive being checked.
That's the domain-specific version of the Mandate Boundary this book keeps returning to. In procurement, the Mandate Boundary sits at the shortlist and the RFP response: a buying agent may gather, compare, and rank vendor claims unaccompanied, but the moment those claims translate into a signed commitment — a contract, a purchase order, a vendor relationship a company will depend on for years — a human still has to countersign, because nothing about a well-formatted claims feed changes who absorbs the consequence if the claims were wrong.
Procurement: what to build in 2027 vs. what to position for in 2030.The Moat, Applied to the Loading Dock
MCP and A2A being free protocols means the interface was never the business. The three things that were always going to be the business, applied to procurement specifically:
Verified facts with provenance. Not a spec sheet a vendor wrote about itself, but a claim with an evidence trail attached permanently — which security audit, which pricing tier, which compliance certification, issued by whom, verifiable independently of the vendor repeating it. This is what a verified-claims feed actually is, once you strip the GEO branding off it: provenance infrastructure for B2B facts, built the same way facts infrastructure gets built in every other chapter of this book — boring, expensive, and exactly why it's defensible once built.
Warranted outcomes. The uncomfortable question a claims feed has to answer eventually: what does the vendor stake on the claim being accurate? A spec sheet with no consequence attached is marketing. A spec sheet a vendor is willing to warrant — refund the deal, cover a security incident, eat a penalty if the attestation was stale or wrong — is infrastructure a buying agent's operator can actually rely on, because the agent's mandate can now price the risk of being wrong instead of just trusting the claim. This is the same distinction the opening chapter draws between a vendor who tells you a decision and one who has priced being wrong into the product.
Accountable judgment. When a buying agent shortlists a vendor off a bad claim and the resulting purchase goes badly, who answers for it? Not the model — the model can't be fired, sued, or held to a contract. The answer has to be a specific, named party: the vendor that signed the attestation, the procurement lead who countersigned the mandate at the Mandate Boundary, or — increasingly, this is the actual product opportunity — a third-party verification provider whose entire business is standing behind the claim so that both sides of the transaction can point to a name when something breaks. That is a genuinely new role in the B2B stack, and right now almost nobody occupies it cleanly.
A shortlist an agent can generate in ten seconds is worth nothing to a buyer who still has to spend six weeks finding out whether any of it was true.
That's the gap the current wave of GEO tooling doesn't close, because tracking whether you're mentioned accurately is a monitoring product, not a trust product. The vendors who win the next stretch of this build will be the ones who stopped asking "are we visible to the agent" and started asking "can the agent verify us without calling us" — and then went and built the warranty behind the answer.
What to build, and how to charge for it
Run procurement's version of the moat through Chapter 0's menu and four concrete products fall out, not just a direction.
A verified-claims feed — the signed specs, attestations, and pricing this chapter has already described — is naturally a tiered subscription: a base tier covering a fixed claim set and a modest number of agent verification pulls per month, a higher tier unlocking more claim categories (security, compliance, custom pricing) and a higher rate limit on how many times a buying agent can query it, because the vendor's real cost scales with verification volume, not with having claims at all. Layer a metered verification fee on top for agents outside a buyer's existing subscription — a pay-per-check option for the long tail of buying agents a vendor has no standing relationship with.
An agent-readiness audit — bringing a vendor's product feed and well-known endpoints up to a standard a buying agent can actually parse — is a clean one-time integration fee, priced like a security audit, with an optional ongoing monitoring subscription for vendors who want to be re-certified as protocols evolve.
The third-party verification and warranty role this chapter identifies as a genuinely open position in the stack is where outcome-warranted pricing belongs: a per-claim or per-deal verification fee that scales with the value of the transaction it's underwriting, with a real payout if a claim the verifier certified turns out to be false. That is a materially different — and larger — business than selling access to a claims database, for the same reason an insurance premium is worth more than a subscription to weather data.
And the 2030 buyer-agent RFP responder this chapter already prices per qualified opportunity is outcome-warranted pricing taken to its logical endpoint: a vendor pays only when its agent's answers actually advanced a real deal, which is the only pricing model a buyer will accept for a system negotiating on their behalf without supervision.
2030: When the RFP Answers Itself
Here the evidence runs out and the extrapolation starts, so treat what follows as informed positioning, not a forecast with sources behind it.
The plausible next stage, if the Vendor Handshake becomes standard infrastructure the way TLS became standard infrastructure for web traffic, is a buyer-side procurement agent that doesn't just shortlist vendors — it drafts and negotiates the RFP response itself, querying vendor agents directly over A2A for warranted answers to security questionnaires, SLA terms, and pricing tiers, priced by the vendor per qualified opportunity rather than per lead 6. That's a genuinely different shape of GTM motion: instead of a vendor's sales team chasing a signal that a company is "in-market," a vendor's agent is fielding structured, machine-generated RFP queries around the clock and only escalating to a human seller when a deal clears a threshold worth a human's time.
The harder version of this — a standing procurement mandate, re-evaluated continuously as a vendor's certifications, pricing, or security posture changes, the way this book's mortgage chapter describes an "always pre-approved" borrower — is a plausible 2030 pattern for repeat, low-variance B2B purchases: consumables, commodity SaaS seats, routine service renewals. It is not plausible yet for anything with real switching cost or real risk, for the same reason full agentic checkout stalled in retail: the price of being wrong is still higher than the trust that's been built to be delegated. This is my inference from where the infrastructure is heading, not a sourced benchmark — nobody has shipped a standing B2B procurement mandate at scale yet, and the regulatory and contractual questions underneath one (who's bound, under what authority, revocable how fast) are further from settled than the payment rails are.
What's worth building toward now, regardless of exactly when 2030 arrives, is the accountability relationship a standing mandate would require: a named party who can be pointed to when a vendor's claim turns out to be stale or a purchase goes wrong. That relationship is worth building years before the protocol matures, because it's the part that doesn't get thrown away if the specific 2030 pattern turns out wrong and something else wins instead.
Procurement was never really a question of who gets to shop. It was always a question of who gets to spend the company's money and who answers for it after. The next place that question shows up, in a more literal form, is the wallet itself — which is exactly where this book goes next.
The Algorithmic Wallet
A corporate card used to need a person to swipe it. By 2027 it mostly needs a policy instead — and the fight over who writes that policy, not who processes the swipe, is where the actual money in this chapter is.
Call the thing the policy governs the Policy Wallet: not an account a human authorizes one purchase at a time, but a standing set of conditions — vendor, category, price band, cadence, counterparty — that a piece of software checks against every attempted payment and either honors or blocks, with nobody awake to watch it happen. The Policy Wallet is the Mandate Boundary from Chapter 1 poured into a specific, cash-shaped mold. Every mandate protocol shipped in the last eighteen months — Mastercard's Agentic Tokens, Visa's Trusted Agent Protocol, Google's AP2 — is a machine for drawing that boundary around money specifically: what an agent may spend, on what, before a human has to look at it again. The protocols answer how a payment gets authorized. They do not answer what the policy should say, who is on the hook when the policy is wrong, or how a bank proves any of it to a regulator eighteen months later. That gap is the whole chapter.
The rails are done. Compete somewhere else.
Start with what's no longer in question, because treating it as an open competitive space is the fastest way to waste a 2027 budget.
Mastercard announced Agent Pay in April 2025 — Agentic Tokens that bind a card to a specific agent, merchant, and consent policy, built on the same Mastercard Digital Enablement Service tokenization that already powers Apple Pay and Google Pay 1. Visa's Trusted Agent Protocol followed that October, giving merchants a way to verify an agent's identity before checkout rather than guess whether it's a bot 1. Both networks have since moved from announcement to production. Mastercard says the first fully autonomous agentic payment — an AI agent booking a ride through a mobility provider called Hoppa, authenticated by DBS Bank with no human confirming at the point of sale — happened in Singapore on March 4, 2026, and in June 2026 the company launched Agent Pay for Machines with more than thirty partners spanning cards, bank accounts, and stablecoins on one settlement layer 11. Visa, meanwhile, struck a partnership with OpenAI the same month to embed tokenized Visa credentials directly into agent-initiated checkout inside ChatGPT and Codex, with spending limits, merchant categories, and required-approval rules enforced at the network level 12. And in May 2026, Google donated AP2 itself to the FIDO Alliance, alongside a Mastercard-built companion standard called Verifiable Intent, with new FIDO working groups on agentic authentication and agentic payments now chaired jointly by Mastercard, Visa, Google, OpenAI, and Amazon 13.
Three competitors who spent decades fighting each other for interchange share converged on overlapping, interoperable standards for machine-initiated payments inside about thirteen months, and then handed the governance of those standards to a neutral standards body so no single one of them could own it outright. That is not a market with room for a new entrant building "a payment rail for agents." That market closed before most product teams finished their first planning cycle on the topic. If a line item on your 2027 roadmap is infrastructure that competes with Agent Pay, TAP, or AP2 directly, kill it now and redeploy the budget.
The opportunity that survives this consolidation sits one layer up, exactly where Chapter 1 said the moat would be once a protocol goes free: the policy semantics layer that decides what a Policy Wallet is actually allowed to do, and the evidence layer that proves who's really on the other end of the transaction. Neither Mastercard nor Visa nor Google is in the business of encoding your specific procurement rules — "this agent may reorder consumables within five percent of contract price, from this vendor list, capped at this monthly ceiling" — into an enforceable Intent Mandate. Somebody has to compile that policy, in that specificity, and somebody has to package the KYC/KYB evidence that proves the counterparty accepting the payment is who and what it claims to be, especially when the counterparty is itself software. That compiling and packaging work is unglamorous, vertical-specific, and exactly the kind of boring infrastructure that compounds instead of getting commoditized by the next protocol release.
It also happens to be the work a CFO actually needs done before any of this touches a real treasury account. No finance leader signs off on a Policy Wallet because the rails are elegant. They sign off when three specific questions have answers they can put in a board deck: what, precisely, is this agent allowed to do without me; what happens to the money if that policy gets exploited or simply misfires; and can I explain the wallet's behavior to an auditor, a regulator, or a plaintiff's lawyer without pointing at a model and shrugging. Those three questions are, not coincidentally, Chapter 1's moat restated as a procurement checklist — evidence, warranty, explainability — and they are the actual gate between "we piloted an agentic payments demo" and "we let it move real money unattended." The rest of this chapter is about what has to exist on each side of that gate.
When the vendor on the other end is also a wallet
Here is the part that changes the shape of the problem rather than just its scale. Everything so far describes one agent — a shopping assistant, a procurement bot — transacting against a human-run business. That's the easy half. Mastercard built Agent Pay for Machines specifically for the other half: machine-to-machine commerce, where an IoT sensor pays per API call, a logistics agent pays a warehousing agent for storage by the hour, and neither side of the transaction has a person checking a dashboard 11. When the payer's wallet and the vendor's invoicing system are both agent-operated, "software hires software" stops being a checkout-page feature and becomes the entire commercial relationship.
That reshapes KYC and KYB, because the question is no longer just "is this business real." It's "which specific agent is acting, under whose authority, with what spending limit, and can that be proven independently of the agent's own say-so." An emerging shorthand for this — Know Your Agent — is circulating among identity vendors and standards groups as of 2026: the idea that every acting agent needs to be cryptographically bound to a verified human or business principal, with its permission scope machine-readable and its behavior auditable over time 14. Treat that framing as directional rather than settled; there is no single regulator-blessed KYA standard the way there is a chartered bank behind KYC. But the underlying problem it's naming is real and it's exactly the one a Policy Wallet has to solve before a CFO will let it run unattended: prove not just that the vendor exists, but that the specific piece of software claiming to represent the vendor was actually authorized to send that invoice.
This creates a specific failure mode. In a human-to-business transaction, a confused or malicious counterparty eventually runs into a person who notices something is off — a purchasing manager who flags an unusual invoice, a customer who disputes a charge. In an agent-to-agent transaction, that noticing has to be engineered in deliberately, because by default nobody is watching. Whichever side of the transaction is holding the better evidence trail — the more complete, better-provenanced record of what was authorized, by whom, under what policy — wins the dispute when it eventually happens, whether that dispute plays out as a chargeback, an audit finding, or a lawsuit. That is the KYC/KYB evidence packager business in one sentence: sell the receipts that make a machine-to-machine dispute resolvable by something other than "our agent said your agent said."
The moat, in wallet terms
Chapter 1's three-part moat — verified facts with provenance, warranted outcomes, accountable judgment — translates into this domain almost without modification, which is a good sign that it's the right framework rather than a slogan.
Verified facts with provenance is literally the KYC/KYB evidence trail, and the infrastructure to generate it is arriving on a hard regulatory clock rather than a product roadmap. Under the EU's eIDAS 2.0 regulation, banks, insurers, and payment providers must accept the EU Digital Identity Wallet as an authentication method for onboarding and strong customer authentication by December 2027, with each member state required to have at least one government-issued wallet live a year earlier 15. That deadline is real, but the rollout underneath it is not going smoothly — reporting as of September 2026 describes the wallet stalling in roughly two dozen member states even as the regulatory clock keeps running — a reason not to bet a 2030 plan on flawless infrastructure arriving on schedule 15. India is running a parallel experiment with a different mechanism: the DPDP Act's Consent Manager framework goes live on November 13, 2026, formalizing the licensed-broker model that the country's Account Aggregator network has been operating since 2021, where a regulated consent manager moves encrypted financial data between institutions without ever holding the decryption key itself 16. As of late 2025, seventeen licensed Account Aggregators connect more than 135 financial information providers, with roughly 38 percent of borrowers reportedly enabled on the network — figures worth treating as directional, since they come from industry secondary sources rather than the regulator itself 17. Both systems are, underneath the acronyms, the same idea: a verifiable, consent-scoped, revocable evidence trail attached to a financial fact, which is precisely what a KYC/KYB evidence packager needs as raw material.
Warranted outcomes is where this domain gets genuinely uncomfortable, because nobody has actually settled who pays when a Policy Wallet gets it wrong. Agentic payments break the assumption baked into decades of consumer-protection law that a transaction has one clean moment of authorization by one identifiable person. Under Regulation E in the US, a transfer is generally presumed authorized once a consumer hands credentials to an agent, even if that agent then acts outside what the consumer actually intended — which means the consumer-protection backstop that would normally absorb a bad agent decision may simply not apply 18. Legal analysis of the current wave of agent payment tools is blunt about the state of play: the question of who absorbs the loss — the person who authorized the agent, the developer who built it, or the merchant who received the funds — will likely be settled by whoever litigates first, and no company wants to be that test case 18. That uncertainty is not a reason to wait. It's the actual product opportunity. A mandate policy engine that merely executes a rule is a feature. A mandate policy engine backed by a warranty — a vendor who prices, underwrites, and stands behind the accuracy of its own policy enforcement — is a business, for the same reason an insurer is a business and a weather app is not.
Accountable judgment has the sharpest edge of the three, because it's not really a business risk here — it's a legal wall. The CFPB's 2022 guidance established that a lender cannot use a credit-decision model too opaque to produce specific, accurate reasons for turning someone down; "the black box told us to" is not, and has never been, an acceptable adverse-action notice under the Equal Credit Opportunity Act and Regulation B 19. In May 2025, the CFPB withdrew that guidance along with dozens of other interpretive documents as part of a broader deregulatory push 19. That withdrawal did not repeal ECOA or Regulation B — the statute is still the statute, and a creditor still has to produce specific, accurate reasons for a denial or face liability under the underlying law, guidance or no guidance. If anything, the withdrawal makes the constraint sharper for a builder, not softer: the safe harbor of clear agency guidance is gone, and what's left is bare statutory exposure that gets tested in court rather than pre-cleared by a regulator. This is exactly why SMB cash-flow underwriting built from consented bank data with reason codes traceable to specific transactions is more defensible than a generic underwriting model wrapped in a chat interface. Explainability here is not a nice-to-have UX layer. It is the difference between a product a bank's counsel will approve and one they legally cannot.
Corporate wallets: rails standardize in 2026, policy layer builds in 2027, positioning for 2030.A wallet that can't explain why it said no isn't a product a bank can ship. It's a liability nobody has been sued over yet.
What to build, and how to charge for it
The Policy Wallet's economics split cleanly along Chapter 0's menu, and the split matters because pricing a mandate policy engine like a SaaS seat, instead of like an insurance product, is the fastest way to underprice the actual risk you're taking on.
A mandate policy engine — the compiled, enforceable version of "this agent may reorder consumables within five percent of contract price" — is sold as a tiered subscription per wallet or per policy ruleset, with the tier gating both the complexity of policy a customer can express and the transaction throughput the engine will authorize per hour, the same kind of rate-limited access-tier structure that governs how much a role can do in the mortgage chapter's product ladder. Layer a metered per-transaction fee on top for actual mandate checks executed above the tier's included volume, because the marginal cost of evaluating one more transaction is real and should be priced as such, separately from the fixed cost of having a policy engine at all.
A KYC/KYB evidence packager for agent and non-human counterparties is naturally metered per verified entity — a fee each time the packager stands up a fresh evidence bundle proving who's really on the other end of a payment — with a subscription tier for institutions verifying at high volume who want a predictable bill instead of a variable one.
SMB cash-flow underwriting facts, built from consented bank data with adverse-action-ready reason codes, is where outcome-warranted pricing belongs: charge per underwriting decision the facts actually support, with a defined liability position if a reason code turns out to be wrong or unsupportable under ECOA scrutiny — the same logic that makes a mortgage QC warranty worth more than a subscription to an extraction API.
And the connective tissue between all three — the one-time integration fee for actually plugging into a bank's core system, a payment network's mandate API, or an EUDI Wallet relying-party integration — is usually the hardest six weeks of the entire sale. Pricing it at zero to win the logo doesn't save the customer money. It just moves that cost from their budget onto yours.
2030: the financial passport, staged rather than scheduled
Treat everything in this section the way Chapter 1 insisted you treat any 2030 material: a plausible direction to position for, not a date to build against. Nothing below carries a citation, because nothing below has happened yet.
The building blocks are visibly assembling. A continuous, real-time audit — where a ledger is reconciled to source evidence constantly rather than sampled quarterly by a human auditor — becomes newly plausible once the underlying facts (bank transactions, invoices, payroll records) already carry the kind of provenance the EUDI Wallet and India's Account Aggregator network are built to produce. An auditor who currently samples a few hundred transactions and extrapolates could instead consume a standing feed of attestations and only intervene on exceptions. That is a genuine step change in how assurance work gets done, and it points to a live 2030 opportunity: sell the attestation layer, not th...
