Essay ·
The door where the designer gets in
Two posts crossed my feed this summer, arguing past each other. One: I don't want to use your agent, I want my agent to use your thing. The other: I don't want your agent either, I want mine efficiently enabled to use your product. They read like opposites. They are the same demand from two seats. Nobody wants the chatbot you bolted into the corner of your product. Everybody wants to bring their own agent and have it get real work done inside what you built. Every product is about to be used by agents. The only open question is how they get in.
Six doors
There are six answers on the table today, and they sit on a line. At one end, headless: the agent never touches your interface. Your code calls their API. Or you stand up an MCP server and hand a configured agent a set of typed tools. Powerful, and invisible; there is no screen, and the human in the loop is a developer. At the other end, bound to the interface: the product ships its own in-app assistant, living in the screen, knowing your whole session, and belonging entirely to the vendor. In between sit the browser-driving approaches. Computer use, where the agent looks at pixels and clicks, zero setup and fragile as a guess. Browser MCP, where it reads the page's structure and works generic tools, better than pixels but blunt: click the third button, not search the drugs.
The UX dimension is the real axis
Line the six up and a second row tells the story the first one hides. Ask who the human actually is. On the headless end it is a developer; in the middle, a power user watching a cursor move or a page change under it; on the bound end, an ordinary product user. Ask what that human sees while the agent works, and whether the agent knows anything about the session they are already in. Then ask the question my discipline should care about most: who designs this experience. For four of the six doors, the honest answer is nobody. The API and MCP paths have no interface to design. Computer use and browser MCP have one, but the agent is scraping it, not being handed it; no one designed the encounter, it just happens to the page. The in-app assistant is designed, carefully, by the vendor, for the vendor's agent, which is exactly the one the user said they did not want.
The door a designer can own
Which leaves one. There is an emerging pattern, a W3C proposal, where the
page itself hands the agent typed tools. The product author writes them.
search_drugs, assess_patent_cliff,
size_market: named capabilities, with types, that do the thing
and show the thing. The agent that calls them is the user's own, carrying
their context and their other tools. There is no setup; you open the page and
the tools are there. And it all runs in the live session you are already
looking at, on your login, on your screen, so you watch it work and can grab
the wheel mid-task. It is the only door where the answer to who designs the
experience is neither nobody nor the vendor. It is shared: their interface,
your agent. That word, shared, is why the work is ours.
I built one to be sure. A replica of the Cortellis drug-intelligence experience, on the same Helix design system my team shipped, wired through 48 typed tools to live data. You ask, in plain language, what obesity drugs are on the market in the US, and the real grid filters itself. You say act as Novo Nordisk, where are we exposed, and the app reorients around a portfolio and builds the view. Then act as Zealand Pharma, and the same questions return completely different answers. By the third question it behaves less like a search box than like a co-pilot in a strategy meeting. None of it is scripted, and none of it is a screenshot trick; it is the agent working the product the way the analyst does, in the open, where both of them can see.
What building it taught me
Three things went wrong in ways that changed the design, and each was a design problem before it was an engineering one.
First: if it is not a tool, the agent cannot see it. We had a good patent drill built as a click in the interface, and in a live session an agent scouting a competitor's patents hit the wall and told the user to go find it on the website. The capability was one click away; the agent had no hands for it. Every affordance a person can reach, the agent has to reach too, or the experience has a hole exactly where a human would have improvised. We audited every capability against the tool list and closed the gaps.
Second: an agent rewrites whatever you give it, so the caveat has to live where it cannot be dropped. Hand an agent a result with a disclaimer in a side field and it reads as boilerplate and disappears; what survives into the sentence the user reads is the confident part. So the limits moved into the field names themselves. A value the agent must qualify is named so it has to say the qualification out loud to use the number at all: claim one of the first filed publication, not granted. The schema became the microcopy. If you have read my essay on designing for the user who has to defend the answer, this is that argument compiled into a type.
Third: the tool helps you look, it never decides. Every expert we validated with drew the same line. The patent analyst: this is triage, not freedom to operate. The dealmaker: the pre-screen never says no, only the team does. So the interface is full of red, amber and green, and every one of them means read this first, never this is the answer. No green ticks. Designing an agent's confidence is as much of the job as designing its capability.
Those workflows, for what it is worth, were not invented at a whiteboard. Each was mined from a research-grounded persona and then validated with that person, usually twice, and fixed until they would trust it. The method that built the personas built the product standing on them.
The seat is still empty
I closed an earlier essay by saying the next seat is where agents meet software, and it is empty. This is the sharper version. Of the six doors an agent can take into your product, exactly one lets a designer shape what happens on the other side, and it is new enough that almost no one is standing in it yet. The rest will be filled by whoever wrote the API client or whoever the vendor assigned. This one is still ours to lose. I would rather we walk through it while it is cheap.
The build behind this: a WebMCP replica of Cortellis on the Helix design system, 48 typed tools on live data · the companion argument: Your next user is an agent · more in the lab