Agent auth, twice

The first time, nobody asked for it. At Real Hire I was building a hiring platform, and by 2025 agents were already making my own work faster. It seemed obvious they'd soon be users of every product I cared about, so I decided ours should be ready before anyone thought to ask. I built an MCP server so an agent could do real work with your account: pull your profile, query open jobs against your strengths and preferences, check on your applications. Then, because "paste your API key into a config file" is not a door you offer real users, I put a proper OAuth 2.1 flow in front of it: PKCE, scoped tokens, a consent screen that says in plain words what the agent may touch. The consent copy said "Claude wants to access your Profile and Applications." Writing that sentence honestly is half the security model.

The second time it was my day job. At Mesa, a San Francisco systems startup rebuilding version control for AI agents, I owned a few surfaces: the Python SDK, an AI code reviewer, my first real systems work inside a Rust filesystem. The MCP server is the one that taught me the most. Twenty-two tools, stateless, an OAuth 2.1 authorization server in front, cancellation threaded end to end so an agent that gives up mid-request doesn't leave work running behind it.

Here's what doing it twice taught me. The best test harness for an agent-facing product is an agent. My loop was to point a coding agent at the server cold. No docs, no system prompt, nothing but the tools. Then watch. What does it reach for first? Where does it stall? Which tool does it use in a way I never predicted, and which "obviously useful" tool does it never touch? You can interview human users. Agents you can just run, again and again, at almost no cost. It's the fastest product feedback I've ever had.

That loop forces a discipline: the instructions have to live inside the tools. If the agent needed context I hadn't shipped in a tool name, a description, or an error message, I treated that as a bug in the surface, not a gap in the prompt. A human gets onboarding, tooltips, a support channel. An agent gets your tool list, once. Either the product explains itself at the boundary or it doesn't work.

Auth stops looking like plumbing, too. A human forgives a clunky login once a month. An agent hits your authorization surface every session. For agent-facing products, the door is the product. "Connects instantly from any client" versus "requires a support ticket" is the difference between being infrastructure and being a demo.

If you're adding agent access to your product this year: the specs are good. Read them before the blog posts. Then hand what you built to an agent with no extra context, and watch. It will tell you what your product actually is faster than any user ever has.