Interaction Is Not Interface

AI is already changing how we interact with software systems. Increasingly, interactions can focus on a person, their role, and what they are trying to accomplish, rather than on an application and the screens it happens to provide. The change is uneven and unfinished, but the direction is visible.

Most software still works the other way around. We start with the application: its screens, navigation, vocabulary, and state. People have to find their way through it and translate what they want into the structure it provides.

Turn that relationship around and you start somewhere else. What is this person trying to accomplish? What responsibility do they have? Where is the work now, and what can happen next? Only then do you derive how they should participate. The first question is no longer “which application do I open?” It is “what am I trying to accomplish?”

A specialist may need a dense view of the evidence. A manager may need one decision and its consequences. An auditor may need to see where every fact came from. An agent may need the available action as a tool. A field operator may need visual, spoken, tactile, and ambient cues while acting on the physical world. These differences exist even if everybody uses the same computer. Device, environment, accessibility, and personal preference can shape the result further, but they are context. The person, role, and goal are the center.

This becomes a practical product problem when one underlying system serves several kinds of business. I was discussing that problem on a call with Jason Akatiff, founder of BuiltWithAI.com. An insurance agent, a mortgage broker, and someone screening calls for a law firm may share that system, but they should not have to experience the same product. While explaining our approach, I said something almost in passing:

Interactions don’t need to be compiled into code.

He stopped me there. Of everything I had said, he thought that was the line. He was right. I had been talking about this for a while, but on that call it finally compressed into a sentence.

His case made the cost obvious across industries, but the principle is broader. Whenever we compile an interaction into one interface and then treat that interface as the source, the next role, device, or environment becomes another thing to build, configure, test, and keep aligned. Worse, the interface becomes the only durable record of decisions that existed before it. The interaction has been reduced to one particular representation.

We compile too early

By “compile,” I mean resolving the intent, rules, and possible actions of an interaction into concrete components on a screen. That translation is useful, but it is also lossy.

Take the approval example. The business requirement does not say there must be a table, a detail screen, and a green button in the bottom-right corner. Those are interface decisions. They may be good decisions, but they are not the interaction itself.

The interaction is closer to this:

• Here is a decision that requires attention.
• Here is the evidence relevant to it.
• Here is where the evidence came from.
• These are the actions you are allowed to take.
• This is what each action implies.

Preserve that description, and you can derive a table, a sequence of spoken questions, a compact phone flow, or an agent tool. But the direction matters. Once the interaction has become a table with a green button, you cannot reliably recover the original description from the table. The button tells you that somebody can click it. It does not tell you the goal, why this person may act, what evidence the action requires, or how the same decision should work when nobody has a button. What was lost is not visual detail. It is meaning that this particular representation had no reason to express.

We usually discard that richer description and eagerly jump into React components, native macOS controls, routes, and application state. The interaction becomes inseparable from its first implementation before anybody asks where else it might need to live. When we later need a phone client, an agent tool, an auditor view, or an accessible mode, we derive it from a representation already shaped by another environment. We are no longer translating the original interaction. We are reverse-engineering it from what survived.

Configuration can hide or rename parts of the first interface, but it cannot restore meaning that the interface never preserved.

Should AI generate the whole interface?

The tempting answer now is: let a model build it. Describe the desired experience and have an agent generate the web application, then the phone client, then whatever comes next. This works surprisingly well. But why ask a probabilistic system to rediscover a translation whose rules we already know?

If the phone client is generated from the web application, the model has to guess which parts express the interaction and which parts are accidents of the web. AI can make that guess better than earlier tools could, but inference is not preservation.

A model is most valuable where something ambiguous must become precise. It can interpret a conversation, notice missing requirements, and produce or modify a higher-level description of an interaction. Once that description is precise, ordinary software can derive each representation quickly and reliably. The better that underlying interaction model becomes, the less implementation AI has to invent. AI can resolve what the interaction should mean; deterministic renderers can decide how that meaning appears in each environment.

Make the interaction data

So we tried something else at Inferal: describe the interaction as data before turning it into components. That description includes goals, information, possible actions, order, constraints, and where the evidence came from. It remains the source after an interface has been rendered. The macOS controls and web components are outputs, not the place where the interaction goes to live.

At Inferal, this is part of the operational model, not a UI model sitting beside it. The operational model describes the business: its vocabulary, current facts, rules, constraints, and evidence. The interaction layer describes how a person or agent can take part.

The path to an interface has four parts:

• The operational model holds what things mean, what is true now, and what the rules allow.
• The master interaction describes the goals, information, and possible actions for the full process.
• A specialized projection narrows that interaction for the industry, organization, role, person, and current context.
• A renderer produces the appropriate interface or tool.

When a person or agent acts, the result returns to the operational model as business data. Its rules respond, the process advances, and renderers update their interfaces from the new state. The same model supplies the meaning used to render an interface and receives the result of the action. It records “the decision was approved with this evidence,” not merely “button X was clicked.”

Keeping the interaction at that level also changes what we synchronize. In a conventional application, where you are is often represented by interface coordinates: this route, that tab, this open panel, that selected row. Those coordinates make sense only inside the interface that created them. A phone may not have the same tabs. A spoken interaction has no panels at all.

What needs to travel is the meaning: the evidence has been collected, the decision is waiting for approval, this person is authorized to act, and these actions are now available. That is where we are in the process, together with the data accumulated on the way. Each renderer can present that shared state differently. Nothing has to translate “the user is on tab three” into a rough equivalent of tab three somewhere else.

From specialization to hyper-personalization

Once the interaction is data, specialization becomes a data operation too. The master interaction describes the full process: everything it can ask, show, accept, and allow, together with the meaning and constraints behind those possibilities. It is not a generic interface that everybody has to use.

A query derives a specialized projection from that master. It says what to keep, remove, add, rename, or reorder for a particular context. One projection may retain the evidence and controls a specialist needs. Another may emphasize where evidence came from for an auditor, or compress the decision for somebody who has only a moment to respond.

1. 01Master interactionFull processMaster interaction: Full process.
2. 02IndustryDomain contextIndustry: Domain context.
3. 03OrganizationLocal rulesOrganization: Local rules.
4. 04RoleDuties and authorityRole: Duties and authority.
5. 05PersonNeeds and preferencesPerson: Needs and preferences.
6. 06This momentDevice, place, time, stateThis moment: Device, place, time, state.

You can think of these projections as related child and sibling models, not independent products. When the master changes, compatible changes flow through. If a change makes a projection invalid, it fails explicitly and can be repaired instead of quietly drifting away from its source.

Industry specialization and personal adaptation are the same operation with different context. Industry is an obvious place to start because its differences are easy to see and govern. Organization, role, responsibilities, preferences, device, location, time, and the current state of the work can narrow the interaction further.

This goes beyond responsive design. Responsive design asks how a layout should change when the screen gets narrower. Adaptivity asks what this particular person, in this role and environment, needs from the interaction right now. The answer may change the presentation, but it may also change the information, available actions, sequence, level of detail, or explanation.

That is the path from specialization to hyper-personalization. We keep adding relevant context to the same source, then render the result. A model can help decide what a projection should contain, but it does not need to improvise an interface every time somebody opens an application.

Does this mean everybody should design their own interface? No. Give people a blank box asking them to describe any interface they want, and they will create a Frankenstein product. That is not personalization. It is product abdication.

People know when something is wrong. They know a screen is too dense, a task takes too many steps, or the terminology does not belong to their work. They do not need to know what should replace it. That still requires product judgment: understanding the work, inventing a better interaction, testing it, and deciding which constraints should remain. AI can make that loop faster. Once we make the decision, we can deliver it as a new projection instead of starting another software project.

Interfaces still matter

Putting the person, role, and goal at the center does not make the interface disposable. It changes what the interface is for. A table may still be the fastest way to inspect an anomaly. A carefully designed graphical interface may express relationships that would be painful to uncover through conversation. It becomes a projection of the work, not the place where the work is defined.

Agents add another path; they do not force every interaction into chat. Even a conversation with an agent is an interface, with its own strengths and costs. The point is not to replace graphical interfaces. It is to expand what an interface can be, while stopping any one of them from becoming the sole owner of the work.

This is not mainly about adapting one flow to different devices. Two people on identical laptops may need different projections because their responsibilities and goals differ. Devices, environments, and preferences refine the projection further. The business context leads.

When the operational model holds the purpose, state, rules, and available actions, each interface can do what it does best without owning the interaction. The person no longer has to enter an application’s world and carry the missing context alone.

You can derive an interface from an interaction. You cannot recover the whole interaction from an interface. That asymmetry is why the interaction must remain the source: use AI where interpretation is required, and deterministic software where the translation is known.

The future is not a world without interfaces. It is a world in which an interaction no longer belongs to one interface.