Insight

Designing for AI

For as long as there have been interfaces, you designed for a person on the other side of the glass. Increasingly the user is an autonomous agent acting on someone's behalf — and it doesn't want your screen, it wants a named action it can call, with the inputs, permissions, and failure states spelled out well enough to trust.

Today: the human is the endpoint

A producer signs in, reads the dashboard, and the dashboard talks to the API. Every path runs through a screen built for a pair of human eyes; the interface is the destination.

Tomorrow: the agent is the endpoint

Same platform, but the screen drops out of the middle. An agent calls the API directly, gets structured content back, and runs the workflow — no dashboard rendered, because no one is looking at one.

The button becomes a contract

"Click Save" was enough when a person aimed the cursor. For an agent, Save has to be a declared action — Save Submission, with named inputs, outputs, permissions, and failure states — because the thing calling it can't read your layout, only your contract.

A few years ago, when a producer put a submission together, the work happened on a screen. They'd open the form, fill in the carrier, the effective dates, the loss history, and hit Save in the bottom-right corner. The interface earned its keep by arranging all of that for a human: fields grouped the way a person reads them, the primary button blue and obvious. Everything was optimized for the one set of eyes pointed at it.

Now an agent does the prep. It pulls the loss runs, matches the account against carrier appetite, assembles the submission, and saves it — and never once looks at the screen. It doesn't care that Save is bottom-right or what shade of blue. It needs four things: what this action is called, what it takes and returns, whether it's allowed to run it, and what happens when it fails. The pixels are irrelevant; the contract is the product.

It's the same everywhere the agent shows up — a booking platform whose next big customer is a travel-planning AI, a CMS whose most frequent reader is a retrieval system. The tempting move is to keep designing the screen and bolt an API on afterward. But when the agent is your primary user, the API is the interface: the semantic labels are the copy, the declared actions are the buttons, the failure states are the empty states. Design them carelessly and the agent stumbles exactly where a confused person would — except it can't squint, ask a colleague, or file a ticket.

The instinct that the screen is the deliverable dies hard, because for thirty years it was true. But the most important user of what you design increasingly has no eyes at all — and it judges you on whether it can act, not on whether it can see.

Design the action, not the button.