Not every AI feature should be a chat

The same enterprise that lets AI silently categorise a million support tickets will refuse to let an AI assistant touch the layout of one slide. From outside it looks inconsistent. It’s a precise read on where AI is safe to depend on, and the chat box sits on the wrong side of that line more often than chat-first design assumes.

Watch what enterprises approve. They hand AI the invisible, high-volume work: routing tickets, tagging transactions, flagging anomalies, deduplicating records. Millions of decisions a day, no human in the loop, complete trust. Then watch what they hold back: the hands-on, reversible work a person was doing themselves a minute ago, like editing the document, adjusting the design, changing the number in the cell. There they want their hands on the controls. That’s a sensible judgement about which surface suits which task, and it has nothing to do with being scared of AI.

Two questions decide the surface

The surface for an AI feature should fall out of two properties of the task rather than out of what’s fashionable to ship.

The first is how much trust the task requires. Categorisation is forgiving at scale, because one misrouted ticket in a million is noise and the aggregate is what matters. Moving an element on a customer’s slide is unforgiving and singular, because there’s no average to hide in and the one wrong move is the entire experience. Tasks with no tolerance for error want the user’s hand on the wheel. High-volume background tasks are exactly where you let the AI run unattended.

The second is how reversible the action is. A categorisation that runs in the background is reversible by definition: re-run it, correct the tag, nothing was staked. Directly manipulating something the user is actively working on has immediate, visible consequences they then have to live with. The more reversible and invisible the work, the more autonomy the AI can safely have.

Where chat earns its place

Chat is a good surface for one particular shape of task: open-ended and exploratory, where the user doesn’t know yet what they want and a wrong turn costs them another message. “Help me think through this”, “what’s in this dataset”, “draft me three options”. The ambiguity is the point, and a conversation is a good tool for resolving ambiguity.

The fashionable AI design tools show what happens when you force everything else into that shape. “Chat, move this box five pixels left” is slower, vaguer and riskier than the direct control it replaced. You type a sentence, wait for a generation, and then find out whether the model understood you. The old way was to grab the box and move it, with your eyes closing the loop as you went. It’s also all-or-nothing: you get the model’s entire interpretation back at once, and if it’s 90% right you’re now editing its guess rather than expressing what you wanted. A precise, reversible, hands-on task got wrapped in an imprecise, slow, all-or-nothing interface, which puts distance between the user and the thing they were trying to do.

How wide is the space?

Those two questions are about how much autonomy a task can take. A third question sits on a different axis and decides how much an LLM is buying you. How wide is the space of inputs and outputs the feature has to cover?

You build a traditional control by anticipating that space in advance. Every option, every edge case, every state has to be foreseen and given a component, and whatever you didn’t build, the user can’t do. That foresight is most of the cost of software, and it’s why narrow, well-understood tasks get clean controls while sprawling ones get a thin UI or none at all. An LLM broadens the interface without you building any of it, because it takes an input you never enumerated and produces an output you never designed a screen for. That’s the trade. When the space is too wide to enumerate, you were never going to build a control for every way someone might ask for the chart they want, so language carries the range. When the space is narrow, the model is selling you breadth you don’t need and charging latency, an unpredictable result and a full round-trip for it.

The answer also moves within a single feature. Generation is wide, because you don’t know exactly what you’ll get, so an open interface fits. Editing is narrow, because you know the precise change you want, and pushing it back through a stochastic round-trip to move one line is slower and less certain than doing it yourself. The same feature wants a broad interface to create with and a direct one to refine with. Good ones switch at that seam instead of trapping people in a conversation for work their hands could finish in a second.

A decision rule

Before defaulting an AI feature to chat, run it through four questions.

When the answers point right, the better surface is a button, a toggle, a slider, or an inline suggestion the user accepts or rejects in place. A button has no ambiguity to misread. A toggle reverses instantly. An inline suggestion lets someone see the proposed change against the real thing and take it or leave it without a round-trip through a sentence. Those surfaces give the AI exactly as much autonomy as the task can bear.

Match the surface to the task

The chat-first default treats conversation as the universal interface for AI, and for a real slice of tasks it’s the right one. The mistake is reaching for it everywhere, including the places where a direct control would be faster to use, safer to trust and easier to reverse. Where you land depends on how much trust the task demands and how reversible the action is, and sometimes that lands on a conversation and sometimes on a button.

Pick the surface the task is asking for. Often it’s quietly asking for a button.