Ask an agent to tidy up a folder of exported assets and it will. It renames the files using a convention you mentioned once, moves them somewhere reasonable, and reports back. Now look at what the interface lets you do about the result: type another sentence.
Fix this. Try again.
That is the entire repair vocabulary of a conversation. One move, after the fact, in words. It was enough when the worst outcome was a mediocre paragraph. It stopped being enough the moment these systems started doing things to files, calendars, inboxes and orders.
Chat is not the problem. It is the default: the surface that survives when nobody makes a decision about the interface.
The job changed underneath the craft
For most of its history, UX design has been about operation. Screens, navigation, workflows: making a system a person can run. I have worked at the strategic end of that for years, deciding what a product should do and for whom rather than what the button looks like, and the object of the work was the same either way. Something that waits to be told what to do.
That is the part that changed. We now design systems that interpret intent, adapt to context, make recommendations and act on someone's behalf. Once software acts, the design question stops being how a person operates it. It becomes how authority, initiative, knowledge and responsibility move between a person and a system.
Which makes designers something closer to architects of trust, a phrase that sounds grander than the daily work actually is. Most of that work is deciding where a confirmation step goes.
Six jobs, one channel
A conversation carries a lot. Stating intent, supplying context, setting constraints, steering mid-run, giving feedback, revising the result. Six different jobs, one text field, everything expressed in sequence and in the user's own words. Prompt engineering is the evidence. When Zamfirescu-Pereira and colleagues watched non-experts try to write prompts for a CHI paper in 2023, the people did not fail because the model was weak. They failed because the interface left the whole translation job to them. An entire practice grew up around compensating for that. Where a product offers a property panel or a set of persistent constraints instead, the need for the skill quietly disappears.
The second cost shows up once the system does more than answer. One sentence in, a paragraph out, and everything in between stays invisible: retrieval, tool calls, the drafts it discarded, the sub-agents it spawned. That was tolerable when the gap was one generation wide. With agents it is not. The more that happens between instruction and result, the more expensive invisibility gets.
None of this is an argument for removing chat. The best products have already worked that out. Perplexity shows the sources behind a claim. Cursor shows you an editable plan before it touches your files, and has done since Plan Mode shipped in October 2025. Those are interface decisions rather than model decisions, and they are a large part of what separates those products from the ones that ship a text box and hope.
Adoption rose through the second quarter1, though the sample skews enterprise2.
Citation Trail
Every claim carries its source.
Read the three source files
Rename the exported assetsedit
Delete the originals
Write the summary
Editable Plan
The plan is a document before it is an action.
Prefers metric units×
Works in Berlin×
Dislikes long replies×
AI Memory
What it remembers, and a way to take it back.
So the patterns exist. What they lack is names. A pattern nobody has named cannot be put in a ticket, compared against an alternative, or defended in a review, so every team quietly rediscovers its own version and nothing accumulates.
Transparency is a question of timing
Everyone claims transparency. Almost nobody says which kind, which is why the word has stopped doing any work.
The lens I use breaks it into four conditions and calls them DOPE: directability, observability, predictability, explainability. A stupid acronym I have stopped apologising for. Trustworthy autonomy is the overlap.
Observability
see what the system thinks
Directability
steer in real time
Predictability
know what comes next
Explainability
understand why it decided
What the diagram does not show is that three of the four are separated by time. Predictability is what you ask before the system acts: show me the plan, not the result. Observability applies while it acts: a visible state, not a spinner. Explainability comes afterwards, when the decision has to be reconstructed for a customer, an auditor, or yourself.
Directability is the odd one out. It is not about seeing anything. It is whether you can still change what happens, and it expires the moment the system finishes.
They fail independently, and that is the part worth keeping. A system can narrate every step it takes and still leave you unable to say why it took that route. Another can explain its reasoning beautifully and give you no way to stop it halfway.
Here is where I part company with most of the transparency discourse. Explainability is the axis everyone argues about, and it is the one that changes the least. It arrives after the fact. By then the email is sent, the file is changed, the order is placed. Directability and observability are the pair that can still alter the outcome while it runs; predictability buys you the chance to act earlier; explainability documents what you no longer get to change. Rudin made a version of this argument for machine learning in 2019: an explanation bolted on afterwards is not the same thing as a system you could understand beforehand. A study from Microsoft Research and the University of Washington this year makes the point better than I can: a better interface for an agent's action trace made participants faster at finding errors and noticeably more confident, and their final accuracy did not meaningfully improve. The trace reassured. It did not protect.
The part that didn't survive
I have been collecting these patterns for a year. Eighty of them now, each one built as something you can click rather than read about, and each sitting next to the chat version of the same job so the trade-off is visible instead of asserted.
Seven of them have no chat version. I found that out by trying to build one.
Task Bid Market. Oversight Rhythm. Critic Gate. Concurrency Dial. Patterns for the situation where several agents are running at once and somebody has to decide who takes which job, in what order, with how much authority. There is no conversational version of that to compare against, because a conversation has one speaker at a time and these situations have five. I had built the library on the premise that chat is the thing every pattern improves on. Then seven patterns turned up where chat was never in the room to begin with.
The library
the chat version of the same job
to compare against
When I counted the whole library against that question in September, the seven turned out to be the visible edge of something larger. Thirty of the eighty patterns stop working once the person leaves the loop, and they are not scattered at random: fourteen of the sixteen inline patterns fall away, because every one of them puts your hand on the thing while it happens. Chat was never in the room for the seven. For the thirty, nobody is in the room at all. The comparison I built the library on assumes someone present, and a growing share of the library describes situations where that assumption is the first thing to go.
What I don't know
Whether all four conditions are actually necessary.
I have been writing as though they are, and the sentence I keep repeating, that trustworthy autonomy requires all of them, is one I have never tested. It is plausible that a system with genuinely excellent predictability needs very little explanation afterwards, because nothing it did was a surprise. It is equally plausible that directability without observability is worse than no control at all, since you would be steering something you cannot see, which is roughly how Bainbridge described the ironies of automation in 1983 and how a paper by Mitchell, Ghosh and Passi described agent oversight this August: prolonged reliance erodes the very abilities that oversight depends on. That is the question my research is stuck on right now, and I would rather say so than keep asserting the four-part version because it is tidy.
Where this leaves the work
If you are building something that acts on a user's behalf, the useful move is rarely a better chat. Ask which of the four conditions your feature currently fails, then design the smallest thing that answers it. An intent preview. An approval gate on the one step that cannot be undone.
And keep a note of the patterns where the comparison breaks down entirely. Seven out of eighty, in my case, and thirty if you count the ones that only work with someone watching. That is the part I did not expect when I started counting.
The count of thirty comes from Designing for Agents; the six-jobs argument is laid out at length in Why Chat Breaks. Every pattern named above is a working demo in the catalog, the ones I got wrong included.
Drafted with Claude. Argued, cut, rewritten by me.