Who Holds the Keys to the Agent Web - Part 2: Who Gets the Receipt
The agent commerce infrastructure is being built right now. Payment rails, discovery protocols, trust registries, autonomous wallets, all the systems that will let agents find services, evaluate offers, and spend money on your behalf are already shipping. But no mechanism exists for an agent to verify that what it is being sold is real. No format lets a business declare which agent endpoints are authorised to act on its behalf. No consumer interface shows a human what their agent is about to spend before it spends it. The potential capture this time is about transactions, trust, and the reasoning traces that accumulate when agents do the work. And could become the most detailed map of your economic life that has ever existed.
In Part 1 of this series, I argued that authentication is where the open agent web closes first. Agents need credentials to act on your behalf, to check your email, file your tickets, commit your code. Whoever manages those credentials sees the graph of everything your agent touches. Identity vendors are building that management layer now, positioning themselves as the invisible intermediary between your agent and every service it reaches. The alternative, a local broker you control, like a password manager for agent permissions, currently exists in pieces but not as an assembled product. And the window to build it is narrowing.
Part 2 follows the money. What happens when agents stop acting on systems built for humans and start negotiating directly with each other? The capture is no longer about what your agent is permitted to do but what your agent actually does, what it buys, who it trusts, and who keeps the record.
"Book me the cheapest flight to Thessaloniki that gets me back by Sunday." Today that is a query to a booking website. Your agent navigates the same interface you would. It clicks through the website, scrolls through the offerings, selects the best offer from the list on the page. But this familiar interface is expensive, it was designed for a human who browses, compares, abandons, and comes back.
But when the agent can get the price directly from the airline's agent, the booking interface becomes unnecessary. The airline still exists, the flight still exists and the transaction still happens. But the system a person was meant to click through does not. Even the backend for it is slimmed to a few components. Your agent contacts the relevant airline agents, negotiates with them, picks the most suitable offer, closes it and pays. All in just a couple of seconds.
I need to be honest about what kind of territory this is. What I describe here is something that is still forming, its full shape still unknown, we can only see shadows and silhouettes of it in the distance. Agents with their own wallets executing millions of transactions, micropayment rails with nearly a thousand live endpoints, paid tool servers generating real revenue, all these are things that are already emerging. But other pieces exist only as proposals, benchmarks, or thought experiments. The assembled system, agents autonomously discovering services, evaluating trust, negotiating terms, and carrying the receipts forward, does not exist yet. And with the current models, it cannot exist. Language models hallucinate, collude without being instructed to, fall for prompt injection, and negotiate irrationally. What is being built now is the infrastructure that will be ready when the models mature enough to use it.
The reason to pay attention now is that the capture mechanisms are being built before the system arrives. That is the pattern from Part 1. OAuth was designed for humans clicking consent screens. By the time agents needed auth, the infrastructure had already hardened around assumptions that did not fit. The same thing is happening now with payments, trust, and commerce, except faster, because the people building it learned from the last round. And in some cases, they are not building capture deliberately, they are just building a useful infrastructure that can become a capture mechanism by default, because no one builds the open alternative at the same layer.
How agents find each other
Before an agent can pay for a service, negotiate terms, or evaluate trust, it has to find the service. This is the discovery problem, and it is more broken than anything else in the agent commerce stack.
Every major discovery mechanism proposed or deployed today shares the same limitation: the agent must already know where to look.
Google's A2A protocol has agents publish AgentCards, JSON documents at a well-known URL describing the agent's identity, capabilities, and security requirements. In tutorials and demos, agents are given peer URLs through configuration files or environment variables, then fetch the AgentCard from that known endpoint. No global registry of AgentCards exists and the spec suggests "Open Discovery" and "Registry-Based Discovery" as future directions. But today, developers have to manually configure the list of agent endpoints.
Google's Universal Commerce Protocol puts a JSON manifest at /.well-known/ucp on merchant domains listing services, capabilities, payment handlers. Shopify auto-generates these for stores that enable Agentic Storefronts. Boden and Coffee Circle have live manifests. But the agent only finds the manifest after it already has the domain. As Google's own documentation describes the flow: "when an AI agent encounters a merchant's domain, it requests this file."
For MCP servers, the tool endpoints that agents call , two de facto directories have emerged. The official MCP Registry at modelcontextprotocol.io holds server metadata in JSON records: name, installation instructions, invocation details. The Smithery.ai platform functions as a marketplace and distribution gateway, cataloguing servers with public pages and connection APIs. Both are centralised catalogues that developers browse and neither is a protocol an agent uses to discover tools autonomously.
The actual discovery flow for an agent today, if it needs a service it has never used, is this: search the web the way a human would. Identify a domain from the results. Check whether that domain publishes anything at a well-known path, an AgentCard, a UCP manifest, an agents.txt, or an agents.json. Most do not, so the agent falls back to parsing HTML, reading documentation, or calling APIs that were designed for human developers to configure manually.
This is the RSS problem before RSS existed. The content was there in the form of thousands of blogs publishing updates, but there was no feed format, no subscription mechanism, no aggregation layer. The content was discoverable only if you already knew where it was. RSS solved this by creating a format simple enough that any software could read it and a convention clear enough that any publisher could implement it. The agent discovery layer has not found its RSS yet.
Several proposals are reaching for it. At least four competing agents.txt and agents.json specifications exist. None has achieved meaningful adoption and the more ambitious efforts are further along. The Agent Name Service, now an IETF Internet Draft with OWASP backing and a GoDaddy production deployment, defines a DNS-inspired directory using PKI-based authentication. The Agent Directory Service, also an IETF draft, uses a distributed hash table with cryptographic provenance and has working implementations with SDKs in three languages. Both ANS and ADS solve capability discovery, but the governance questions that matter most (name allocation, dispute resolution, root authority trust) remain explicitly deferred to future work in both specs.
The structural pattern from Part 1 applies. The centralised option, platform registries, curated directories is being built and is partially live. AWS Marketplace, Salesforce AgentExchange, Smithery. The decentralised option is proposed but not yet shipping. The default is forming around the centralised version, because that ships first.
Whoever controls the directory through which agents discover services controls what agents can find. That is a discovery graph, the map of what services exist in the agent economy. If that map is a platform catalogue, the platform decides what is listed. If it is an open convention at a well-known URL, anyone can publish and anyone can read.
And there is a secondary problem layered on top of the protocol gap. Even where agent-readable formats exist, publishing them requires infrastructure that not every business has. Shopify launched Agentic Storefronts in early 2026 as a single toggle in the merchant admin that publishes the store's product catalogue, pricing, and return policies in a format AI shopping agents can read. For Shopify merchants, agent commerce is a settings change. For everyone else, the restaurant without a website, the independent broker running on email and spreadsheets, the sole trader who sells through Instagram, there is no equivalent. Building an AgentCard or MCP endpoint from scratch takes weeks of developer time for a basic connector, months for complex integrations. Supporting payment protocols means integrating specialised APIs. The result is a discovery divide: businesses with modern e-commerce stacks appear in agents' results, and businesses without them do not exist. Agent commerce deepens the digital divide, because the penalty for being machine-unreadable is total invisibility.
How agents evaluate before transacting
Discovery is only the first problem. Even if your agent finds the airline's agent, it faces a question that human commerce solved long ago and agent commerce has not begun to address: is this offer worth accepting?
When a human shops online, trust is layered. Reviews and star ratings from previous buyers. Brand recognition built over years. Return policies printed on the checkout page. Payment protection from the credit card network. Consumer protection law as the backstop. Each layer is imperfect but together they create enough confidence to enter a transaction with a stranger.
Agents have none of these layers. There is no agent equivalent of reviews. No machine-readable rating schema an agent can query before transacting. Some blockchain projects are building toward this, AgentRadar, the Intuition protocol, but these are pre-release and limited to crypto-native contexts.
There is no standard for machine-readable commercial terms or SLAs. No deployed format where a service publishes its pricing, refund policy, liability limits, or uptime guarantees in a structure an agent can evaluate before committing. Google's UCP publishes checkout capabilities and payment handlers but not refund policies, SLAs or liability terms. The Stanford CodeX centre has published the clearest articulation of what this should look like, standardised transactional terms analogous to Creative Commons licences. The only working example is HederaToolbox, a single MCP server that publishes a terms.json file agents must acknowledge before proceeding. That is the state of machine-readable commercial terms for agents in March 2026.
There is no verification mechanism before payment. When a human buys from an unknown seller, the payment network provides a backstop with chargebacks, fraud protection and dispute resolution. When an agent transacts right now no equivalent exists. A few blockchain protocols attempt conditional payment: ERC-8183 defines smart contract escrow where funds lock until an evaluator confirms delivery. Aegis Protocol offers multi-tier dispute resolution for AI contracts. LOBSTR proposes escrow with a review panel. But all of them are experimental and none is deployed at scale. For the vast majority of agent transactions today, the agent must assume the service delivers what it promises.
And when it does not deliver, there is no recourse designed for agents. There is no agent-specific chargeback protocol, no arbitration mechanism and no clear legal standing for agents in transactions, the question of whether the user or the agent is the consumer is unsettled in every jurisdiction. Chargebackgurus, a payments industry consultancy, warns that agent commerce will increase disputes because agents will make purchases the user did not intend. The existing human dispute infrastructure (the credit card chargebacks, the platform refund policies, the current consumer protection law) was not designed for transactions initiated by autonomous software and may not apply cleanly.
And beneath all of these missing layers like the the reviews, the terms, the SLAs, the verification, the recourse there is a more fundamental gap. Every evaluation assumes the service is real. But how does the agent know that?
When your agent encounters an endpoint that says it sells Aegean Airlines tickets, it faces a question that the entire agent commerce stack has not answered: is this endpoint actually authorised by Aegean Airlines?
This is not the identity problem. The Cryptographic identity (DIDs, ERC-8004, Visa's Trusted Agent Protocol) proves that an agent is a persistent entity with a consistent key pair. But it does not prove that the entity has any relationship with the airline whose tickets it claims to sell. And it is not the reputation problem. On-chain feedback from other agents means other agents believe they got what they paid for but It does not mean a licensed airline actually issued a real ticket.
In human commerce, this question is answered by a stack of institutions you never think about. When you buy on aegeanair.com, trust comes from the TLS certificate issued by a certificate authority that verified the domain owner. The domain is registered to Aegean Airlines S.A. ICANN governs the domain registry. The airline is licensed by the Hellenic Civil Aviation Authority. IATA accredits it internationally. The payment processor is regulated by the central bank. Consumer protection law backstops the whole chain. This is eight institutional layers, built over decades, that together let you click "buy" with reasonable confidence that a plane ticket will follow.
For agents, none of these layers have machine-readable equivalents. No format exists for a business to publish a verifiable, machine-readable claim about which agent endpoints are authorised to act on its behalf. AgentCards are self-attested, the agent wrote its own description. UCP manifests describe capabilities but not authorisation chains. The various agents.json proposals address discovery but not the question of "authorised by whom."
The closest thing to a solution is the IETF's Agent Identity and Discovery draft from March 2026, which specifies that a domain owner publishes agent endpoints in a DNS TXT record , which is structurally the same pattern as SPF for email authentication. A business declares its official endpoints; any agent can verify by checking the business's domain. The problem is that AID stops at discovery: "these are our endpoints." It does not address authorisation: "these endpoints are authorised to sell tickets on our behalf, with this scope, until this date." The difference between listing an endpoint and attesting commercial authority is the difference between a phone directory and a power of attorney.
A few prototypes reach further. The Retail Model Context Protocol illustrates a Verifiable Credential where a retailer issues a signed "ShoppingAuthorization" to an agent, listing permitted actions (purchase, view orders) that a buyer's agent can cryptographically verify. Prove's Verified Agent service issues signed credentials linking agents to real identities. But these are isolated examples, no open specification defines what an agent authorisation credential should contain, who should issue it, how it should be verified, or how it should be revoked.
The reseller chain makes it harder. If Aegean authorises TravelAgency.com to sell its tickets, and TravelAgency.com runs the agent endpoint, a buying agent needs to verify two links: that TravelAgency.com is authorised by Aegean, and that this specific endpoint is authorised by TravelAgency.com. No protocol, standard, or even proposal addresses multi-hop commercial delegation for agents. The Verifiable Credentials model could express it through a chain of signed attestations from principal to reseller to endpoint. But no one has built it.
The technical architecture for solving this is not exotic. The building blocks exist: DNS records for publication, HTTPS for origin verification, signed credentials for delegation, well-known URIs for standardised discovery. What is missing is the boring institutional plumbing, things like the agreed formats, the shared verification policies, the governance of who decides what counts as sufficient proof. And that is where the capture risk lives. Because the entity that defines the default verification policy, which attestations agents should accept, which registries they should check, which credentials count as legitimate , controls what agents consider trustworthy. That is a legitimacy graph: the map of who is allowed to participate in agent commerce at all.
The absence of this layer is a structural gap that makes everything else fragile. Payment rails can move money between agents and trust registries can verify identity. But without machine-readable terms, agents cannot comparison-shop. Without verification, they cannot distinguish legitimate services from fraud. And without dispute resolution, they cannot recover from failures.
If the evaluation layer eventually requires human judgment then it inherits every failure mode of existing human evaluation systems, accelerated. Fake reviews are already a multi-billion-dollar industry targeting human readers. Review bombing already destroys businesses on Google Maps overnight. SEO farms already game search rankings to make fraudulent sites appear legitimate. Astroturfing on Reddit already manufactures consensus that does not exist. These are manipulation systems built for human audiences. When the audience is an agent parsing structured data, the same techniques apply but faster and at larger scale and they are harder to detect, because an agent has no intuition, no sense that "this feels off," or ability to notice that five hundred five-star reviews were posted from the same IP range on the same Tuesday afternoon.
The manipulation surface extends to every layer an agent reads. Keysight's security team demonstrated that adversarial instructions embedded in an A2A AgentCard , the JSON metadata describing an agent's capabilities , can trick a host LLM into executing unintended actions, including data exfiltration. Princeton researchers showed that injecting fake data into an agent's memory or information sources can trick it into purchasing overvalued items. Microsoft Research found that simulated shopping agents were easily duped by fake reviews and persuasive claims, frequently selecting fraudulent listings and in one case directing payment to the wrong merchant entirely. A security firm built a test site that showed human browsers a normal designer portfolio while serving AI agents a doctored version calling the same person a "notorious product saboteur" and the AI confidently repeated the fabrication. A researcher demonstrated in March 2026 that a single hidden HTML element on a product page, invisible to human browsers but visible to LLM scrapers, is enough to feed an agent a false price. He tested ten hiding techniques across Claude and GPT models and all of them fell for the same tricks. These are not proofs of concept confined to laboratories. Dataprovider's analysis of thousands of live websites found multiple businesses already embedding hidden instructions designed to influence AI-generated reviews and summaries placed on real product pages, restaurant listings and professional portfolios. The manipulation infrastructure that took twenty years to build for human-facing search engines is being adapted for agent-facing commerce in months.
And the capture implication compounds. If the evaluation layer is a platform service like a curated directory that rates and reviews and guarantees the services it lists, then the platform controls what agents consider trustworthy. If it is an open standard, the standard must solve the manipulation problem or it will be gamed from day one. The history of how this has gone in the past, from Google's twenty-year war against SEO manipulation to Yelp's ongoing struggle with fake reviews to Amazon's estimated thirty to forty percent counterfeit review rate on some product categories, does not encourage optimism. Every human evaluation system that achieved scale was gamed at scale. And the agent evaluation systems will not be exempt. The only question is whether the gaming targets a platform gatekeeper or an open protocol and which of those is easier to defend.
How agents pay each other
The HTTP specification has included status code 402 (Payment Required) since 1997. For nearly thirty years it sat unused but in 2025 and 2026, two competing protocols activated it for its original purpose. When an agent requests a paid resource, the server responds with 402 and a payment challenge. The agent pays and retries and the server delivers. There is no need for account creation, checkout page, of a human in the loop.
Stripe's Machine Payments Protocol and the x402 standard which were launched by Coinbase and are now governed by a foundation that includes Cloudflare, Google, and Visa, both use this handshake
MPP runs through Stripe. It works by having the agent authorise a spending session and stream micropayments against it. For conventional payment rails, Stripe offers Shared Payment Tokens. The agent generates a time-limited token that lets a merchant charge its stored payment method without seeing the card number. The merchant just sees a normal Stripe transaction. Over a hundred businesses onboarded at launch. Stripe supports both MPP and x402 in its Agentic Commerce Suite and Google backs x402 through its Agent Payments Protocol. Visa and Mastercard are positioning their own agent payment layers. It does not matter which protocol wins, what matters is that the settlement layer sees the transaction and the entities building that layer are the largest payment networks in the world.
x402 is permissionless. Anyone can run a facilitator and it works with any EVM-compatible token on any chain. Coinbase launched the protocol in May 2025; by late 2025 the x402 Foundation included Cloudflare, Google, and Visa. Google integrated x402 into its Agent Payments Protocol. Stripe launched x402 support in February 2026. The services using it range from QuickNode offering pay-per-request blockchain access to indie operations charging a cent per API call. The boundary between genuine commerce and gamified testing in x402's early ecosystem is unclear. But the infrastructure is production-grade, it has substantial institutional backing and it is actually running.
The structural parallel to Part 1 is obvious. MPP is the cloud identity vendor of payments positioning Stripe as the entity between every agent and every service it pays. x402 is the local delegation broker, it is permissionless and operationally harder. And here is what the payment processor sees that the identity vendor does not. The authority graph from Part 1 maps what your agent is permitted to do. The commercial graph maps what your agent actually does, what it bought, from whom, how often, in what pattern. Whoever settles agent transactions at scale owns the most detailed map of the agent economy that exists.
The oversight infrastructure exists in pieces, but only as developer tools. Stripe's Agentic Commerce Suite generates one-time virtual cards for agent purchases, with configurable fraud controls and webhooks that can pause a transaction for review. Coinbase's Agentic Wallets provide per-session and per-transaction spending caps, destination whitelists, and a developer portal showing agent activity. Both are built for engineers configuring guardrails in code but neither is a consumer product. No mainstream notification app exists where a human sees what their agent is about to spend and approves or rejects it before the transaction completes. The human approval interface for agent commerce, the equivalent of "confirm purchase" on a checkout page, has not been built yet.
The consequences of all this are already visible in anecdotes. A SaaS founder reported that an autonomous agent spent eight thousand dollars on two online courses The agent just decided the content was "helpful" and executed the purchase using a saved payment card. There was no two-factor authentication or human approval step. The founder now builds payment middleware with hard budget caps and isolated virtual cards, solving the problem the infrastructure did not. In a separate incident, an agent called Freysa was tricked by a prompt injection into sending forty-seven thousand dollars in ETH to an attacker. Gitcoin's Owockibot leaked its private key and lost twenty-one hundred dollars within minutes. Currently no aggregate statistics exist on agent spending errors. There is no reporting category for "my agent bought something I didn't intend," no agent-specific chargeback protocol or dispute mechanism that distinguishes between a human-authorised purchase and an agent-authorised purchase within delegated parameters. The incidents show up as Twitter anecdotes and Reddit complaints and the infrastructure to formally record and analyse them does not exist yet.
Visa launched a CLI tool for agents to initiate payments on its network and Mastercard introduced Verifiable Intent, a cryptographic record of the user's authorised instructions embedded in the transaction. Both are positioning for the same role, the layer that sees every agent transaction regardless of which protocol carries it.
Agents with wallets
The payment protocols above describe how money moves when a human delegates spending to an agent. But a separate development is agents that hold their own money.
And the distinction matters. In the Stripe model an agent spends through a delegated credential, the Shared Payment Token. The human sets a limit and the agent operates within it. The human remains the economic actor and the agent is the instrument.
On-chain, something different is happening. Olas, the agent monetisation platform, deploys agents that self-custody funds in Safe multisig wallets and make autonomous trading decisions. On Gnosis Chain, Olas agents account for a significant and growing share of all Safe transactions and on some days they are the majority, according to both Olas and Gnosis. The exact share varies by measurement period, but autonomous agents are already a major category of on-chain activity. Their newest agent, Polystrat, trades autonomously on Polymarket around the clock with over four thousand trades in its first month. More than a third of its users reported positive returns, in a market where historical data suggests only seven to thirteen percent of human traders do.
And the frameworks are proliferating. Coinbase AgentKit provides over 50 action modules. Solana Agent Kit connects agents to 60 protocol actions. ElizaOS, with nearly 17,000 GitHub stars, ships a unified multi-chain wallet. Virtuals Protocol tokenises agents themselves and provides smart contract escrow for agent-to-agent transactions through a five-phase lifecycle (request, negotiation, escrow, evaluation, settlement).
Autonomous agent wallets are proven in the crypto-native ecosystem. Agents can hold funds, make spending decisions, and transact without per-transaction human approval. But this is not happening at the conventional e-commerce space like the airline booking layer of my example. Eventually the gap between where autonomous agent commerce exists and where most people expect it will close. The question is what infrastructure governs the crossing.
Nevertheless the capture question is the same. When an agent holds its wallet on a public blockchain, the transactions are visible to anyone who reads the chain. When an agent holds its wallet through a managed platform, the transactions are visible to the platform. The choice between on-chain autonomy and managed custody is the payment-layer version of Part 1's choice between the local broker and the cloud vendor.
The problem RSS never had, again
Part 1 described the authentication problem but agent-to-agent commerce has a different trust problem. When your agent negotiates with the airline's agent, there is no login page or existing OAuth flow. The question then is not "can this agent prove it has permission to act on a human's behalf." The question is "is this agent what it claims to be, and can it deliver what it is offering."
Today, the answer relies almost entirely on borrowed infrastructure. Google's A2A does not define a trust mechanism but assumes agents are already authenticated through existing enterprise systems. Agents trust each other the way web servers trust each other: TLS certificates validated against known certificate authorities. This works inside an enterprise but it does not work when your personal agent encounters an unknown agent from an unknown organisation offering a service for a price.
The absence of a trust layer is not theoretical. Moltbook, the agent social network Meta acquired in March had ninety-nine percent of its accounts fabricated by its own creators. In travel booking, eighty percent of AI bots interacting with booking sites do not honestly identify themselves. And prompt injection, the practice of adding malicious instructions hidden in content that override an agent's behaviour, is the direct attack on agent commerce. Mastercard's AI policy team has warned that a corrupted booking page could redirect an agent to transfer funds to a criminal's account.
The research is surfacing deeper problems. Stanford's NegotiationArena found that LLM agents boost outcomes by pretending to be desperate and exhibit the same cognitive biases as human negotiators. Multiple studies demonstrate that LLM agents spontaneously collude in market settings without being instructed to and prompt-based prohibitions on collusion do not work. Institutional governance reduced severe collusion from fifty percent to under six percent but did not eliminate it. Microsoft Research's Magentic Marketplace found that all models exhibit severe first-proposal bias, that speed beats quality by ten to thirty times, and that some models are completely compromised by manipulation attacks. Princeton researchers demonstrated that injecting misleading data into an agent's memory or social feed tricks it into purchasing overvalued items or leaking funds. It is the fake review problem but this time applied to agent cognition directly. And in February 2026, the Lazarus hacking group exploited a prompt injection to drain a hot wallet at Bitrefill. This was real a breach where an AI assistant was tricked into authorising a fund transfer to an attacker.
These are not failure modes that identity verification fixes or problems that better reputation systems solve. They are structural properties of how current language models behave in adversarial environments and commerce is an adversarial environment by default.
The emerging responses to this fall into two categories. The centralised response: Microsoft shipped Entra Agent ID for enterprise agents. Visa's Trusted Agent Protocol uses cryptographic signatures with hundreds of completed transactions. Mastercard's Verifiable Intent embeds authorisation proof in the transaction itself. These position their operators as the trust anchors, as essentially the entities that decide which agents are verified.
The decentralised response: ERC-8004 provides on-chain reputation that is public, permanent, and portable. Mnemom offers trust ratings using cryptographic attestation and zero-knowledge proofs without a public blockchain. Vouched's MCP-I extends the Model Context Protocol with W3C Decentralised Identifiers, donated to the Decentralised Identity Foundation as an open standard. AgentScore aggregates trust from multiple independent sources, penalising agents that exist on only one platform.
The parallel to Part 1 is again obvious. The centralised registries capture the graph of who trusts whom and the decentralised reputation makes that graph portable. In the end whichever system most agents check before transacting owns the trust layer.
And the deeper problems like collusion, manipulation or first-proposal bias are not addressed by either approach. They require market design, not identity infrastructure. That design work has barely begun.
The commercial graph
Part 1 described the authority graph, the map of what every agent is permitted to do across every service. Part 2 describes something larger.
The commercial graph is the authority graph plus the transaction history plus the legitimacy layer. It maps not just what your agent can access but what it actually bought, from whom, at what price, how it decided, and what it learned. It is the complete record of your agent's economic life.
The payment processor sees the transactions, the trust registry sees the reputation, the discovery platform sees what services exist and the verification layer sees who is allowed to sell. And beneath all of these, the entity that defines what counts as a verified, legitimate participant in agent commerce through a registry, a verification policy, a platform listing, sees who is allowed to sell at all. No single entity captures the whole graph today. But the infrastructure being built is the scaffolding for a system where the graph could be assembled by anyone positioned at enough intersections.
Stripe settles the payments and supports both competing protocols because it sees the commerce regardless of which standard wins. The trust registry tracks reputation, the discovery platform controls what agents can find and autopilot accumulates the decision traces. The cloud platform hosts the runtime, memory, and connections and each captures a slice. The entity that controls enough slices assembles the graph and the entity that can correlate across layers owns something none of the individual layers can see.
Transactions will be recorded, reputations will be tracked and decisions will leave traces. The counter-position is about where those records live and especially on everything that follows, the amendments, the disputes, the cancellations, the long-lived state of what was agreed and what changed.
If the transaction receipts live in a file you own, the payment processor sees the settlement but not the full history. If the reputation is portable, no single trust anchor controls legitimacy. And if the discovery layer is an open convention at a well-known URL, no platform controls what your agent can find.
Each of these is an architectural choice that is available now, at least in principle. None is the default.
The pattern from Part 1 holds at every layer. The open option exists and infrastructure for it is being built, in some cases by the same entities building the captured version. The question is which becomes the default before the system hardens.
I watched the open web get captured the first time through convenience. Then I watched the auth layer begin to close through security. Now the commerce layer is forming, and the capture mechanism is efficiency. It is simply easier to let the payment processor, the trust registry, and the autopilot service keep the records than to maintain them yourself.
But what is "easier" has a cost. The cost is legible in retrospect and invisible in the moment. That is how defaults work. That is why the moment to choose is now, while the infrastructure is still forming and the defaults are still soft.
The doors are still open. The people building the toll booths are moving fast. And this time, they are not just capturing what you read or who you follow or what you are allowed to do. They are capturing what you buy, who you trust, and who gets to sell.
But commerce is not a moment. It is a relationship with a lifespan. What happens when the flight is cancelled? When the terms change after the contract is signed? When the service delivers something different from what was promised? When a dispute arises and the agent that made the purchase no longer has the context of why it made that choice?
The post-transaction state all the amendments, the cancellations, the partial fulfillments, the warranty claims, the long-lived record of what was agreed and what actually happened, is where the most detailed capture occurs and where the fewest records exist. When the agent that bought the ticket is gone, the context window has closed and the reasoning that informed the decision has evaporated with the session, what remains is a line on a credit card statement and whatever the service provider chose to keep.
Whoever holds the canonical record of what was agreed, and what changed after, holds the most valuable layer of the commercial graph. But that is for Part 3.
Published: March 2026 · Author: Lida Liberopoulou · License: CC BY-SA 4.0