Ben Greenberg - Unlocking AI Agentic UX with Google’s AP2 Standard and the x402 Protocol

In this talk, Ben, a senior developer engineer at Arbitrum, discusses the evolution of web interactions from people to machines to the emerging agentic economy, where agents can perform tasks on behalf of users, including making payments. He introduces X402, an implementation of the HTTP 402 status code that enables native web payments for agents, allowing them to transact without needing human intervention. The discussion highlights the importance of making web applications 'agent ready' to facilitate these new payment capabilities. Ben also emphasizes the coupling of X402 with the Agent Protocol 2 (AP2) from Google to provide secure authorization for transactions. He explores the need for predictable settlement processes, often utilizing blockchain technology for efficient transaction finality and auditability. Additionally, he offers insights into the developer tools and SDKs available to integrate these functionalities, encouraging engagement with the programmable economy through initiatives like Open House.

Good afternoon, everyone. It is so great to be here. Sorry to interrupt what looks like your YouTube shorts listening. Everyone's listening something great on their headphones. I'm coming in live to you right now to talk about, I think, a very important topic. A very critical topic at an inflection point of perhaps the entire modern web, which is how to enable HTTP web native payments. Now, I'm sure

you're not going to see this word for the first or the last time in the next 2 days. The agent economy, agentic activities, agentic applications, everything nowadays is about agents. And I am sorry to disappoint you, this talk is also about agents. And we're going to talk about how to give your agents a wallet. How to give your agents the ability to transact. Before we get going,

my name is Ben. I'm a senior developer engineer at Arbitrum. You can find me online everywhere at Homos on Rails. Uh long-time Ruby on Rails developer. Any Ruby devs here from a while ago? Love you. Right there. Love Ruby devs. You find me online everywhere on that social media account. And I would also love to connect. If you want to talk agentic payments, how to build agents

together that not only can think, not only can process, but can pay, please scan that QR code and connect. I would love to talk to you. Okay, let's get going. Well, agents, my friends, agents are the new interface. For the entire history of the web, I'm old enough to remember when we transitioned from bulletin board systems to the web. The entire history of the web has been

people to machines, people to services. But now there's a new interface, and that interface is your agent that is acting on your behalf. That is thinking for you, planning for you, responding to your Kanban tickets for you. That is doing your shopping list on bol.com for you. But one thing that they have not been able to do is to pay. Because at every interface of checkout, at

every place where you insert a credit card information and click submit, every website, every application assumes a human at that point of encounter. But that's not the case nowadays. That's not the way that we're building the future of the web nowadays. More and more, agents need to be able to pay. And not only do agents need to be able to pay, as those of us in this

room who are responsible for web applications and services, did anyone here ever use Lighthouse or use Lighthouse? Does that sound familiar? I see some heads head nodding. Right, a valuable resource to think about accessibility, SEO, performance, first time to paint on the browser, all kinds of very important data points. When we start imagining what our new checklist is for our web when we think about things like

not only, and these things are deeply important, things like accessibility, scalability, things like its ability to be performant, when we think along those lists, we're also thinking about things like is our site agent ready? This is a new service from Cloudflare. You can actually go talk to them right outside. cloudflare.is-it-agent-ready.com. Cloudflare has launched what one could call the new Lighthouse of the agentic web. And amongst the

things it checks for, and it checks for all the different ways that your site or your application can be accessible to a non-human actor. Notably, your agent. One of the things it checks for is is it accessible for payments? Can an agent pay? That brings us right to the point of why you're sitting in this space with those lovely green headphones on. You're in this this space

to talk about how we get to that moment. How do we answer the question when our managers, when our CTOs, when our CIOs say to us, "Hey, dev team, did you make the site agent ready yet? Did you do the payment processing thing yet?" And you have to go Google and look up, "What is the agent processing thing? How do I do that?" Well, now you have

the answer cuz you came to this talk and you'll be ready and equipped to at least begin that adventure down that road. And it starts with four characters, X402. X402 enables native internet native payments, not only for agents, but it is so helpful and so useful for agents. Now, X402 might sound a bit familiar because it's a new open standard built on top of the 402 status

code. The 402 status code from the web spec has existed existed since I don't know, 1997 or something like that, almost 30 years. There are people in this room, I see a couple of them actually, who are definitely younger than this status code. This status code is older than some of you in this space right now, but it has not been used. This The moment for this

status code is right now. And the way [cough and clears throat] it works is actually quite simple and quite familiar to any of us who are used to this call and response process on the web. Servers respond with payment requirements, clients sign their payment and pay in the next repeat request. There's already XPR 2 is relatively new. There's already a V2 of XPR 02, which launched ability

to go beyond single call payments. Imagine multi-payment processing, dynamic payment recipients, imagine like an Amazon marketplace or other sorts of services like that. XPR 02 is a protocol that's now been adopted by the Linux Foundation and it continues to expand and grow actively. Right now, as we are talking in this room in this very moment, there's probably some activity happening on some GitHub discussion about how to

expand beyond for more feature set in XPR 02. And that's because it is approaching wide levels of adoption. XPR 02 has been adopted and integrated by Cloudflare. It has been adopted and integrated by AWS, by Google Cloud, by Vercel, by Netlify, by Mastercard, by Amex, by an increasing list of platforms, by Adyen, I think they're a Dutch company, you probably know them a bit, by all sorts

of services are consolidating. It's not the only payment standard for the agentic web. I want to be very clear on that. There are other payment standards, but this payment standard is perhaps as since it is being held and entrusted by the Linux Foundation, one could argue is perhaps one of the most open with clear governance and transparency and being adopted by a wide array of actors in

the industry. So, it's quite promising to watch it. And the way it works, I hinted that it's a process familiar to many of you. You make your initial API request, your 402 request. The response comes back with how to pay. So, your merchant, your API, whatever it may be, sends back a request sends back a response with, "Okay, you want this service. You want this API call.

This is the type of currency we take. This is how you pay for that currency." And then it waits for you to pay. Now, how do you pay? Well, that depends on the the agreement made and the structure made by the admins of that application. The payment rails, so to speak, is agnostic. It's what you set up for your application. You decide what kind of payment rails

you want and you respond to the requester with those payment rails. And then the requester, it's on them to make that payment and provide to you cryptographic proof, which is the signed payment, the next step, cryptographic proof that you indeed made that payment. And once it's verified, whatever that service is, whether it's a web scraper or an API call, uh a new pair of Nike shoes, it

doesn't really matter what it is. Once it has been verified, that item drops, that item is opened, that item is made available to the requester. More often than not, that requester is an agent, not a human. Now, coupled with that, there are also really exciting standards out there in the web that enables this to be done in a secure way. I listened to the last talk and

I thought it was fantastic around secure uh MCP servers, how to think about MCP in a secure context. We also need to think about that exact same uh constraints and exact same realities in the threat landscape we live in today. And thankfully, there are standards that complement and go together in tandem with standards like X.502, namely AP2, Agent Protocol 2 from Google, which offers us what we

could call secure authorization. So if X402 is the payment specification, then we have AP 2 which becomes the authorization spec. And it doesn't take much imagination to understand how they couple together. And the way that APT works at a high level is that you work on a construct of verifiable digital credentials. VDCs. Again, using cryptographic proofs. And each of those steps has an audit trail. A open

transparent auditable audit trail. And you can specify flows whether how much and whether or not at all. Humans, that's all of us by the way in this room unless I'm mistaken there's an embodied AI here right now. That's all of us. Whether humans are in the loop and how weird is it to say that by the way? I never thought I'd be in a in a world

where I'd be giving a talk about whether humans are in the loop or not. You know, as a long time Star Trek fan I'm kind of imagining well where's the Vulcans? Are they coming soon? But whether humans are in the loop or humans are not in the loop and it like X402 has no opinion. It's not opinionated on the payment settlement layer. That it's agnostic. As long

as it can verify it and create a cryptographic proof for it, it doesn't really matter what your payment settlement layer is. And this too has been adopted by a wide amount of companies. Adyen, MasterCard, PayPal, etc. And though as I mentioned the way it works is with verifiable digital credentials. You have a series of mandates. And the mandates carry through the user's journey with their agent. So

imagine it as sort of like a storyboard. And you are the user. So you start the storyboard at your intention. My intention is to buy the new Mac mini when it drops so I can my open cloud agent on it. That's my intention. So I signed an intense mandate authorizing and specifying what I want. That's the first step. Then you have a cart mandate, which encodes what

the agent will be purchasing. What you want and what will be purchasing. Each step, if if there's any product managers in this room, you can imagine the user story, the user journey. That's essentially what we're doing through a trail of cryptographic steps called mandates. And then each one of those, of course, leads to an audit trail. And as we mentioned, human loop, human non the loop, it

really depends on your comfort level. So we go through the process, you define your user intent, which goes to the agent's intent of what it will purchase. Finally, the agent goes and discovers it out there for you on the Apple store, gets you the new Mac mini when it drops. It builds out a cart. You mandate, you sign in advance what the cart can be. So the

agent then is scoped exactly to what you specify. And then lastly, you have a intent, another last mandate for payment linked to the payment method that you want to execute on. So each step of the way is its own discrete item, which of course, if we like separation of concerns, as many of us should, we like separation concerns, this becomes easy to reason on, easy to think

about, easy to act and debug each of these steps. These, of course, could have been consolidated, but it's much easier to reason on when they're separated out. And finally, settlement. So together with AP2 and X402, you get a really clear, coherent journey of how an agent can not only act for you, can not only look for for items for you, can only book tables on OpenTable for

you, but can also pay for you for things securely, with guardrails, with a sense of confidence. Then as we mentioned, this is not something that it is both This amazing. It is both new and also well adopted. We're living in really strange times. Things that are so new are are experiencing a velocity that is absolutely unheard of. I have not seen this in my career in technology,

this level of velocity of adoption on really anything else this fast. Just over there is a workflow from AWS's official guide on how to use AWS services like Bedrock and Lambda@Edge, I think, and CloudFront and others, how to use that to build an X402 service. That's incredible. That is unheard of, that level of adoption. It just tells you the sense of speed and velocity and where we're

marching at a pace that is for me at least, and maybe not for you, but for me is quite dizzying to try and keep up with this. I feel like I've two jobs, my job and keeping up with the things that enable my job at this point. It's really, really challenging. I want to take a couple minutes because all of that maybe made sense to you. All

of that seems like it fits in a paradigm. Call and response, HTTP servers, HTTP status codes, cryptographic proofs. You may be familiar with some of those things, less familiar with others, but they all are words that we have a shared vocabulary for. But what I don't assume that everyone in this room has is a shared vocabulary around the settlement economics of these activities. This is not something

that you learn in a classic CS program. It's not something you learn in a coding boot camp. It's not something you may pick up in an O'Reilly book of settlement economics. So, I think it is actually pivotal and integral we just take a minute to talk about that because let's imagine the scenario. You are assigning your agent to act on your behalf to make API calls for

web scraping. It's a good example, right? And that web scraping may involve thousands of API calls. Thousands of API calls. You need a settlement economics that makes that viable. That makes that feasible. The settlement layer needs to make sub-cent payments feasible. Because the beauty and really the power of X402 is you don't need to create accounts. You don't need to create subscriptions. You don't need to go

through an entire KYC, know your customer process. Your agent can make 0.0001 cent per API call payments. But then you need a settlement process that can support that. And so, in case it's not familiar to you yet, or hinted around the edges, the settlement layer for X402 across the entire industry from AWS to Google Cloud to Vercel to Netlify to IDN to all of them is on

blockchain. Why? Because blockchain, and some of you could say, "FINALLY, THERE'S A USE CASE FOR BLOCKCHAIN." BUT WHETHER OR NOT you're like, "Finally, there's a use case." or you're feeling vindicated, that does not matter for our conversation at this moment. Blockchain provides the primitives for near instant finality and settlement and built-in inherent within the very architecture of the system is auditability. Right? You probably heard that from

every crypto bro you ever spoken to in your entire life. It's publicly auditable. It's transparent. Well, now that makes sense for all of you. Right? And but you need a blockchain, you need a settlement layer that can provide the predictability in those fees as well. Because blockchains, like a lot of market economics, fees can be variable. Some of you, I'm sure, have had the experience of trying

to buy some coin once in your life. I don't know what that coin was. I don't really care. Trying to buy some coin in your life, and you may have experienced, well, the fee to buy the coin was more expensive than the coin itself. And you probably wonder why that was. Well, it depends on network traffic, on the amount of validators, on all other sorts of things

that are not for here and now. But so, that doesn't work for the economics that we're building at our scale. We need fee predictability for agents to act where they're not going to drain our entire life savings to make a single API call. And I also strongly believe, and I've held this true, I've been doing developer relations for longer than I care to admit, I strongly believe

that developer tooling, developer ergonomics, good quality developer tooling does not have to equal less efficient, worse experiences from scalability, from speed, from performance. That if I introduce abstractions and make things a better experience for devs, I don't have to I don't want to hear from my DevOps team that I'm also increasing the bloat at the same time. And so, where I work in Arbitrum, we built a

co-equal virtual machine to the settlement layer, the Ethereum virtual machine. They interoperate, they share a same state tree. That's very fancy terms for basically they work together. And that one works on Rust. And that not only do you get a crypto bro, you also get a Rustacean. And telling you we do everything in Rust, it's always better in Rust, compile it in Rust, it'll be awesome. But

from anything compiled from Rust into WebAssembly, uh will be more performant, faster, and cheaper to run by definition. And so, you get the a faster experience, a more production, one could argue more enterprise level experience using languages like Rust in the same auditable, deterministic, and tamper-proof network. And you can see the price, you know, on AWS we call these credits, on blockchain we call this gas, it's

the exact same thing. In a Rust network, it is exponentially 92% cheaper to run your transactions than on a non-Rust network. It is not a statement of opinion, it is actually a verified uh proof that you can run yourself in any experiment. It is 92.6% cheaper to run it on Rust than to run it on anything else. Well, you could also do C# too. To run it

on WebAssembly than to run on anything else. And so, cheaper compute means you could do more verification. Verification costs money, like you run a service on AWS, everything on AWS costs money, same kind of idea. Cheaper compute means you can verify more, you can have more uh auditable, more uh cryptographic trails, more logs, more proofs, all the things that are important for, I don't know, the big

fancy word like compliance, for example. And we start thinking about money and start thinking about economics, we need to start thinking about compliance. So, the way this roughly works, as we mentioned, HTTP status code 402 came about in 1997. The X402 implementation is the implementation of that status code for the first time in 28 years. And the schema is well defined. I hope it's a bit intuitive.

You define your network, the max amount required, and the asset that you're using to pay for. It's usually going to be a USD stablecoin, USDC, and that's essentially it. And then, when you're building your application layer, it really There are SDKs already. There are SDKs already. There's client libraries. There's MCP servers. You're going to hear about a fantastic MCP server that's come out tomorrow on another talk

on a genetic payments that I highly recommend you visit. I won't tell you more. You have to find it on the agenda yourself. They're MCP servers. There are client libraries. There are SDKs. This one is for Express JS. You import the library. You define who and where the payment is happening. We call that a facilitator. And then you put one point of middleware. One middleware call on

the one route that needs payment. That's the only intervention in your code that you need to worry about. And you're using all the infrastructure you already know, Cloudflare, AWS, Google AP2. And as we mentioned, you get all the benefits of independently verifiable compute, independently verifiable execution that makes this viable for market economics at scale. You can do so much with these services. Pay per use API access,

agent to agent service, autonomous constraints, machine to machine payments. The list is really endless to build open, composable AI agent economies. Now, if you want to know more, I actually built for you a GitHub repo. You can clone this. It is just open source repo combining X402 with AWS services. So, you can see what this looks like in a kind of a sandbox enterprise version using all

AWS services and X402 that is totally free. Clone it, play with it, do what you want, learn with it. If looking at code helps you, I highly recommend scanning that and uh starting. And I would also want to mention, if you're interested in payment economics, if this is something that really fascinates you, we run a builder initiative called Open House. Our next initiative is happening in London

From May 25th to July 12th, combination of in-person and online, sponsored by these companies and more with over a half a million dollars in grants and rewards for builder teams launching the next wave of the programmable economy. So this is something that is fascinating to you, you're curious about it, I encourage you to sign up either for the online portion or the in-person portion. You not be

in London for the online bit. You only need to be in London for the in-person bit. It's highly recommended. Half a million dollars up for grabs with AWS, Robinhood, and other companies sponsoring and coming together for what we call open house. And lastly, I would love to talk to all of you. Definitely you right there. I want to talk to all of you. If you are curious

about the programmable economy, building agent economics that work using X402, please stay in touch. I don't bite. I'm somewhat friendly if I have enough coffee. I would love to talk to each and every one of you and continue this conversation. Thanks so much for your time and enjoy the rest of DevWorld Amsterdam.