Agent interfaces arrive in capability jumps

You’ve probably seen the reassuring version of agentic design advice by now. Agents are just a new kind of user, so design for them the way you’d design for anyone: clear labeling, semantic HTML, predictable structure, the same accessibility basics that already make a page work well with a screen reader. Nielsen Norman Group, the UX research firm that’s been shaping this argument, frames it as evolution, not revolution. No paradigm replacement required. Just a wider audience for principles you already have.

That advice isn’t wrong, exactly. But it describes only part of what’s happening, and treating it as the whole picture will cost you.

Look at what actually shipped between late 2025 and mid-2026: four genuinely new interface categories, one after another. Skills, where an agent executes an instruction on its own. Projects, which preserve context across sessions instead of starting cold each time. Artifacts, standalone output objects a person and an agent can both work on. Memory, a model that retains a persistent picture of who you are across conversations. None of these are a familiar pattern made a little friendlier for a new audience. Each one became possible only once a model crossed a specific reliability threshold, executing reliably enough, or persisting context reliably enough, to support it. Before that threshold, the category simply didn’t exist to be designed for.

Existing UX principles govern how well you design inside a paradigm. They have nothing to say about whether the paradigm exists yet, and that second question is the one gating your roadmap.

There’s a second version of the same pattern at a different scale. Early in 2026, agent systems shifted from modular, one tool call at a time, to orchestrated, multiple agents coordinating with each other. That changed what design even means at that layer. It stopped being about composition, wiring one tool call to the next, and became about governance: one agent now has to reason about another agent’s behavior and hand-offs. Nothing in the “agents are just users” framework anticipated that a design problem like this would even exist, because no version of human-facing interface design has ever needed one agent to model another agent’s choreography.

The same threshold logic explains something else that looked strange at first: why command-line agents overtook visual, IDE-style suggestions as the dominant interface for AI coding, instead of the other way around. The researcher Andrej Karpathy has a rule for this: AI automates fastest wherever its output can be checked automatically. A terminal command either exits clean or throws an error, a verification signal built into the medium. A visual or creative decision usually needs a person to judge whether it’s actually good. So the terminal paradigm matured first, not because anyone designed it that way, but because it was the domain where the model could prove itself fastest. The expectation going in was that interface innovation would lead capability, that designers would push models toward new use cases. The evidence says the opposite: capability crosses a line, and only then does a matching interface become viable.

None of this contradicts Nielsen Norman Group’s advice. It just means their advice answers a narrower question than it’s being asked to answer. Once Artifacts exist as a category, yes, design one well: label it clearly, make it predictable, resolve the tension between what a human reader needs and what an agent parsing the same object needs. That work is real and the existing principles are the right tool for it. But whether Artifacts, or the next category after Memory, should exist yet at all is a different question, and it isn’t a design question. It’s a capability question, and the honest answer is often not yet.

That’s the distinction worth sitting with if you’re planning a roadmap right now. Two frameworks have been sitting next to each other as if they agreed, one saying the paradigm is stable and you’re just widening its audience, the other saying the paradigm itself replaces discontinuously whenever the model clears a new bar. They can both be true, at different altitudes. Inside a paradigm, the old principles hold. Between paradigms, they tell you nothing, because no amount of accumulated best practice produces the next category on its own. It has to be earned by the model first.

The operational move that follows is almost embarrassingly simple, which is probably why it gets skipped: before you invest in polishing an agent-facing feature, ask which paradigm you’re actually in, and whether the model underneath it has crossed the threshold that makes the next one real. Polish spent on a category the model can’t yet support reliably isn’t craft sitting ahead of the curve. It’s UX debt you’ll have to unwind once the ceiling moves and the category changes shape under you.

So the open question isn’t whether existing UX principles are wrong. They aren’t. It’s narrower and harder to sit with: is there a way to tell, before the model crosses a threshold, which capability is about to arrive next, or does that only become visible in hindsight, once the category has already appeared and someone writes the retrospective explaining why it was obvious all along? Right now, nobody can answer that with real confidence. Until someone can, the safer move is to keep asking the capability question before you ask the design one.