Chat vs Forms vs Inline: Choosing an AI Interaction Model

Chat is the interface for when you cannot enumerate the arguments. That is a genuinely important case and it is much rarer inside a product than the number of chat interfaces in products would suggest.

How chat became the default

Chat was the right interface for a general assistant, because a general assistant has an unbounded task space and no way to know in advance what a user wants. That worked, it was copied, and it arrived in hundreds of products where the task space is not unbounded at all — where there are, in fact, six things the feature does.

It is also the cheapest thing to build. A text box and a message list require no decisions about what the feature does, which is exactly why it is so often the wrong choice: it defers the product design onto the user, who has less information than you do about what the system can handle.

What chat costs you

• Discoverability is zero. A blank text box advertises nothing. Everything the feature can do has to be guessed, and users guess low — see the blank canvas problem.
• Every interaction pays full latency. A form submission and a chat message can be the same call, but a conversation makes users pay it repeatedly to converge on something a form would have collected in one round trip.
• The prompt grows without bound. Each turn resends the whole history, so cost per turn increases through a conversation for output the user may value less than the first turn’s. A form has a fixed, tuned, cacheable prompt.
• It is hard to evaluate. A form has a bounded input space you can build a golden set over. A chat box has an infinite one, so your eval covers a sample of what users do and you find out about the rest in production.
• It puts prompt engineering on the user. The quality of the output depends on how well the request was phrased, and you have handed that responsibility to someone who does not know what the system is sensitive to.

Against all of that, chat has one genuine advantage that nothing else has: it accepts requests you did not anticipate. If that matters for your feature, it can outweigh everything above. If it does not, you are paying five costs for a benefit you are not using.

The three models compared

The third row is underused relative to how well it does on every axis. Rewriting a selected paragraph, suggesting a value for the field the cursor is in, completing the line being typed — these avoid the blank canvas entirely, because the user has already expressed intent by selecting something, and they inherit the host application’s undo for free.

The enumerable-arguments test

One question, and it is decisive more often than it looks: can you write down the function signature?

If the feature is:

  summarise(document, length, audience, tone) -> text

then you have named four arguments. A form collects them in one
screen, shows the user that exactly these four things vary, sends a
short fixed prompt, caches its prefix, and can be evaluated over the
cross product of its options.

Building a chat box for it means asking the user to express those
four arguments in prose, waiting while a model parses them back out,
and hoping it got them right.

If instead the feature is:

  doWhatIMeant(anything) -> ???

then no form exists, and chat is the correct interface.

The interesting middle case is when you can name most of the arguments but not all: a form for the four you know plus one free-text field for the rest. That is usually the right answer for a feature inside a product, and it is strictly better than chat because it collapses the part of the input space you understand into controls and reserves the conversation for the part you do not.

Mixing them properly

The three are not exclusive, but there is a wrong way to combine them: a chat interface with a pile of buttons that inject prompt text. That gives you the discoverability of a form and the evaluability of a chat box — the worse half of each.

The combinations that work share a property: the structured part actually changes the request rather than typing into it. A slash command that selects a different prompt template and a different model. A tool picker that changes which tools are attached. A selection that becomes the whole input rather than being pasted into a message. In each case the structure is real state, which means it can be validated, defaulted, remembered and evaluated — none of which is true of text injected into a box.

The distinction sounds pedantic and is not. Text injected into a composer is indistinguishable, by the time it reaches your backend, from text the user typed — so you cannot tell the two populations apart in your logs, you cannot route them to different prompts or models, and you cannot evaluate them separately. Structure preserved as state gives you all three, and it costs a field on the request.

There is also a sequencing argument for building the structured version first, even when you intend to ship chat eventually. A form defines the task, which forces you to decide what the feature actually does; that decision is the input to a prompt, an eval set and a set of failure modes you can enumerate. Starting with chat defers all of it, and the deferral is usually permanent, because once users are typing arbitrary requests there is no longer a bounded task to define. Teams that describe their AI feature as “hard to evaluate” are very often describing the consequence of that ordering rather than a property of language models.

None of which is an argument that chat is bad. It is an argument that it is a specific tool with a specific cost profile, and that “users can just ask for anything” is a description of a product with no defined scope. If that is genuinely what you are building, chat is right and the rest of this cluster tells you how to survive it. If it is not, the interface is doing work the product should have done.