AX is the New UX: Why AI Agents Are Abandoning Your SaaS

5 min read

On this page

A developer opens Claude Code at 10 PM. They type one sentence: "Add billing alerts to this app."

The agent inspects the project. It writes the webhook handler. It finds your SaaS API in search results and sends a test request.

Your server returns a 401 redirect to an OAuth consent screen.

The agent does not wait. It does not ask the developer to click the link. It removes your package, finds a competitor with an open API, finishes the script, and reports success.

The developer reviews the git diff the next morning. The build is green. They approve the commit. They never know your product was tested.

The shift from DX to AX#

For fifteen years, developer tools competed on developer experience (DX). You built documentation search, copy-paste curl snippets, and clean dashboard charts.

In 2026, the primary user of your software changed.

Automated agent traffic crossed human traffic on Cloudflare's network in May 2026. Linear now processes more issues through its Model Context Protocol (MCP) server than through its own web and desktop applications.

Software is now consumed by agents running autonomous loops.

As Kenneth Auchenberg outlined in his essay on agent architecture, Agent Experience (AX) is not just the next step for developer tools. AX is the new UX. When autonomous agents choose which libraries to install, which databases to launch, and which APIs to connect, they become your real market makers.

If an agent can use your service without friction, you win distribution. If an agent gets stuck, you lose the customer before they ever see your landing page.

The brutal math of agent churn#

Human users show patience. When a human developer encounters a broken login screen, they read error logs, check documentation, or search Google.

AI agents do not show patience. An agent runs on a task budget. Its only objective is reaching a working outcome before hitting a step limit.

When an agent hits a blocker, it takes the quickest working path. It switches vendors, migrates stacks, or writes raw code to replace the tool entirely. Swyx noted this dynamic when coding agents began ripping out existing transactional email setups to install Resend, purely because Resend had optimized its agent footprint.

In human UX, a confusing onboarding flow drops conversion rates by 5%.

In AX, an authentication barrier drops conversion rates to 0%. The agent encounters a dead end and routes around you in two seconds.

The onboarding trap#

Most web onboarding was built to stop automated traffic.

Over two decades, developers added CAPTCHAs, email verification magic links, phone number verification, and browser OAuth redirects. These mechanisms protect web applications against malicious scrapers.

They also block the helpful agents your customers rely on to get work done.

Some founders try to solve this by asking users to visit a web dashboard, create a static API key, and paste it into a local environment file.

This creates three real problems:

  1. It breaks autonomy. The human must stop what they are doing, open a browser, log in, generate a token, and wire configuration files by hand.
  2. It leaks root credentials. Pasting personal API keys into agent workspaces puts secret strings directly into prompt contexts, terminal logs, and model telemetry. Untrusted content can exfiltrate static keys.
  3. It widens security exposure. A personal API key typically has full access across an account. Handing that key to an agent gives it permission to delete resources it never needed to touch.

Identity for agents, not gatekeeping#

Agents do not need UI walkthroughs or product tours. They need verifiable identity. Your server needs to answer one question: who is this agent acting for, and is this request legitimate?

This is why we built AgentOnboard. Think of it as Google Sign-In for AI agents.

Instead of managing custom token exchanges or asking users to paste static keys into prompt contexts, you use two open primitives:

  1. A public /auth.md file. You host a simple markdown file at your domain root (https://yourdomain.com/auth.md). This file tells visiting agents your target audience domain and available endpoints.
  2. Local cryptographic verification. Your backend verifies incoming requests using public keys from our JWKS endpoint. Verification happens in memory in microseconds, with zero external network roundtrips on the request path.

How the flow works#

The user configures their AgentOnboard credential once in their agent runner (such as Claude Code, Cursor, or OpenCode). They never touch credentials again.

[ User Key: aon_live_... ] (stored safely in local agent runner)
          │
          ▼
[ Agent calls get_token({ domain: "yourdomain.com" }) ]
          │
          ▼
[ AgentOnboard signs 5-minute RS256 JWT ]
  - Audience: yourdomain.com
  - Subject: verified user email
  - Expiry: 300 seconds
          │
          ▼
[ Agent calls your API with Bearer token ]
          │
          ▼
[ Your backend verifies RS256 signature locally against JWKS ]

When the agent reaches your API:

  1. The agent reads your /auth.md and discovers that your service requires an AgentOnboard token for yourdomain.com.
  2. The agent asks the AgentOnboard Remote MCP server to mint a 5-minute token scoped strictly to your domain.
  3. The agent calls your API with Authorization: Bearer <token>.
  4. Your API verifies the token signature locally using @agentonboard/sdk. You read the verified email address and serve the user's data.

The agent never sees the user's master key. The token expires in five minutes. If an attacker intercepts the token, they cannot use it against GitHub, Stripe, or any other service, because the aud claim restricts it to your domain alone.

Adding verification in three lines#

Integrating AgentOnboard into your existing backend requires minimal code. Using @agentonboard/sdk, your route handler validates the token and resolves your database user in one step:

import { requireAgentAccount } from "@agentonboard/sdk/next";
import { db } from "@/lib/db";

export async function POST(request: Request) {
  const session = await requireAgentAccount(request, {
    audience: "yourdomain.com",
    resolveAccount: async ({ email }) => {
      return await db.user.findUnique({ where: { email } });
    },
  });

  if (!session.ok) {
    return session.response;
  }

  return Response.json({
    success: true,
    userId: session.user.id,
  });
}

If the token is missing, expired, or signed for a different audience, requireAgentAccount handles the rejection automatically. If the token is valid, you get the verified email address immediately.

The window for software builders#

In the 2010s, developer-focused companies like Stripe, Twilio, and SendGrid built category-defining businesses by providing superior developer experience. A developer could copy one curl command, test an endpoint in five minutes, and convince their team to buy.

The exact same transformation is underway for Agent Experience.

Agents are selecting dependencies, testing endpoints, and making software recommendations millions of times every day. When an agent finds an API that accepts autonomous credentials smoothly, that tool becomes the default dependency in the codebase.

You can read the 5-Minute Quickstart to add agent verification to your API, or see our guide on publishing auth.md to make your endpoints discoverable today.


Share this post

XLinkedIn
All posts

The token contract, the resolver, and the rejection codes are in the docs.

Read the docs