For three years, the same scene has been playing out across business products: a small bubble appears in a corner of the screen, you click it, a text area opens. Hi, how can I help you today? The product has become "AI ready." Except it really hasn't, and nobody actually uses it beyond the first few tries.
The problem doesn't lie with LLMs. It lies with the fact that nobody has yet found the right form of conversational interface for a business application. And until we clearly define the constraints, we'll keep recycling the laziest pattern in AI design: the empty text field.
A well-designed form beats a chat on almost every criterion that matters in a business application. First, it shows the available options, which lets users naturally discover what they can do and build their knowledge as they go. Second, it constrains input: fields expect a certain data format and immediately give feedback on what's valid or not, which is reassuring for the user. Finally, it's fast to use, because clicking is faster than typing. In short, it offloads cognition: the user recognizes, rather than formulates.
A single, empty text field, even backed by an LLM, is the exact opposite. It has the effect of a blank page: no affordance, no guarantee on what phrasing will be accepted, slow to fill in, and a high cognitive cost to translate intent into a sentence. What may be viable for the general public in an exploratory mode simply doesn't work for a professional repeating the same operations over and over, and for whom cognitive effort needs to be directed elsewhere.
Yet the desire to integrate an LLM is entirely legitimate, because it brings something no classical interface can provide at a reasonable cost.
What an LLM does, and what no one would re-implement in code without investing months, is transform vague human expression into strict, structured data. It is potentially a very effective coercion adapter between the way people think about their intentions and the way APIs actually accept them.
Concretely, an LLM natively absorbs:
Fuzzy temporal expressions: "Monday", "in two weeks", "end of the month", "the 14th or 15th if that's full". No more multilingual regexes or date parsing libraries like Duckling.
Contextual entity resolution: "the client we saw yesterday", "Mrs. Dupont's order", "like last time". Classic autocomplete requires you to type a recognizable string, whereas an LLM can query history and choose.
Implicit composition: "cancel Thursday and move it to next week" maps to two separate API calls that the model orchestrates without any workflow code.
Formulation tolerance: typos, synonyms, regional expressions, domain jargon — no more mappings to maintain.
Multilingualism: the user writes in their language; the backend receives structured data.
Interactive disambiguation: if an intent is ambiguous, the LLM can hand back a targeted question, whereas a classical UI must anticipate every case upfront.
This last capability is, in my view, the most impressive and the least well exploited. The question isn't whether to use it, but in what form to expose it so users can actually benefit from it.
Every user interface involves a trade-off along three axes:
Expressiveness: the breadth of what a user can express in a single action.
Discoverability: how easy it is to discover what's possible without documentation.
Speed: the actual effort required to formulate a request.
A chat alone maximizes expressiveness, but sacrifices discoverability, and loses speed as soon as you need to type. Voice can partially compensate, but introduces other problems (still little used in professional settings, privacy concerns...). A classical form does the opposite: high discoverability, decent speed, but expressiveness limited to what was anticipated.
In the next section, we look at some emerging patterns that negotiate these three axes differently.
1. Invisible field coercion. The form remains there, visually unchanged, but each field becomes tolerant: the date field accepts "Monday", the quantity field accepts "twelve", the recipient field accepts "last week's client". The interface doesn't change shape, only the input tolerance does. This approach is conservative, but it's probably the pattern that scales best because it demands no learning from the user. The only downside is that composition is lost, and orchestration is not fully exploited.
2. The acceleration lane. The form remains visible, but a single field lets the hurried user dictate everything at once. The LLM then fills in the fields, and the user can adjust with the mouse. This is the pattern adopted by Linear, Raycast and Fantastical. The hierarchy is respected: keyboard for power users, mouse for everyone else. The form remains a trust mechanism, since you can see what was understood before you confirm.
3. Pre-filled + correction. The app makes a hypothesis based on context and the user corrects what's wrong, rather than building from scratch. Cognitive work shifts from composition to verification. This approach, which is widely discussed in the development world, seems to me to go in the wrong direction. There's a loss of sense of control on the professional's part, and in my experience the sense of fatigue it produces is significant.
4. Disambiguation chips. The user expresses a short intent via voice, a button, or a briefly typed query, and the LLM responds not with an answer but with a series of small structured choices to confirm. For example, "Reservation Friday 4 people" would produce three clickable chips 7pm / 8pm / 9pm, then inside / terrace. The conversation becomes a chain of touch validations. This is probably the least explored and most promising pattern for mobile.
5. Generative UI. The LLM doesn't fill in a form, it generates one tailored to each intent. Vercel v0, Claude artifacts, the generative UI ecosystem are exploring this direction. This radical approach is still poorly suited to business use because it lacks determinism, raises accessibility concerns, and creates problems for interface testing, auditing, etc. But it is probably where the long term trajectory leads.
Each of these patterns makes a different trade-off on the expressiveness / discoverability / speed triangle and none has established itself as the clear winner. But "chat-everything" remains, in my view, a poor choice in most cases and amounts to non-design that may produce a "wow" effect for investors, but proves expensive to maintain and frustrating to use.
The interesting work of the next two years will be to test these patterns (and new ones) on real business workflows, observe what users actually adopt, and anticipate that future business interfaces will probably look nothing like today's, and certainly nothing like a chat.
Whatever the outcome, the right reflex is to decouple the model's exposure layer from the chosen