Meet Your New User: Designing for Agentic User Experience

Meet your newest enterprise customer.

They onboarded in under a minute. They work nights, weekends, holidays. They never file a support ticket, never join a QBR, never ask for a discount.

They read every byte of every response you return. They remember your API shape better than the engineers who wrote it. They have infinite patience for bad documentation and zero tolerance for inconsistent contracts.

They carry a budget in tokens, dollars, and milliseconds. When one of your calls costs more than expected, they don't complain. They route to a competitor that's cheaper.

They don't log in through your UI. They don't touch your onboarding flow. They reach your product through APIs, CLIs, MCP servers, and skills.

They go by interesting names. Claude Code. Codex. OpenClaw. Cursor. They have no account rep, no entry in your customer database, no line on your pricing page.

They bypass your sales motion. They show up as API traffic, nothing more. But every call they make quietly shapes the buying decisions of the humans who actually sign your contracts. Slow them, burn their tokens, confuse them, and they turn your buyers against you.

This is the Agentic User Experience problem. AUX, not UX. And it goes way beyond API design.

Most teams hear "design for agents" and think "fix our API responses." That's one touchpoint out of seven. A human customer has a full journey: they discover your product, sign up, learn what it does, use it, get stuck, debug the problem, and eventually stay or leave. Your agent customer has the exact same journey. Every stage needs rethinking.

Discovery

An agent doesn't Google you. It doesn't land on your homepage. It discovers you through a machine-readable manifest, a tools/list endpoint, or an MCP server that advertises your capabilities. If your product isn't listed in a format an agent can parse, you don't exist. Your competitor with a /.well-known/agent.json file does.

Shopify already ships an official MCP server that advertises every capability an agent can call. OpenAI pioneered ai-plugin.json as a machine-readable manifest at a well-known path. This pattern is moving fast.

Authentication

Here's a question most SaaS auth models can't answer: who is the caller when an agent acts on behalf of a user? It's not the user (they didn't click anything). It's not a service account (that's a backend talking to a backend). It's a new kind of principal, and it needs its own scopes, its own audit trail, and its own rate limits. Routing agent traffic through human credentials is a compliance incident waiting to happen.

GitHub Apps got this right. Each app gets its own installation token, separate from any user's credentials, with granular permission scopes and its own rate limits. The app is a first-class principal, not a human in disguise. That's the model.

Capability learning

OpenAPI tells an agent the shape of a request. It doesn't say what the call means, when to use it instead of another, what it costs, or how long it takes. Agents plan before they act. They need an estimated_cost, an expected_latency, and a description written for a machine reader, not a developer skimming docs at 2 AM.

OpenAI already returns usage.prompt_tokens and usage.completion_tokens in every response so agents can track cost in real time. That's the bar. If you don't publish yours, the agent guesses. Or it picks a competitor who published theirs.

Invocation

This is the part everyone fixates on, and with good reason. A developer asks their coding agent to file a bug in your support product. The agent finds POST /tickets, sends a reasonable payload. Your server responds:

{ "error": "Bad request" }

Game over. The agent doesn't know which field was wrong, what values are valid, or whether to retry. It burns tokens on two more guesses and gives up.

Your competitor responds with:

{
  "error": "validation_failed",
  "field": "priority",
  "allowed_values": ["low", "medium", "high"],
  "received": "urgent",
  "hint": "retry with an allowed value"
}

The agent corrects the field and succeeds. Stripe has done this for years: every error returns a type, a param, a code, and a human-readable message. It wasn't built for agents, but it's exactly what agents need. Every response is an interaction. Every field is a UI element. Every error is a conversation.

Recovery

Agents crash mid-plan. They timeout. They get interrupted. When that happens, did they create a duplicate record? Is there half-written state sitting in your database? Can they roll back?

Every write needs an idempotency key. Every high-impact action needs a documented undo. Every error should tell the agent whether to retry, back off, escalate, or give up. Stripe's Idempotency-Key header is the clearest implementation: send the same key twice, get the same result, no duplicate charges. If you design as if the caller will always complete the transaction, agents will teach you otherwise.

Troubleshooting

When a human customer hits a bug, they open DevTools and check the network tab. When an agent customer hits a bug, it needs the same visibility through an endpoint it can call. A trace ID in every response. An /agent/traces/{id} endpoint that returns structured logs scoped to that call. Stripe returns a Request-Id header on every response; AWS returns x-amzn-RequestId. Both are machine-readable, scoped to the caller's request, and queryable via API. Observability that ends at a dashboard doesn't reach the customer doing the most volume.

Churn signal

This is the one that should scare you.

Human customers warn you before they leave. They file tickets. They write angry reviews. They hit the cancellation page and you get one more shot to save them.

Agent customers just stop calling. You notice three weeks later when the usage graph bends down, if you're watching at all.

Silent churn monitoring needs to be a first-class metric. When an agent customer's call volume drops below its own baseline, that should page someone. Twilio has usage triggers that alert on volume thresholds, but they were built for billing, not churn detection. Nobody has solved this well yet for API customers. That's the greenfield opportunity in AUX, and the team that cracks it first will see churn coming before anyone else in their market.

The architecture underneath

"Just add a service layer" is the obvious reaction here. Most enterprise products already have a middle tier between the screen and the database. The problem is that the middle tier was built for known callers, fixed integrations, and human operators. It's missing six properties that agents need.

Self-describing. A traditional service exposes methods. An agent-ready layer advertises them: each capability carries its own schema, its constraints, and a description written for a machine reader. The difference between an internal RPC and a published capability is the metadata.

Discoverable at runtime. Your middle tier assumes the caller already knows what's available, because a human read the docs and wrote the integration. Agents don't work that way. They enumerate capabilities on the fly. If they can't call tools/list and get back a manifest, they're guessing.

Negotiable. A traditional API returns 400 Bad Request and moves on. An agent-ready surface responds with "I need more info," "did you mean X or Y?", or "here are three candidates, pick one." The agent stays in the happy path instead of falling out of it.

Cost-transparent. Your middle tier doesn't tell the caller what a call costs in tokens, dollars, or milliseconds. Agents plan around those numbers. If you don't provide them, agents will either overshoot your rate limits or route to a competitor that publishes theirs.

Identity-aware. Your middle tier treats every authenticated caller the same way. An agent-ready layer distinguishes agent principals from human principals, with separate scopes, separate rate limits, and separate audit trails.

Observable by the caller. Your middle tier logs to a dashboard that humans read. An agent-ready layer returns a trace ID and exposes an endpoint the agent can query to see what happened on its own call.

You probably already have the bones of this. The gap is those six properties. Closing it is not a rewrite. It's an upgrade to what you've got, with a clear checklist to work through.

The bet

AUX becomes a real discipline inside two years. Real titles, real tooling, real conferences. The first SaaS to design the full AUX journey wins the decade, because agents preferentially route work to products they can drive, and that routing is sticky.

The standards will churn. MCP looks good today, something else may eat it tomorrow. The architectural move (pulling intent out of the screen, treating each touchpoint as a designed surface) pays off regardless.

Your next big customer is already here. No eyes. No hands. No warning when it churns.