For thirty years we designed software for one kind of user: a person with eyes, a cursor, and patience. Every button, label, and empty state assumed a human on the other end. That assumption is quietly breaking.
Increasingly, the thing using your software is an agent — a model that reads, decides, and acts on a business’s behalf. It doesn’t scan a page; it parses it. It doesn’t get bored; it retries. Designing for it well is a different craft, and most teams haven’t started.
The user can’t see
A human forgives a vague label because context fills the gap. An agent can’t. When the user is a model, the interface has to be legible to a machine first:
- State is explicit, not implied. “Loading…”, “done”, “failed — here’s why” beat a spinner that means nothing to a parser.
- Actions are named, not just drawn. An agent acts on structure and semantics, not pixels and vibes.
- Errors are recoverable. A good error tells the agent what to try next, not just that something broke.
None of this hurts human users. It tends to make the product clearer for everyone — which is the quiet bonus of designing for agents.
Keep the human in the loop
An agent that acts 24/7 is powerful and, unsupervised, a little dangerous. The interface’s real job becomes oversight: showing what the agent did, why, and giving a person a clean way to step in. The best agent products aren’t the ones that hide the machine — they’re the ones that make its work visible and reversible.
The face still matters
There’s a temptation to think that once agents do the work, the interface stops mattering. The opposite is true. The agent is the workforce; the interface is still the face — the part people touch and trust. When an agent is acting on your behalf, a beautiful, honest interface is what turns automation from unsettling into something you’d actually rely on.
That’s the line we keep coming back to: intent over chaos. Agents bring scale; design brings intent. You want both. If you’re building something an agent will live inside, let’s build it right.
