Agent First Development is The Future

Back when mobile took off, every product team went through the same reckoning. You couldn't just shrink your desktop site down and call it a mobile experience. The winners were the teams that flipped the process: design for the small screen first, then expand out to desktop. "Mobile first" wasn't a slogan, it was a complete rethink of where you start.

I think we're at the exact same inflection point again, except this time the new screen isn't a screen at all. It's an agent.

Here's the thing that makes this not just a hot take: it already happened. In June 2026, Cloudflare CEO Matthew Prince confirmed that bot and agent traffic officially passed human traffic on the internet for the first time ever. He'd predicted this would happen in 2027. It happened a year early. Cloudflare Radar puts it at roughly 57% of requests now coming from bots and agents, not people.

And the reason isn't spam. It's scale. A human comparing cameras might check five websites. An agent doing the same task might check five thousand. Multiply that across every shopping decision, every research task, every "hey, can you handle this for me" moment, and you get an internet where the primary requester of your product is increasingly a piece of software acting on someone's behalf.

Stripe's own research backs this up with a number that's hard to ignore: agentic shoppers could account for as much as $385 billion in US ecommerce spending by 2030. That's not a niche use case. That's a second customer base showing up at your door, and in a lot of businesses, it'll eventually be the bigger one.

My thesis

The old playbook was: build the product for humans, then bolt on an API later so "enterprise customers" or "developers" could integrate. Agents were an afterthought, something you served through a thin wrapper around your real product.

I think that playbook is now backwards. The right way to build a product going forward is Agent First Development: design for the agent as your primary user, and treat the human-facing UI as one client among several, not the canonical one.

This isn't about ignoring humans. Plenty of your users will still be people clicking around a dashboard. It's about recognizing that the agent calling your API might be the one actually making the purchase decision, filing the ticket, or configuring the account. And if your product wasn't built with that in mind, you're invisible to it.

Start with the API, not the frontend

Agents are getting shockingly good at "computer use": clicking buttons, reading screenshots, filling out forms like a human would. But that's still the slow, fragile, expensive path for them. Give an agent a well-designed API instead of a UI to fumble through, and it'll be faster, cheaper, and far more reliable every time.

So the first thing you should design isn't the frontend UX. It's the API UX.

That means every single thing a human can do in your product should be reachable through an API. Not just the core feature set. The boring stuff too. Creating a new user. Grabbing API keys. Changing a plan. Resetting a password. If a human can click it, an agent should be able to call it.

Stripe is a good case study here, mostly because they've been transparent about the process. They didn't just add an "AI mode." They built the Agentic Commerce Protocol with OpenAI as an open standard for how agents transact with businesses, introduced Shared Payment Tokens so an agent can pay on someone's behalf without ever touching raw card details, and shipped an official MCP server at mcp.stripe.com so any MCP-compatible agent can work with the Stripe API directly. The pattern across all of it: don't make the agent guess. Give it a typed, scoped, well-documented surface built for exactly what they want to accomplish.

That last point matters more than it sounds. Your API shouldn't just be a plain HTTP interface anymore. It needs to be reachable through MCP, through OAuth, and through plain old REST, because different agent harnesses will reach for different tools, and you don't get to pick which one shows up at your door. And here's the part people get wrong: don't build a separate "agent API" next to your "real API." Build one API that both your frontend and your agents consume. The moment you fork them, they drift, and eventually your agent experience quietly rots while nobody notices because the humans never hit that code path.

There's a side benefit to this that's easy to miss: once your API genuinely covers every feature, your own internal coding agents get an enormous gift. They can test the thing they're building the same way an external agent would, by hitting the same API, instead of scripting a browser to click through your UI. If you're using Claude Code, Cursor, or any coding agent to ship features faster, an API-first product is the difference between that agent verifying its own work in seconds versus flying blind.

Agent First changes the frontend too

None of this means the frontend doesn't matter. It means the frontend needs to change in ways most teams haven't thought about yet.

Give coding agents a real way to log in. If your coding agent is iterating on your frontend, it needs to authenticate against your live app to actually test what it built. "Login with Google" is fine for a human clicking a button, but it's a wall for an agent. You need an auth path, a service account, an API key flow, something, that lets your own agents log in and verify their work without a human clicking through an OAuth consent screen every time.

Make your marketing content legible to agents, not just search engines. This is where llms.txt comes in: a plain-text file that tells agents what your product does and where to find more. Stripe already publishes theirs at stripe.com/llms.txt, alongside Markdown versions of their docs, specifically so an agent can parse "what does this company offer and how do I use it" without having to render a JavaScript-heavy page first. If an agent is doing the research and recommending your product to a human, and it can't parse your homepage, you're not in the running.

Get ahead with new discovery standards like WebMCP. WebMCP is a proposed web standard, already shipping behind a flag in Chrome 146, that lets a webpage declare its own callable tools directly to an in-browser agent. Think bookFlight() or checkout() instead of an agent trying to guess which button does what. Google's own numbers on this are eye-opening: roughly 89% fewer tokens spent when an agent calls a declared tool versus scraping pixels and DOM to figure out what's clickable. It's early, it's experimental, and it might not be the exact standard that wins. But the direction is unmistakable, and the products that adopt this kind of thing early will have a real edge with browser-native agents.

The point isn't agents over humans

None of this is an argument for building soulless, headless products with no UI. Humans still need a place to see what happened, feel good about their purchase, and trust the brand behind it. What's changing is the order of operations, and who you assume is knocking on your API first.

Mobile-first didn't mean nobody used desktops anymore. It meant you stopped treating mobile as the cut-down version of the "real" product. Agent-first is the same move, one layer deeper. Your agent interface isn't the stripped-down version of your product for robots. For a growing share of your users, it *is* the product. Everything else is just a nicer way to look at what already happened.

The teams that get this early won't just be more "AI-friendly." They'll be the ones agents actually recommend, actually complete transactions with, and actually keep coming back to, because they built for that reality instead of retrofitting it in six months from now, after everyone else already did.