Insight
Designing for AI
I've always designed for a person on the other side of the screen. More and more, the user is an agent working for that person, and it doesn't want the screen. It wants an action it can call, with the inputs, permissions and failure states clear 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.
When we started letting an agent build the submission at Ennabl, the first thing I noticed was that it never opened the form. It pulled the loss runs, matched the account against carrier appetite, filled in the carrier and the effective dates and the loss history, and saved. I had spent weeks on that form. Which fields go together, how a producer reads down the page, where the Save button sits, what shade of blue. The agent didn't look at any of it.
It needs four things instead. What the action is called. What it takes and what it returns. Whether it's allowed to run it. What happens when it fails. That's the whole list. Everything I had designed was for a pair of eyes, and this thing has none.
My first instinct was to keep designing the screen and add an API afterwards. But when the agent is the main user, the API is the interface. The names of the actions are the copy. The declared actions are the buttons. The failure states are the empty states. If I write them carelessly, the agent gets stuck exactly where a confused person would, except it can't squint, ask a colleague, or file a ticket.
It's hard to let go of the idea that the screen is the deliverable. It was true for my whole career. But a growing part of what I design now is read by something with no eyes, and it judges the work on whether it can act, not on what it can see.
These days I write the action first, name, inputs, what comes back, what fails, and draw the screen after. I don't always manage it.