When Chat Renders an Interface

An assistant shows three appointment slots with a button under each. It looks like an application, and for the person using it, it behaves like one.

The useful question is what that screen is actually telling you. Three slots were available when something fetched them. A button means the interface will let you ask for one. Neither of those is the same as the slot being free now, or the booking going through.

What the surface is for

The interaction surface is where a person sees system state, provides input, makes choices and requests actions.

That is a real job and it is a narrow one. A surface may expose, initiate or display the mechanisms around it, and it may hold local validation, local state and its own instrumentation. What the interface alone does not establish is that permission was granted, that a person's judgment was meaningful, that evidence was recorded, that the behaviour was acceptable, or that this exposure was justified.

The interaction surface is the part a person directly interacts with, so its visible labels and controls should not be treated as proof of the mechanisms sitting behind them.

What prose does, and what it does not

It is tempting to say a text reply cannot carry a workflow. That is not true, and saying it gets the distinction wrong.

Text does carry workflows. A numbered list of options and reply with 1, 2 or 3 is a selector. A typed command is an action. A yes-or-no question is a confirmation. A sequence of questions is a form. None of that needs rendering.

An interactive surface can represent structured state and constrained choices directly, rather than describing them only in prose. That is the actual difference. Four options with three attributes each can be laid out so they are comparable at a glance rather than read in sequence. A choice can be constrained to what is selectable rather than parsed from whatever someone typed. A value can update as an input changes.

Whether that is worth building depends on the task. A question with one answer does not need a card, and a rendered component is not an improvement on a sentence that was already doing the job.

What is on screen is a view

An interaction surface represents state and available choices to a person. It does not by itself establish that the state is current or that the choices are permitted.

A rendered value came from somewhere at some moment. Between that moment and the person looking at it, the underlying record can change, and nothing about the screen updates on its own unless something was built to update it.

It matters for the words interfaces use, because those words assert conditions. Available. Approved. In stock. Connected. Current balance. Each one names a condition that something else is responsible for establishing. A label reports how the interface is representing state at that moment, and it does not by itself establish that the underlying condition is current or authoritative.

The practical consequence is small and specific: where a decision depends on a value being current, the value has to be re-established at the moment of the decision, not read off the last render.

A control is a request

A visible control expresses something the interface will let a person request. Whether that request becomes an effect is determined elsewhere.

This distinction collapses in a particular direction: a button that exists is read as a button that will work.

Two consequences follow. A control being visible does not mean the operation behind it is permitted right now, for this person, in this state. And hiding or disabling a control changes what the interface offers. It does not by itself enforce permission or make the underlying operation unavailable through other paths. Where permission actually gets decided is a separate layer of the system, and this page does not restate how it works.

The booking, traced

Here is a constructed example to make the states visible. Nothing about it is universal, and plenty of interactive surfaces never reach half of these steps.

Something fetched availability and the surface rendered three slots. A person selected the second one. That selection expresses a request for that slot. The underlying system now checks availability as it is at this moment, not as it was at render, and decides whether the booking may proceed. It proceeds or it does not. Whatever actually happened comes back, and the surface updates to match.

Now take the path that the happy-path version of this page never showed. Between the render and the click, the slot was taken by someone else.

The interface may have accurately represented the availability it received at render time. By the time the person acts, that condition may have changed. The selection was still a request for something that was genuinely offered, and the request was still well-formed.

What happens next is a workflow decision rather than a single right answer. The system may refuse, refresh the options, offer alternatives, add the person to a waitlist, or ask them to choose again. What it should not do is confirm the requested slot unless the current authoritative result establishes that the booking succeeded.

That puts a requirement on the surface rather than on the check. If the surface cannot represent refusal or changed state, it cannot faithfully present that branch of the interaction.

Requested, done, and worked

Three more states worth keeping apart, because they are easy to merge.

A request accepted by the interface is not an operation that ran. A confirmation rendered on screen is not evidence that the effect occurred, unless that confirmation is reporting an authoritative result rather than the fact that a request was sent. And an operation that completed is not necessarily the outcome the person wanted, which is a judgment that gets made somewhere else entirely.

The mechanism worth holding onto: the surface should not present a requested effect as completed unless the underlying result establishes that it completed.

Interfaces also validate, and it is worth being clear about what that establishes. Checking that a field is filled, that a number is in range, that a date parses, that something was selected: these are real checks and they are checks about the input. They do not establish that the requested operation makes sense against the current state of the system, or that it is allowed.

Interactive does not mean acting

A rendered component is not inherently connected to anything.

A card can be entirely read-only. A selector can change nothing but what the interface is displaying. A form can collect values that go no further until something is submitted. A chart can be a picture of data already fetched.

Which of those a given component is depends on what it was wired to, and that is not visible from the fact that it is interactive. Assuming an interface element implies an external effect gets the system wrong in one direction; assuming it does not gets it wrong in the other, more expensive one.

It is also worth naming the actor precisely. Saying the assistant opens the app describes an outcome, not a mechanism. What selects a component may be the model, the host application, a deterministic rule, a tool definition, or the person choosing directly, and implementations differ. The surface does not have to own that choice.

What reuse does and does not buy

Interfaces built from shared components let different tasks use the same implementation, which is an ordinary software design choice with ordinary software design benefits.

It is not what makes an interaction surface work, and it does not on its own establish anything about cost, speed, or how good the resulting experience is. Those would need their own evidence.

What the surface shows but does not own

Several mechanisms can be surfaced to a person. Displaying them does not create them.

A citation displayed next to an answer shows what something reported as its source. A feedback control produces a signal if something is collecting it, which is not the same as having a way to judge the behaviour. A status indicator reports what some upstream thing said. And a person clicking approve is an input event; whether they were positioned to judge what they approved is a design question about the decision, not about the button.

A surface can also show current workflow state without being where that state lives. Conversation history is a record of an exchange, and whether it reflects the state a workflow should continue from is a separate matter.

And an interaction surface can work exactly as designed while the system underneath is not ready to be put in front of the people it is for. A rendering demonstration establishes that the rendering works.

What this changes

Next time an assistant renders something clickable, ask five questions about it.

What state is this showing, and when was it true? What does selecting this request? Where does permission get decided? What establishes that the effect happened? And what does this screen do when the answer is no?

If the interface has good answers, it will behave the way it looks. Where it does not, the gap shows up after somebody has already clicked.