Agents Are Your New Customer

I watched the WorkOS Auth.md video this morning and felt two things simultaneously.

Amazed. And annoyed.

Amazed because this is real. Annoyed because I want to be further in the frontier — and watching someone else ship the vocabulary for the category I've been working in quietly for months has that effect on you.

Auth.md is a new open protocol from WorkOS that lets AI agents authenticate to a service on behalf of a user — without a browser, without a sign-up form, without a human in the loop. It's a Markdown file you publish at your domain. Agents read it, parse the flows, pick a registration path, and either present a verified identity assertion from a trusted provider or walk the user through a six-digit OTP claim. Standard OAuth credentials come out the other end.

That's the mechanism. But the line that broke my brain wasn't technical.

It was this: "Agents are your new customer."

The Line That Inverted Everything

"Agents are your new customer. Build things that agents need, build things that agents want."

That's the startup mantra — "know your customer" — flipped on its head. For two decades, "customer" meant a human. A person with a browser. A person who fills in a form, clicks a button, reads an onboarding email. That's who infrastructure was built for.

Auth.md argues that the entity hitting your API might not be that person anymore. It might be an autonomous process running on their behalf. And if you haven't designed your API to receive that process, it will bounce off you. It will return a 401. It will give up, or it will ask the human to stop what they're doing and manually paste in an API key like it's 2014.

The scope of that shift is TCP/IP-scale. When the internet came out, we defined the primitives that let machines talk to each other — TCP, IP, HTTP. Auth.md is proposing a primitive for the agent era: a standard way for an autonomous actor to present itself to a service that doesn't know it. No proprietary handshakes. No per-vendor integrations. Just: here's who I am, here's who I'm acting for, here's the credential.

WorkOS Auth.md is open. Not WorkOS-only. Any app can publish an auth.md file. Any agent can read one. The protocol is built on standards you already know — OAuth 2.0, OIDC, Protected Resource Metadata (RFC 9728), JWT-based identity assertions. No new crypto. No new key distribution. The clever part is the discovery layer and the two flows that handle the cases existing OAuth couldn't — because existing OAuth always assumed a human in the loop.

I Was Already Here

Three pieces of agent-first infrastructure I'd been building before Auth.md gave me the vocabulary: MeshWire, Hookflows, and content encryption.

Here's the part that hit different.

I've been building agent-first infrastructure for months. Not because I had a thesis about it. Because that's just what the problems demanded.

Meshwire — I built it so agents can discover and connect to each other across sessions. Not so engineers can wire up a graph in a config file. For agents. So an agent running in one Copilot CLI session can find and talk to another agent running in a different session, across a network, without either of them knowing ahead of time that the other exists. My MeshWire launch post is literally titled "Stop Connecting Your Agents One by One" — a complaint about the human-centric wiring model being applied to agent infrastructure.

Hookflows — governance for agents, not humans. The whole point of a hookflow is that an agent triggers a hook at a defined checkpoint, and the platform can observe, validate, or block what happens next — without a human watching the terminal. I built those because I needed a way to enforce behavioral contracts across a fleet of agents that were operating autonomously. No human approval gates. Agent-to-agent accountability.

Content encryption — I built this so content could be consumed by agents with verified access, not just by humans with passwords. The whole model is: agent presents credentials, gets decrypted content, acts on it. There's no human login flow because I never intended one.

Auth.md is the vocabulary I didn't have for what I was doing.

I wasn't building "AI tools with some backend services attached." I was building services whose primary consumer was going to be an agent. I just didn't have a word for that orientation. I couldn't point at the Auth.md spec and say: "This is the problem space I'm living in." Now I can.

What Auth.md Actually Solves

Auth.md's two registration flows: Agent Verified (trusted provider attestation) and User Claimed (OTP binding). Both terminate in scoped, revocable OAuth credentials.

The problem Auth.md addresses is deceptively simple: an agent hits your API, gets a 401. What does it do next?

Before Auth.md, the options were bad. The agent gives up. The agent interrupts the user to go create an account manually. The app ships a bespoke agent-registration endpoint that no other agent is trained to understand. None of these scale.

Auth.md solves this with two flows:

Agent Verified — A trusted agent provider (think: any platform whose agents act on behalf of authenticated users) signs an identity assertion — an ID-JAG — vouching for the user. The agent presents it to your /agent-auth endpoint. You verify the JWT against the provider's JWKS. You JIT-provision a user record. You issue a scoped credential. No OTP. No human in the loop. If you've ever JIT-provisioned users from Google Sign-In, this is structurally the same — just with an agent as the trust intermediary instead of a browser.

User Claimed — For when there's no trusted provider attestation. Your app issues a claim token, sends the user a one-time link, renders a six-digit OTP, and the agent completes the binding on the user's behalf. Slightly more state to manage, but it gets to the same place: a scoped, revocable credential tied to a real user that an agent can present on every subsequent request.

What makes this elegant is what it doesn't do. No new crypto. No new user model. The auth.md file itself is plain Markdown — discoverable at https://yourapp.com/auth.md, parseable by any agent that can read documentation. The protocol layers on top of standards you already have. The lift to integrate is five steps and a few dozen lines.

The Number One Problem

Authentication is actually the entry point to a bigger problem: how does an agent-accessible service establish trust, issue credentials, and eventually handle payment?

Right now, most SaaS assumes a person is clicking "Subscribe" somewhere. An agent can't do that. It can't fill in a credit card form. It can't reason through a pricing page and select a plan. The "customer journey" is entirely human-shaped, which means the moment your customer is an agent, the entire onboarding funnel is broken.

Auth.md solves the authentication layer. Payment and billing for agents is a harder problem still unsolved — but it's the natural next step once authentication is a primitive. Who pays for the agent's API calls? Is it the user on whose behalf the agent acts? Is it the agent platform? How does a service know which organizational billing context to attach to a credential issued to an autonomous process?

These are the questions that emerge once you accept the premise: agents are your new customer. Not a stretch goal. Not a 2030 problem. Now.

Rethink Your Customer

I'm not alone in building things agents need before having the vocabulary for it. I hear versions of this story regularly from engineers who've been quietly adding agent-friendly endpoints, building fleet-management tooling, or designing consent models for governed agent systems that have no analog in the human-centric playbook.

The vocabulary matters. Not because you couldn't build without it — clearly you could — but because having it changes what you reach for. It changes how you pitch. It changes who you're building with. "This is agent-first infrastructure" is a different conversation than "this is a developer tool with an API." It signals a different design orientation, a different set of tradeoffs, a different kind of early adopter.

Auth.md gives us a shared language. A spec that says: yes, this is a real problem, here are the flows, here's the primitive, build on it.

If you're reading this and something in you is going yes, that's the thing I've been feeling — you're not alone. The shift to agents-as-customer is already happening. You might have been building for it without naming it. That's fine. You're not behind. You're in it.

The Bottom Line

WorkOS's Auth.md is one of the most important developer primitives to ship in the agent era. Not because it's complex — it's deliberately simple. Because it's the first standardized answer to "how does an agent authenticate to a service it's never seen?" on top of standards we already trust.

More importantly, it named a category.

"Agents are your new customer" isn't hype. It's a reframe of something that's already true for a growing number of services. Auth.md is the infrastructure that makes that sentence actionable — something you can implement today, not something you wait for a platform to do for you.

I'm building in this space. If you're building in this space, or starting to feel the pull toward it, the vocabulary is here. Start from the Auth.md spec on GitHub. Publish your auth.md. See how your service looks through the eyes of an agent trying to get in the door.

You might be closer to agent-first than you think.

---

Relevant context from my own work: Stop Connecting Your Agents One by One — MeshWire's origin story. Hookflows: Governed Git for AI Agents — building governance for agents, not humans. Three Layers Your AI Agent Is Missing — the infrastructure gap that makes agent-first systems hard.