Agent 时代产品需双入口：为 Agent 设计，也为人设计

The UI is dead. Or so I keep hearing:

"Agents are your users now, software is losing its head, and everyone who learned Figma should start learning Bash."

Maybe the UI is dead in four square blocks of San Francisco (where folks are running multiple Mac minis for clawbots). But I'm a regular person at a screen for most of my day, and so are the people I build for.

Here's my take:

• Everything is a user interface if I'm using it
• My agents are using it too now, just not the part you designed
• Headless is a new layer on top of product building, the same way APIs and the GUI once were

If you're a product builder, congratulations! That means your job just doubled: every user of your product is bringing an agentic plus-one.

Here's a few things to consider in this hybrid (not headless) future.

Your homepage isn't the front door

If you're building for a technical audience, onboarding them into your product increasingly won't start from a "get started" button. It'll start in a terminal or an AI chat window.

This is less true for consumer products, but the pattern is spreading – especially if your AEO game is strong. A new user chatting with Claude or ChatGPT may never see your homepage at all. They'll ask the agent for a recommendation, it'll point them at you, and (with user permission and a good MCP) set up your product right there.

The catch is you can't count on the agent to read your install docs. A capable one might go looking, but plenty won't. So setup has to be something an agent can finish on its own (easy to find, easy to authenticate into, and done in one call instead of ten steps).

Get that right and you've handled the agent, but don't forget the person behind the agent. Expect that, eventually, they'll open the product and need to work out what it does and what to do next. That requires UI, baby!

Design two entry points to your product:

• For the agent: a signup flow it can finish end to end (fork ours, our competitors already have). Also, a listing where agents look for connectors (like the Claude and Codex app directories), docs it can parse (an llms.txt, pages served as plain Markdown), and auth that's safe when it improvises (short-lived, scoped tokens).
• For the human: where you start them depends on how they got there. If their agent set things up, they're landing in the middle of a process, so show them what's been done and what's missing. If they clicked around themselves, just point them at the next step.

What this looks like:

• The fastest way to try PostHog is the npx -y @posthog/wizard@latest command that sets up your account, scans your codebase for what to instrument, and logs each step in your terminal as it goes (here's how we built it). Once it's done, some people continue their PostHog journey headless through the MCP. Plenty of others jump back into the web app (they want to see their data and click around).
• Our Slack app turns a message prompt into a draft PR. I 99% trust it to build things correctly. The 1% difference is why I still check the diff in GitHub (a different UI) before merging it.
• AgentMail's onboarding docs teach the agent to provision an inbox and key itself (no console required). Even there, a human UI is needed, and that UI is email: a six-digit code gets sent to a person. Until a human hands it over, the agent can only send mail to the address it signed up with.

If a human can do it, an agent should too

Mostly, agents don't touch your UI. Some can (computer-use agents like Perplexity's Comet will click around a live DOM), but that's a slow and human-shaped UX (user experience).

What agents need instead is AX (agent experience) – how easily an agent can use your product and recover when something breaks. The current standard for AX is the Model Context Protocol (MCP): you run a server that describes what your product can do, an agent can connect to it, see what's on offer, and interact with your product directly.

Unlike a magician, you do want people looking up your sleeve. If you think your product is agent-friendly, prove it: run it headless and see where a human still has to step in. There are probably more of those moments than you'd expect.

Make sure that for every action there's:

• A way for the agent to do it
• A way for the person to check it got done

What this looks like:

• Vercel's MCP server lets an agent inspect deployments, pull runtime logs, and trigger deploys. When it ships something, the change appears in the human UI too (the Vercel dashboard), with the same logs and rollback capabilities.
• Our own MCP server lets an agent create a feature flag or launch an experiment using your credentials. Changes land in the project's activity log attributed to your account, with the calling agent client recorded alongside it (the x-posthog-client header) so you can filter for changes an agent made rather than a person.

Watch what agents actually do

User frustration leaves marks all over the UI (rage clicks, abandoned forms, chaotic mouse movements) which is why session recordings are a goldmine for product builders. Agents leave none of those marks – they hit your API (not your front end) so pageviews and autocapture don't fire, and there's nothing for a replay to catch.

Agents also fail differently than humans, in ways no error category in a log was built to catch. An agent might invent a parameter, trip validation, hit unexpected permission walls, time out, or hallucinate a tool. Server-side requests like these land looking like any other integration (there's usually a user agent string somewhere), but nothing that captures what the agent was trying to do, and whether or not it succeeded.

We got tired of not knowing, and built MCP Analytics which turns every agent tool call into an event – intent included. That's the most useful signal of all: when an agent reaches for a tool your product doesn't have, that's a feature request written by a robot.

Last month, we tracked close to 10 million tool calls from 31 different agent clients. Behind those calls, real people were building things like this:

• Wired PostHog to send a text message when a certain metric moves
• Shipped an A/B test on a "skip the intro" screen (feature flag, 50/50 split, and all)
• Triaged live production errors like expired magic links and missing auth sessions

Note that what's missing from this work is a not a UI, but the PostHog UI specifically. Those 31 clients like Claude Code, Cursor, Cowork, Linear, Notion all have a user interface. A terminal is a UI. A chat window is a UI. Slack is a UI. Headless PostHog users are still looking at a screen.

How's this for meta: the query I ran to pull those examples showed up, seconds later, as a sample intent in the same dashboard. The tool using the tool.

Instrument agent traffic the way you already instrument humans: tag every call with the client it came from, then watch where agents retry or give up. And enjoy the irony, because the thing you built to watch a swarm of agents who never touch a UI is... a UI. Even here the answer is a screen for a human to interpret.

What this looks like:

• In June, Cloudflare's Radar data showed automated requests overtaking human ones on HTML traffic for the first time, 57.5% to 42.5%, about 18 months earlier than its CEO had predicted. You can read that as the end of the screen if you like. I read it as a lot of people asking for things, then agents going to look at the answer.
• Temporal records every step of an agent's run as a durable event history you can replay and inspect where a loop stalled or repeated itself (UI to keep an eye or your AI).

Build an interface worth interacting with