MICHELLE BU: Hi everyone. It’s great to see you again. I’m Michelle Bu, and I lead API design and developer experience at Stripe. So I’ve worked at Stripe since 2013, and I started as a product engineer. And then I did what a lot of engineers do, whether they like it or not. I slowly stopped building. More reviews, more docs, more meetings, fewer pull requests. But this year, that trend started to reverse, and I’ve shipped more lines of code since January than in the past five years combined. And I’m not even sure I’m the most interesting example of that. Across Stripe, 91% of our engineers are now using AI tools in their everyday work. Hang on. I think I just got a Slack.

It looks like Nilofer, our PM, is asking me for something. “Hey Michelle, a little bit of an emergency. We’re talking about workflows on stage today.” Yes, we are. “But we forgot to remove the public preview badge from the docs!” That is pretty bad. And Chrome will relaunch in three hours. Okay, let’s check on that. So it looks like indeed in the live docs, the public preview badge is still on there. So with my newfound ability to contribute code while also giving a keynote, maybe I can help her out. At Stripe, here’s what we’re looking at right now. We’re looking at a Slack channel where a bunch of Stripe engineers are collaborating with their agents. So some of them are planning with their agent before they’re using their agents to commit code, and some of them are directly using agents to remove feature flags and do cleanups.

So here I will go ahead and try to address this with our coding agent. So please remove the public preview badge from the workflows overview since it’s now GA. And I’ll paste that link there. So our agent can read the contents of Slack. It’s optimized for searching our humongous code base, and it’ll find the right code to change based on the context. It looks like it cooked for a second. It analyzed the conversation to determine the repository in workspace, and now it is off. We’ll check back on this later.

The agent you just saw is called a minion, and minions now ship over 1,000 PRs to production every week. In all these cases, humans just have to review and approve. But beyond these one shot PRs, in the month of March, over 57,000 PRs were created with the help of AI coding assistance, which is a 140% increase in just 3 months. And this change isn’t only internal to Stripe. In 2025, agent traffic to Stripe’s documentation 10x’ed in a single year. We went from agents representing less than 5% of our docs’ traffic to nearly 40%. And on this trajectory, agents will soon be reading more documentation than humans.

These data points validate that we’re experiencing a step function change in how development works. But despite all this innovation, there are still basics that we need to help our new agent friends with. Let me show you an example of an attempt at a Stripe integration from just a few weeks ago. Here, I’m trying to build a side business that takes up-front payments and start long-term engagements, but I also want to collect recurring subscription fees. This business is called Vibe Check. I’m going to use Claude Code to add payments to my site. Here, I’ve written a prompt describing my business model and asking it to set up invoices and subscriptions. Claude correctly recommends Stripe for payments, of course. But watch what happens as we actually dig into the agent’s suggestions. Coding agents have improved rapidly, but they still make some common errors because they’re often relying on outdated training data and they don’t know what they don’t know.

So when setting up subscriptions, the models suggest using the plan’s API. That might sound reasonable, but I know that API was deprecated in 2019 because I was at Stripe then. The agent also didn’t ask me any clarifying questions about my customer base or the way that my business operates, which is actually really, really important for selecting the right Stripe integration shape. Next, it asks me to plug in API keys to continue, but I haven’t signed up for Stripe yet. I don’t want to break this development flow, so I’ll just ask the agent to keep going and get my API keys later. Claude starts writing code, and if we look at the code, we can see that it’s getting the users’ payment details with a Card Element. Many of my users are in the EU where credit cards are not the only payment method, and Card Elements are focused on collecting card details, and so they don’t support preferred local payment methods out of the box.

That means my integration now has to manage payment method specific UI and error handling, which adds a lot more complexity and vibe-coded code for me to maintain.

And because I haven’t provided an API key yet, Card Element hasn’t actually been injected into the site, so it just looks like an empty rectangle. The code looks plausible and like it could work, but we can’t actually test it end to end. So now I need to stop what I was doing entirely and go through Stripe’s signup flow. Granted, that was still much faster than reading the docs and writing the integration myself, but without my prior Stripe knowledge, we would’ve ended up with a lot of problems that would’ve bitten us later. The developer experience that agent was relying on was built for humans, but now for both Stripe and for the broader industry, agent experience is becoming a large part of the developer experience. And that’s why we’re empowering agents, this little blobby, nondeterministic thing, in three ways. First, we’re making agents smarter by giving them context on Stripe’s best practices.

Second, we’re making agents more capable with deterministic tools for building and interacting with Stripe’s products. And finally, we’re making agents trustworthy with guardrails that prevent them from going rogue. So let’s take a closer look at each of these. First, making them smarter. When agents aren’t guided, they default to what they’ve been trained on, and that’s not necessarily what’s right or what’s best for your business. For example, last year we released elements with Checkout Sessions, which is a dramatically simpler way to build checkout that handles tax, pricing, and payments orchestration right out of the box. But because of outdated training data, probably some open source projects, some old Stripe docs, maybe a five-year-old Reddit thread that recommends the Card Element, our data now shows that agents consistently default to recommending PaymentIntents, which is recommending an unnecessarily complex integration architecture, even though we now have more modern solutions.

So this means if you’re a customer, you’re starting off your Stripe journey on the wrong foundation. And when you consider this at a macro level, including the increased speed at which agents are able to write code and build, this outdated recommendation gets replicated across thousands of repos very quickly. The scale of this mistake has a much wider impact than it did just a couple years ago. So to monitor agent performance and correctness, we created a Stripe integration benchmark. These benchmarks measure an agent’s ability to complete common Stripe tasks in a realistic environment. And because the benchmark establishes a controlled baseline, we can experiment with how to improve the agent’s performance. We’ve used the insights in our experimentation to make a number of enhancements, starting with our documentation. Our docs were designed to be easily scannable by the human eye, but now they also have to be as lightweight as possible to fit into precious context space and to minimize token waste for all of you.

So to address this constraint, we’ve made all of our documentation available as raw Markdown. By appending .md to any URL, an agent gets all the content without headers, footers, and UI elements. Stripe’s agent skills also load our expertise right into the agent’s context window, which guides it to the right choices before it makes a single line of code. Another enhancement is to Stripe blueprints. Blueprints, like docs, were originally built for humans as a step-by-step way to build a Stripe integration. However, an agent doesn’t use a mouse and so they don’t need a visual clicky guide. We’ve added a “Copy for LLM” button to our human blueprints, which copies a structured set of instructions. These instructions define the required objects, the recommended product settings, and the exact sequence of API calls to make, and any object state changes to monitor for. Also, your agent can build you a great integration.

Because of our benchmarking and product enhancements, we’ve improved the context that the agents have at the tips of their blobby hands. Your experience with agents is now a lot smarter. Did you see his little glasses?

But knowing the right answer isn’t the same as being able to act on it. Today, most platforms don’t actually give agents a way to do things. Your smarter agent can tell you what to do, but it can’t do it for you. We’re changing that, and we’re making agents not just smarter, but also more capable. Let’s see what happens when the agent doesn’t just know Stripe, it can use Stripe. Nilofer is a PM on our agent experience team. Why don’t you come up and show us what the team has been working on?

NILOFER RAJPURKAR: Let’s pull up Claude again and use the same exact prompt as Michelle. Claude correctly recommends Stripe again, and now it’s got our MCP tools helping it figure out our implementation. This time, Claude uses the MCP server’s Stripe integration recommender tool alongside Stripe skills to know what to use and what to ask. As you can see, it now knows to ask, “Where are your customers located?” to help provide a better integration recommendation. Also, it recommends just using Checkout instead of Card Element, because Checkout offers a much easier subscriptions integration. And because I let my agent know that my customers are located in the US and in the EU, Claude now recommends Stripe Tax. It explains that in the EU, digital subscriptions are taxable and require a VAT calculation. Stripe Tax can help me with that. I can see it’s also provisioning a Stripe sandbox for me. The agent uses a new Stripe CLI command to create the sandbox without needing any Stripe credentials.

This command also fetches the API keys and securely stores them for me. This way, I don’t have to break my flow. Okay. With the keys sorted, Claude starts looking at other Stripe skills. It indicates that it has everything it needs and asks to create the Stripe product via MCP. I’ll go ahead and hit yes and let’s see it get implemented. Let’s fast forward now and see the end state. I’m going to open up the checkout page and test that the checkout flow is working correctly. You can see the checkout pages here and ready. I’ll go ahead and hit subscribe and we’re done.

MICHELLE BU: So here we’ve made the agent smarter and more capable, and that resulted in a significantly more confident developer experience for all of you and gives us a purpose-built integration for our unique business. It started with our hosted MCP server, which has predefined tools and allows agents to call a curated set of API endpoints. It used our CLI as well to provision a sandbox. When we built the CLI, it was originally so that developers could test webhooks locally, but as the ecosystem evolved, so did our CLI usage and today the CLI has become one of the primary interfaces for agents to interact with Stripe’s capabilities. We didn’t originally build it for agents, we’re really leaning into it now. Finally, everything that the agent just coded was created in a Stripe sandbox. Sandboxes give agents a real isolated testing environment to operate in, hitting actual Stripe infrastructure with real response behavior.

And so after you’re done coding together, you can easily sign up for a Stripe account and claim your sandbox. When we bring these tools together, you have a complete end-to-end agent development stack designed to take you from a prompt to a production-ready system. Okay, so we talked about building the application, but what about ongoing maintenance and updates? Well, let me show you something we’ve been prototyping. Now that I have a functioning integration based on what Stripe recommended, let’s say I want to change the flow and the look of my checkout. I could go back to my favorite coding agent and fix it, or I could just have Nilofer do it for me since she owes me for that docs change.

NILOFER RAJPURKAR: Thanks, Michelle. I’ll go ahead and get this done right away. I’ll use Stripe Checkout studio, our new visual checkout builder, to update the code. Here, you can see that I’m in Checkout studio, a new place to configure and optimize your checkout for conversion. Here, you can change branding settings, configure payment methods, run experiments with A/B tests, and monitor performance, all from a single place in your dashboard. But many changes to your checkout integration still involve writing code, and that’s where our new prototyping tool can help. Here, I could see that my tool was able to scan my codebase in GitHub and pull out my checkout integration under the “Detected from code” section. Let’s take a look at what my checkout form looks like right now. It’s decent, but I want to collect some additional information. So I’m going to go ahead and add phone number collection, go ahead and turn on name collection, as well as consent for promotional emails. Okay, this preview is looking pretty good, so let’s go ahead and implement this. I can now see all of the steps that would be required for me to go ahead and make these changes manually.

MICHELLE BU: And this is what we were talking about with the Stripe blueprint earlier, right?

NILOFER RAJPURKAR: Exactly. I’ve got all the steps to make this checkout form a reality, but I’d rather have Stripe write this code for me. So I’ve sent my tool off, and it’s now making a PR in my GitHub repo. I’m going to jump over to GitHub and take a look at a PR that I opened just before this keynote. This tool integrates with GitHub Actions and has made this pull request for me. I can see that it’s handled all of the changes that Checkout studio suggested based on those updates. I feel good about this, so let’s go ahead, and go ahead and merge.

All right. Now, if I go back to my website and refresh, I can make sure all of these changes did actually take. All right. I’ll go ahead and sign up for a subscription, and there’s my new checkout form. I can see that I’m now collecting phone number, name collection, and email consent.

MICHELLE BU: I’m excited to see the potential of agents not just helping you build an integration, but also helping you maintain and update it. Writing code, however, is just one part of running a business on Stripe.

NILOFER RAJPURKAR: Throughout our many conversations with you, we’re increasingly hearing that you want agents to not only help build your business, but also operate it. Specifically, you want them to help with routine tasks like subscription updates and billing questions and refund requests. Because agents are nondeterministic and eager to please, they’re actually really great at interpreting these complex tasks. They can reason and infer context, they can adapt their tone and craft a resolution perfectly tailored to the situation.

MICHELLE BU: But also exactly because they are nondeterministic and very eager to please, as hard as they may try to follow your instructions, they won’t always accomplish the task in the exact way that you want them to. This nondeterminism presents new challenges when you want them to move money or refund transactions. We can’t have an agent going rogue from a customer service request or refunding a large purchase. So here’s how we’re making agents more trustworthy. Let’s take a look at some of the things we’ve shipped that help you better understand agent usage and set appropriate guardrails. First, you can now give your agent agent-tagged API keys, which lets you treat your agents as a new type of actor within your business with its own identity. This provides you with complete visibility into the actions the agents are taking on your behalf. More importantly, tagging your agents gives you the control to set permissions, rules, and boundaries with approval rules. Nilofer, can you show us how you’re using these tools?

NILOFER RAJPURKAR: Absolutely. Thanks to the speed of agents, I can now wear a lot of hats. I’m now helping Michelle run multiple businesses simultaneously. In addition to maintaining Vibe Check, I also lead operations at Hypernian, and we get a lot of support requests. Here are two emails that came in today requesting refunds. The first one is from Sarah Chen. She was signed up twice for her subscription and is requesting a refund of $50 for last month’s subscription. In our second email, Marcus Rivera is requesting a $250 refund. He’s a little unhappy with the service and he wants his money back. Let me show you how we’re handling this with agents. First, I’ve created an API key and I can have it tagged here as an agent key. This gives you observability over agent actions and allows you to restrict the actions that this agent can take. I’m using this key in a customer service agent that I’ve built.

Now, a quick reminder from our security team, you should never present the API key page when you’re doing a demo in front of a thousand folks. But the good news is I’m in a sandbox right now, so this is all okay. Okay. Next, under settings, we’ve now introduced approvals. These are safe-by-default guardrails that protect your account. You can see different rules here for refunds, subscriptions, changes to my bank account, and more. These apply whether the action comes from an agent or from a human, and whether it comes from the API, MCP, or the Dashboard. I’ve got the same rules, same protections everywhere. For our use case, I’d like to update our refund rule. By default, this rule requires an approval on all refunds, but for our use case, I’d like to give my agent at Hypernian a little extra discretion, up to $100.

MICHELLE BU: We’re really empowering our agents at Hypernian, aren’t we?

NILOFER RAJPURKAR: We are. All right. So let’s go ahead and save this rule. And now this refund will require a human approval anytime something is over $100. Okay. Let me show you what this looks like in action. I’ve gone ahead and created a customer support agent, and I’ve given this agent my API key that we tagged earlier. Let’s go ahead and get this agent running from my support agent dashboard. You can see that our agent is now monitoring our inbox. It’s pulling for new emails and identifying any refund requests. It’s then using Stripe’s APIs to look up the relevant accounts and my recent charges. I’m going to switch over to Workbench and see the full details of the request that this agent is making. I’ll go ahead and refresh my logs, and I can see new refunds coming in. All right. So here, if I take a look, I can see that this refund was done by an agent because of that key that we tagged earlier.

And in Sarah’s case, this refund went through automatically. No approval needed. Now, let’s take a look at what happened in the case of Marcus’s refund. Here, our agent tried to pick it up just like it did with Sarah’s, and I can see that this action was done by an agent again because that API key is tagged. However, we see an error on this one. This is because our approval rules kicked in. This refund was over $250, and that’s above our threshold, so Stripe blocked it per my approval rules. We can see that the agent gets back a structured error. It’s able to read this and understand that an approval is required. So then the agent went ahead and called our approval request endpoint to send this request off for a human review, in full transparency and a full audit trail.

MICHELLE BU: And so your agent actually figured out how to do that on its own based on the error message that we were returning the API.

NILOFER RAJPURKAR: Exactly. It got all of the information it needed in that error.

MICHELLE BU: Great. So now let’s see what happens when we want the refund to go through.

NILOFER RAJPURKAR: Yeah, so the agent submitted that approval request, and if I come back to the dashboard, I can see that the approval is waiting for me. I can open this up and see all of the details about this review. It’s a $250 refund from Marcus that was initiated by our agent. I’m feeling really comfortable with this, so I’ll go ahead and approve this refund.

MICHELLE BU: All right, if you say so. So we’ve given the agent power to act and we’ve kept a human, Nilofer, in the loop for the most important decisions. Now, what happens after that refund goes through? For example, the Hypernian sales team, which is also Nilofer, may also want to know about every refund. This kind of process is one that happens repeatedly and should run the exact same way every time. And with Stripe Workflows, you can define a process once and it runs the exact same way whether the refund came from an agent, a support rep, or your own backend. Until today, workflow actions, such as updating a customer object, have only been able to act within Stripe. But with the new custom actions feature in workflow, you can now call out to popular applications such as Slack.

NILOFER RAJPURKAR: Let me show you how this works. So that refund that I initiated and approved in the dashboard creates a refund.created event. I’ve got a workflow here, and that event is the trigger for this workflow. Now with workflow support for custom actions, I can configure notifications to all of the right people in the right places. If that workflow is less than $100, it’s going to go ahead and notify the sales team on Slack with that refund amount and a link to the refund in the Stripe Dashboard. Here, if I come over to Slack, I can see that that refund is here. For larger refunds, we’ll want to pull the relevant customer details and tag the customer as needing a customer follow-up in our Stripe Dashboard. And this workflow is going to run the same exact way tomorrow when a support rep processes something from the Dashboard or next month when your backend triggers one through the API, a single defined process every time.

MICHELLE BU: You also mentioned this customer follow-up object I don’t recognize as a Stripe object.

NILOFER RAJPURKAR: That’s right, Michelle. It’s not a Stripe object because it’s a custom object that I’ve defined on my own Stripe account. With custom objects, I can bring my business data and logic directly into Stripe. Let me show you the code and see how this works. So given we’ve seen so many refund requests lately, I want to make sure our customer success team follows up on these big refunds. The customer follow-up object that I’ve created includes a number of important parameters. I’ve got a reference to the Stripe customer who received the refund. I’ve got information about the refund amount and the reason for their refund. I have a status field, which is initially set to “Follow-up needed” and we’ll move through these different statuses. And I’ve also got fields for who completed the follow-up with the customer and any notes that they may have.

MICHELLE BU: And tell me about this “Complete follow-up” custom method here.

NILOFER RAJPURKAR: So this is the custom logic that we’ve built on top of running this object. When our customer success team finishes their outreach, they can click a button in the Dashboard, which calls this action and it captures who completed this report and any notes that they may have and moves the status to “completed.” Let’s go back over to the Dashboard and I’ll show you this in action. I can navigate to my customer follow-up dashboard.

MICHELLE BU: And this is all your custom objects in the Stripe Dashboard.

NILOFER RAJPURKAR: Exactly. I’ve built everything that I need customized to my use case here. And I can see that Marcus’s refund is now in this set of data, marked as “Follow-up needed,” because that refund was above $250. If I go ahead and click into Marcus’s record, at the top of the page, I can see a button to complete the follow-up. After I’ve had this discussion with Marcus, I can click that, provide any notes from our discussion, and go ahead and confirm.

MICHELLE BU: And that’s running the code that we just saw that you wrote.

NILOFER RAJPURKAR: Exactly. All right. All done here.

MICHELLE BU: Amazing. So with custom objects, we were able to better model the entities that matter to our business by defining objects on Stripe. From the Stripe APIs, our custom SDKs, and the Stripe Dashboard, you can create and access these custom records that power your processes. Let’s just take a step back and look at what we just saw. We have an agent that autonomously handles customer support, reading email, looking up accounts, issuing refunds. It resolves Sarah’s refund automatically and approval guardrails kicked in when Marcus asked for more. Then with Stripe Workflows and custom objects, Hypernian’s sales team was automatically notified after we approved the refund and the customer success team was tasked with getting more customer feedback. This is how we’re making agents more trustworthy at scale. Wait, I think that’s just Nilofer wearing another hat. That’s not Marcus, is it? Okay, let’s wrap. Everything we’ve shown you today.

NILOFER RAJPURKAR: Hang on, Michelle. Did you actually finish that docs change I asked for earlier?

MICHELLE BU: Good call. Let’s check back in. Remember that minion that I kicked off at the start of the keynote. Well, it looks like that minion run completed and we can actually go and see the changes that it proposes. And it looks like on the workflow overview doc, it has removed the public preview availability field, and so that should be GA after we deploy this. Amazing.

Everything we’ve shown you today is about making it better to build and run your business with agents. We’re teaching agents Stripe best practices so you can start with the right technical foundation. We’re building deterministic tools so you can work with more capable agents, and we’re putting guardrails in place so you stay in control while moving at a speed that just wasn’t possible before. We’ve been obsessing over developer experience for 15 years. Agent experience is just the next chapter, and so we’re focused on supporting the way you work today and the way that you’ll work in the future.

I’m going to go get that PR merged for you all. Thank you.