When consumers first wanted apps to see their bank accounts, the industry's answer was screen scraping. It was ugly. People handed their banking passwords to third parties, which logged in as them and parsed the HTML. That was fragile and dangerous, but it worked well enough to show that the demand was real.
Replacing most of that mess took the better part of a decade, and the long tail is still being retired. We ended up with OAuth grants, aggregators, and open-banking APIs. Consumer-permissioned account data became real infrastructure, basically a pipe. Authorize it once, and the data flows in a known shape and on known terms.
Now agents are showing up on commercial sites, and it's tempting to think we've seen this before. Automation wants access, so standardize it and build another pipe. The protocol work is already underway, with standard ways for agents to call tools and competing specs for agentic checkout. Those rails are useful. We're glad they're being built. We just think the analogy breaks in two important places.
The interaction keeps branching
Account-data sharing is read-only and fairly easy to standardize. A transaction record is a transaction record. A balance is a balance. The things a consumer wants to share are few and stable enough that you can describe the whole surface in a schema.
Agent interaction is transactional and open-ended. An agent booking a trip might compare fares, check a loyalty balance, apply a credit, choose a seat, then come back tomorrow to change it. An agent procuring equipment might request a quote, negotiate terms, and then ask its human before committing. The path keeps branching. At each step, what happens next depends on what the agent just learned. We don't see how that becomes a fixed list of endpoints, any more than a schema written in 1995 could have described the web of 2010.
So we don't think the infrastructure for a pipe is enough for an interaction that keeps changing as it happens.
A pipe carries data. A branch is a live interaction that forks in real time. They need different infrastructure.
Trust has to be checked each time
The analogy also starts to fail on trust. Consumer data sharing came down to a handful of known aggregators. Trust was established by contract and backed by legal agreements, audits, and certification. Once a pipe was approved, everything flowing through it inherited that approval.
Agent traffic works differently. It consists of millions of short-lived instances running across a growing set of runtimes and frameworks. Each one acts for a particular person, task, and scope of delegation. There isn't an obvious counterparty to sign a contract with, so trust can't simply flow down from a business relationship. It has to be checked for each interaction: which agent is this, who does it act for, what is it allowed to do here, and does its behavior match that grant?
The part in the middle
That evaluation needs a layer of infrastructure that mostly doesn't exist yet, and no checkout spec covers it. Bot detection handles the perimeter: automated or not. Payment authorization handles the final step: funds or no funds. In between, you still have to decide whether the interaction can be trusted. That means recognizing the agent, establishing its provenance and delegation, limiting what it can do, monitoring what it does, and keeping the record. That's the middle layer we're working on.
The pipe took ten years because the industry spent most of that time adding trust to a pattern that was already operating at scale. The branch is arriving faster. Our guess is that most of the industry will have to retrofit this too, under pressure, much as banking did. We'd rather build more of it deliberately this time.
We saw the retrofit era up close from the trust-and-risk side. We're not eager to see it happen again.