Guide

What Agents Want From Your Product

Agents won't click through your UI, sit through onboarding, or follow your navigation. They look for an API, an MCP server, a CLI, or a skill — or they move on.

The shift from clicking to delegating

Your next wave of users won’t click through your product. They’ll delegate the task to an agent and expect it to get done. That agent won’t sit through your onboarding flow, follow your navigation, or read your marketing copy. It will look for a way in that it can actually use.

The 4 things agents want — and the one they don’t

Agents look for four surfaces: an API, an MCP server, a CLI, or a skill. The one they don’t look for is your UI. If none of the four exist, the agent doesn’t struggle through your product anyway — it moves on to a competitor that gave it something to call.

This isn’t a ranking of which surface is “best.” Different agent types reach for different things. A coding agent working in a terminal will happily use a CLI. A hosted assistant like Claude or ChatGPT needs an MCP server or an API it can call directly. An autonomous, long-running agent may need all three, plus a skill that packages the workflow so it doesn’t have to rediscover it every time. That is the basic shape of the Agent Access Stack.

Why the UI is the weakest option

Most products still lead with their UI, because that’s what humans need. But a UI assumes a visual session, a human clicking buttons in sequence, and a person who can read error messages and course-correct. None of that holds for an agent. If your only door is the UI, agents are locked out — not because they’re incapable, but because there’s nothing shaped for them to use.

What good agent-facing design actually looks like

A few principles show up consistently once you start building for agents instead of just adding AI features on top of what you have. The model controls the flow, not you — that’s the biggest mental shift from designing for humans. A tool’s description isn’t documentation, it’s an instruction the model reads to decide whether to call it — vague descriptions get ignored even when the tool is exactly right for the job. Good instructions state both when to use a tool and when not to — negative cases matter as much as positive ones. Many existing APIs need real redesign for agent and conversational use, not just a wrapper. And agents do better with bulk operations than with being forced through the same call twenty times in a row. Start that redesign with the AI-ready API checklist.

(Principles per Elliot Garreffa and Hanh Nguyen’s “19 Principles for Building World-Class ChatGPT & MCP Apps.”)

What to do next

Audit your own product the way an agent would encounter it. Does it have an API an agent could call blind? Does it have an MCP server, or a CLI, or a skill wrapping any of that? If the honest answer is “just a UI,” that’s the gap to close first — everything else in this stack builds on top of it. If you have hundreds of APIs, use how to determine which APIs to make agent-ready before you start building wrappers.


Next step

Where to take this next

FAQ

My product only has a UI right now. Where do I start?
Start with your API, even a minimal one. MCP servers and CLIs both wrap an API — without one underneath, there's nothing for those surfaces to expose. A UI-only product is invisible to an agent no matter how good the UI is.
Do I need all four surfaces — API, MCP, CLI, and skills?
No. Different agent types use different interfaces — chatbots, coding agents, and autonomous agents don't all reach for the same thing. Start with a solid API, then add MCP or a CLI based on who's actually going to consume it, and layer a skill on top once there's a workflow worth packaging.
We have hundreds of APIs. How do we know which ones to make agent-ready first?
This is one of the most common questions from teams starting this work. There's no universal answer, but a reasonable starting point is: which APIs do your own customers or internal teams already automate around today? Those are the ones agents will reach for first.