Skip to content

Exploring an AI Answer Before Asking Again

Thesys’s investigation of ChatGPT’s web interface shows how people can adjust a calculation within an answer and separately send their choices as a new request.

Graham Barlow wanted to explore a Tokyo itinerary without starting over for every budget. In his October 8 ChatGPT feature test, the technology journalist requested 3 days, £3,000, ancient temples and a late-November start. After clarifying that flights were excluded and asking to adjust the budget, he received a slider. Moving it changed elements of the proposed trip. The answer also offered a button to request an updated itinerary.

OpenAI calls these interactive answers Intelligent UI: text mixed with controls, charts and other elements you can operate inside a conversation. An October 8 web investigation by interface-software company Thesys describes calculations that run within an existing answer and actions that send choices as a new request. A changing display need not mean a new model response.

For everyday AI work, that creates room to explore alternatives before deciding what further work to request. You might vary a budget or compare priorities while keeping the answer’s assumptions in place. Asking the model to reconsider the plan is a different task. Neither operation, by itself, checks whether the original prices or estimates were sound.

Calculating with what is already there

OpenAI’s launch explanation describes a library of native components, the familiar-looking pieces from which an interface is assembled. A compiler, software that translates the interface description into instructions the application can run, processes it while the model generates it. Parts can therefore appear before the whole answer is finished. The model chooses how to combine these pieces rather than delivering only a paragraph about the task.

Thesys, which maintains the OpenUI framework and operates related services, examined its own web sessions and client code. For native components, it describes code running in a sandbox, an isolated execution environment. Its illustrative team-pricing slider recalculates locally, without another model call. This concerns its tested web implementation.

For a calculation like that, you can vary the team size while keeping the pricing rule fixed. Instead of reading one quoted total, you can examine how the total changes with quantity. The useful possibility is exploring a relationship already built into the answer.

Keeping the rule fixed also defines the limit. Multiplying a different quantity by the same rate does not investigate whether that rate applies to your purchase. If your question changes from how much a given plan would cost to which plan fits your organization, the calculation may no longer contain the work you need. The slider exposes one variable. Other considerations can remain outside the answer.

The choice of controls therefore shapes what someone can explore. If you are building a similar experience, exposing more adjustable quantities could open more possibilities. It could also ask people to make choices they do not yet understand. Deciding what to make adjustable is part of deciding what work the answer should do.

Turning a choice into a request

Thesys reports a message-producing example. A dog-vest moodboard, a collection of design inspiration, offers style, color and feature choices. Its “Develop this direction” button assembles them into a message requesting a cozy, sand-colored design with reflective details and adjustable straps, plus visual inspiration and construction ideas.

Selecting a color explores a choice already offered. Asking for construction ideas requests further work. The controls supply some of the wording, so the person need not compose every detail in the text box. That convenience also makes the button’s scope consequential: it can carry the chosen features without asking every question needed to make the design usable.

Barlow’s itinerary offered a similar-looking next step. His article does not report pressing the update button or describe a resulting answer, so it cannot verify the same mechanism or a completed planning workflow.

For your own AI work, a useful question is: does the next request contain the choices you intend the model to develop? This suggested check has not been tested as a remedy. It applies whether you compose the request or an interface assembles it, especially when you move from comparing possibilities to producing something another person will use.

What the controls leave open

In a separate laptop-comparison test, Barlow changed the importance of battery life, weight and price and saw the recommendation change. He liked the experience. He also noticed an estimated battery-life figure and said he would still check specifications before buying.

His qualification belongs alongside the benefit. Changing the weight assigned to battery life can explore how a recommendation responds to that preference. It cannot turn an estimated battery figure into a measured specification. An attractive comparison could help you discover what matters to you while leaving the factual basis of the comparison unresolved.

There is another distinction to preserve: a value staying on screen and a value informing a later answer are different questions. OpenAI’s current help documentation says persistence depends on the experience. Some components, including checklists, can retain their state after a refresh; state does not carry across chat threads. Those documented possibilities do not establish how every later model request uses the retained values.

Interactive answers could help you sharpen a request before making a commitment. You could examine alternatives, decide which assumptions deserve checking, then ask for further work. That possible workflow still leaves the factual checks to do: Barlow could change the laptop recommendation by moving sliders, but the battery-life estimate still needed checking before it became a reason to buy.

Sources