Agentic AI Needs a New Kind of UX Designer

Agentic AI is in production. It's making real decisions on behalf of people: financial, medical, operational. And there are no design patterns for it yet.

The patterns for traditional UI are well-understood. Button placement. Form structure. Navigation hierarchy. Error messaging. Accessibility. These exist in design systems, in curriculum, in the shared vocabulary of the field. When you design a login flow, you don't start from scratch; you inherit thirty years of accumulated convention. With agentic AI, almost none of that exists.

When an agent makes a decision, how does it communicate what it did? When? In how much detail? What does it surface? What does it hide? What does it ask permission for, and what does it just handle? Right now, most organizations are answering those questions by accident.

Some teams are building transparency-at-all-costs interfaces: every decision logged, every step shown, every data point visible. The result is overload. People don't understand the system better because of all the transparency; they understand it less. Other teams are going the opposite direction: the agent does the work, the answer appears, trust us. That feels clean until something goes wrong and the person has no idea why the agent decided what it decided. They can't audit it, can't debug it, can't course-correct.

The designers solving this problem are solving it individually. One team builds a "decision audit trail" for compliance. Another builds "confidence score" visualizations. Another builds "explanations on demand." All of them are reaching toward the same thing without a shared vocabulary for it.

The design patterns for agentic AI are being invented right now, in isolation, by the teams that need them most urgently.

There are a few distinct problems worth naming. The first isn't really a transparency problem; it's a decision node problem. The question isn't "how much information should we show?" It's "where in this agent's reasoning does the person actually need to intervene?" Irreversible steps probably warrant a prompt. Ambiguous steps probably warrant an explanation. Routine steps probably warrant nothing. Mapping which decisions trigger which kind of visibility is the actual design work, and nobody has built a pattern for it yet.

The second problem is autonomy calibration. Some people want the agent to be aggressive. Others want it to ask before anything risky. A single transparency model doesn't work. The interface needs to let each person govern how much autonomy they're granting, and it likely needs to do that at runtime rather than only at setup.

The third problem is failure explanation, and not for engineers. It is for the person making the decision. “Request failed: validation error (E102)” is useless. “I could not schedule the payment because the bank routing number needs 9 digits. You entered 8 digits, so I saved this as a draft and stopped before submitting anything. Add the missing digit, then press ‘Resume’ to continue.” is useful. That distinction is not obvious, and getting it consistently right is hard.

None of this is in design school yet. None of it is in any design system as a ready-made component. Whether agentic AI feels like a tool that helps or a system that operates on you will come down to how well these problems get solved. Right now, most of that solving is happening one team at a time, without anyone comparing notes.