Ephemeral Interfaces: When Software Materializes on Demand

A word processor asks us to think in documents; a spreadsheet, in cells; a chat window, in turns. These are useful forms, but each has already decided what kinds of things we can make and how they can relate. A question that crosses those boundaries gets broken up to fit the available surfaces. Some of its connections disappear in the translation.

An ephemeral interface could arrange a temporary environment around the question instead. It would remain connected to its data and change as the inquiry changes. Its components might be generated or selected from a library; their arrangement would be provisional. It could also slow us down where the work calls for it, by making a disputed source or an uncertain inference visible. Beneath it, a persistent layer would keep the sources, relationships, and trails of interaction.

This changes what we treat as the durable thing. An application usually stores a document and offers a stable set of tools around it. Here the arrangement of tools could come and go while the inquiry, including its detours, remains accessible. A stable view can be exactly what a difficult comparison needs. The surface should change when the work asks for a different form, and stay put when movement would only be noise.

Imagine asking, “Explore links between ocean temperatures and storm intensity.” A map of related concepts appears beside a visualization of temperature data and the papers behind it. As you follow a citation or select a region, the surface changes. A comparison might replace the map; an annotation might stay attached to the source rather than to a disposable screenshot. This is the aspiration. Today’s systems can assemble parts of such a view, but they do not reliably maintain that continuity through an open-ended inquiry.

Part 2 described the “Agentic Delusion”: agents that return voluminous research reports while the work of asking, testing, and following connections remains with the reader. We receive mass, but lose momentum. A report may contain good material and still leave us with no way to move through it.

Generated UI hints at another possibility, though much of it currently amounts to a static snapshot. An AI can produce code for a chart that looks convincing while knowing nothing about the data it must display. Connecting retrieval and tool use to interface generation gets us closer: the chart can show a particular dataset. Keeping that chart bound to its source, responsive to a changed question, and traceable back to the evidence is harder.

The interesting artifact, then, is a structure for continued inquiry. It should let me ask where a value came from, compare it with a contradictory result, branch into a different hypothesis, and return without reconstructing the path by hand.

A static report forces the reader to turn paragraphs back into questions. It may cite sources, yet the connections between those sources and the claims are usually flattened into a single sequence. An interactive structure could keep multiple routes open. The reader might follow a disputed number into its method, then come back to the larger argument without losing the branch they took.

Some of the required pieces exist. Models can generate constrained UI code; browser sandboxes can execute it. Component libraries and design systems provide a grammar for assembly. Structured interfaces to external data and tools, including protocols such as MCP, give a system ways to retrieve information and act on it. Tool calling works reasonably well when a request maps clearly to an available operation.

Those pieces do not yet add up to an interface that moves with an inquiry. Complex work may require several sources, calculations, and revisions to an initial plan. Planning and tool orchestration remain unreliable when the goal is open-ended or the intermediate results are surprising. Deep contextual awareness is still more aspiration than dependable capability: a system may know the active document but miss why I opened it, which line of thought I abandoned, or whether I am exploring or trying to finish. Inferring intent from a click or an ambiguous sentence is even less certain.

Live data binding belongs in this gap too. A generated component may receive a dataset once and render correctly, while later changes in the source never reach it. Rebinding every element continuously would be expensive and potentially distracting. The system needs to know which views require fresh data, which can remain snapshots, and how to mark the difference. The reader should never have to guess whether a polished chart is current.

I would distinguish these capacities rather than treat “AI-generated interface” as one solved feature:

The architecture matters as much as the individual capacities. A generated chart that loses its data connection is a picture. An agent that retrieves the right paper but forgets why it mattered breaks the thread. The next question is how these parts can cooperate without making the system’s decisions opaque.

Take a more specific request: “Compare the environmental impact reports for projects X and Y from the last two years.” A system would need to find the reports, establish which versions and periods are comparable, extract the relevant measures, and choose a form in which differences are legible. Each step can change the next. If one report measures a different boundary, the interface should show that mismatch rather than smooth it into a tidy chart.

The orchestrator might select a comparison table from a component library and attach each value to its source passage. If you ask about one surprising difference, it could retrieve the methods section, bring that passage alongside the chart, and leave the other comparison in place. If the source changes, the surface should indicate what changed and whether its earlier interpretation still holds. This requires live data binding, provenance, and a way to revise the plan after interaction. It is an iterative loop, not a six-step pipeline that ends at rendering.

There are several places for this loop to fail. A tool call may return incomplete data. A model may infer that two categories match when they do not. A generated component may obscure uncertainty behind a crisp visual form. The interface grammar therefore needs error states as carefully designed as its charts and maps: missing source, incompatible measurement, stale result, unresolved interpretation. These states are part of the inquiry.

There is also a question of permission. Finding a source and reading it is different from altering a document or carrying a conclusion into another context. An interface assembled around intent must make those boundaries visible enough for a person to intervene.

Consider a researcher looking into carbon capture. At first they want the landscape: concepts, research clusters, authors, and uncertainties. Later they ask to compare the cost and efficiency claims for direct air capture and bioenergy with carbon capture. The map might recede while a table and source passages come forward. When they start drafting, the relevant citations and the unresolved discrepancies should remain near the text.

That sequence describes a desired environment, not a claim about what current systems can infer unaided. The researcher may have to state each shift. Even then, retaining the trail matters: a provisional conclusion should still lead back to the comparison, and the comparison to the sources. A system might offer a branch by region or technology type, but the researcher should be able to refuse it or return to an earlier view.

Modes need not be fixed labels either. Reading, writing, and revising a question can happen in the same stretch of work. The system should be able to place a quotation next to a draft without declaring that someone has entered “writing mode,” or bring back the map without resetting the draft. The task is to support those movements, not to classify the person once and reorganize everything around that guess.

The interface can support thought without pretending to know what the researcher thinks. Its value lies partly in making alternatives navigable and partly in preserving where its own suggestions came from.

If surfaces can be assembled during use, design moves into the rules of assembly. Components still need careful attention, but so do their relationships: which data can be shown in a chart, when a quotation needs its source beside it, how much can change before the person loses their place, and which actions require explicit consent.

A design system could hold the stable vocabulary: familiar controls, visual hierarchy, interaction rules, and ways to inspect provenance. The fluid parts would be layout, density, and the combination of views. This is less like composing one screen than defining a language that can produce many screens without becoming unintelligible.

There is an aesthetic risk here. A polished surface can conceal a weak inference; a constantly morphing one can make even sound information hard to trust. The system should show why a view changed and allow the person to keep, rearrange, or dismiss it. I would rather tolerate a rough edge than lose the ability to see what the system did.

The name evokes lightness, but the work cannot vanish with the surface. What should persist is more than a final document: sources, annotations, explored paths, abandoned approaches, and questions that remain open. Some of this will be explicit. Some will be inferred, and those inferences need their own labels and a way to be corrected.

That persistent layer also needs forgetting. Saving every click would make the next inquiry harder to navigate and might preserve things a person meant to leave behind. The boundary between a useful trail and unwanted memory is a design decision, with consequences for privacy and agency.

The temporary scaffold can fall away only if the underlying context remains legible and under the person’s control. Part 4 looks at the data and retrieval architecture such a substrate would require.