The Interface Belongs to No One Anymore: Why Human–Machine Collaboration Gets a Third Dimension

September 21, 2026

For as long as computers have existed, operating them has been, at its core, a relationship between two parties. A human wants something, a system responds, and in between sits an interface that translates. Batch processing, command line, graphical interface, touch: the language has changed, the relationship has not.

Chatting with an AI changes little about that at first. The machine has become more talkative, but we still sit in front of an interface and spell out what we want from it.

I believe this model is reaching a limit.

I have been carrying this idea around for over a year. It only became truly clear to me recently, while I was developing a software component together with an AI agent. I noticed how hard it is to keep a shared focus. You discuss an implementation, run into a more fundamental question, follow a thought, discard it, come back, much like in a conversation with colleagues.

Only something crucial is missing: a shared workspace.

At some point you find yourself searching the chat history, piecing earlier decisions back together, explaining context again, and trying to work out where the shared line of thought actually got lost. The problem is not that the agent has too little to say. The problem is that chat is still an interface for two.

From two to three

As soon as an agent acts on its own, meaning it doesn’t just answer but executes process steps, triggers workflows and changes state, it is an actor in the system and no longer part of the interface.

The two-party relationship becomes a triangle:

Human ↔ System: The human works with the system directly.
Agent ↔ System: The agent uses the system’s capabilities and acts at the process level.
Human ↔ Agent: The two coordinate on what should be done, who can do what, and who needs something from the other.

Triangle of human, agent and system, with all three relationships inside the interface

The interface no longer sits between human and machine. It becomes the space in which all three relationships become visible. That means it no longer belongs to any of the parties alone. I call this concept Intent-UI.

The starting point is not the form but the intent

Classic software ships its forms ready-made. If you want to change a person’s phone number, you open the person dialog and perhaps see thirty fields, although you need exactly one of them. The interface often mirrors the structure of the system: there is an entity, so there is a dialog for that entity. There are thirty properties, so the dialog shows thirty fields.

Intent-UI turns this relationship around.

The starting point is not the data structure but the intention, the intent.

“I want to change this person’s phone number” is at first neither a form nor an input field, nor is it a process. It merely describes a desired change in the system.

Only from this intent, the current context, the system’s capabilities and the applicable rules does the necessary interaction emerge.

Someone who only wants to change a phone number gets a field for the phone number. Afterwards the component disappears again, because there is no reason to keep it around permanently.

In this sense the interface is no longer a fixed structure. It is a temporary projection of what needs to be settled between the parties at a particular moment.

Direction doesn’t matter

What matters is that this mechanism works in both directions. A human can want something from the system. But just as well, a running process can need something from the human: a decision, an approval, a missing value or an assessment. Today we usually model such situations in advance. We build forms, dialogs and process steps, and while doing so we already work out where a human has to provide which input. In an Intent-UI, the concrete need can generate the interaction instead. The agent then doesn’t point to a form with the instruction to fill in field 17. It generates exactly the question or component that is needed at that moment. The human doesn’t have to be built into every possible variant of a process. Human and agent become two possible initiators of the same interaction logic.

Five principles

The interface is an event, not a product. It comes into being when an actor needs something, and it passes afterwards.
Initiative lies with both. The human can want something from the system, and the agent can need something from the human. The mechanism is the same.
Without a shared model there is no collaboration. Both actors need a shared understanding of which things exist, which capabilities the system offers and what is relevant in the current context. This understanding must not be rebuilt by hand for every individual case. Parts of the system must be able to describe what they offer and the context in which those capabilities stand. Without this model, the agent guesses, and the human can only hope it guessed right. The model doesn’t have to be entirely static. A loose thought can condense into a structure until it becomes a traceable process.
The same rules apply to both. Rights, limits and traceability apply to human and agent by the same logic. An agent has the rights it was explicitly given, and no others just because it sits technically deeper in the system.
Attention is the scarce resource. The interface is organized around the decision that is currently due, not around the data structure behind it.

One technical boundary comes on top of these, and without it the concept cannot work: The agent may shape the interaction, but it may not arbitrarily change the process. This distinction is crucial.

The agent shapes the access, not the truth

Today’s operating logic is mostly deterministic by design. It is thought through, implemented, tested and shipped. That is not a drawback but an important property of reliable systems. The only problem is the gap between new knowledge and its representation in the interface. When a new situation arises during operation, the application doesn’t change at first. Developers have to hear about it, design a solution and ship it with a later release.

An agent can shorten this gap. It can recognize that a particular context needs additional information and generate a fitting interaction for it. It can decide which question has to be asked or which of the existing elements is suited for it. But that doesn’t give it license to reinvent the control of the process. What the agent shapes is the input into a flow, not the flow itself.

A state machine, business rule or other deterministic process control stays separate. Anyone who intervenes in this control at runtime without constraint risks states nobody anticipated, with consequences that are hard to foresee. The outer layer an agent may change is therefore the communication between human and application. This boundary is not a technical footnote. It is a prerequisite for an agent getting access to a production system at all.

From intent to interaction

What does that mean in concrete terms?

Take the simple example from before: A human wants to change a person’s phone number.

In a classic application, the path there is already part of the interface. You open the person search, select a person, open their master data, find the relevant field, change the value and save the record.

The application defined this path long in advance.

In an Intent-UI, only the intent would be known at first:

Intent
  ChangePhoneNumber(Person)

At the same time, the system describes which capabilities it has:

Capability
  UpdatePersonPhone

Requires
  Person
  PhoneNumber

Permission
  Person.ContactData.Write

The intent alone, however, doesn’t yet produce an interface. Only together with the current context, the available capabilities and the applicable rules can we determine which interaction is actually necessary.

If the person is already known, they don’t need to be selected again. If the new phone number is still unknown, exactly this information is missing.

The current need thus reduces to:

Missing
  PhoneNumber

From this, the interaction layer can generate a suitable component:

PhoneNumberInput
ConfirmAction

The human enters the phone number and confirms the change.

This is where the freedom of Intent-UI ends.

The generated interaction does not change the person itself, and it doesn’t invent a new process either. It merely supplies the input for an existing, deterministic capability of the system:

UpdatePersonPhone(Person, PhoneNumber)

Whether this operation is permitted, which business rules apply, which state changes result from it and how the change is logged is still decided by the system.

So the agent did not decide what UpdatePersonPhone means.

It only helped determine what needs to be settled at the current moment so that this capability can be executed.

This is exactly where the separation between generative interaction and deterministic process lies.

Put simply, a chain emerges:

Intent
   ↓
Context
   ↓
Capability
   ↓
missing information or decision
   ↓
Interaction
   ↓
validated input
   ↓
deterministic process

The interface is thus neither the origin of the business logic nor its owner.

It is the temporary projection of a concrete need.

This has a further consequence: to the system, it is initially irrelevant whether the missing information can be supplied by a human, an agent or another capability. What matters is what is needed, who may provide it and under which rules it can be used.

With that, part of software architecture shifts.

We no longer model every possible dialog in advance. We model the system’s capabilities, their preconditions, their rules and the possible forms of interaction.

The concrete interface only emerges where these things meet a concrete intent.

A shared alphabet

Dynamic therefore does not mean arbitrary. An Intent-UI needs stable basic structures from which the concrete interaction can be assembled. You can think of it as an alphabet. A handful of letters can form countless sentences, without new letters having to be invented for each new sentence. Precisely because the basic elements are stable, new statements can keep emerging and still be understood. Human and agent need something comparable: a defined set of elements, capabilities and methods from which both can derive the same things.

The agent then doesn’t generate just any interface.

In simplified terms:

Intent + Context + Capabilities + Rules → Interface

The concrete interface may be ephemeral. The alphabet it emerges from may not.

Without this shared alphabet, every spontaneous adaptation leads to a language of its own. What emerges then is not a shared working environment but a series of one-off solutions whose meaning has to be learned anew each time.

What this means for designers and developers

If this model holds, the task of software development and interface design changes.

We would no longer design screens alone.

We would design the basic elements from which interaction can emerge, the capabilities a system offers, the model that describes these capabilities, and the rules under which human and agent may use them.

What gets delivered is not just interfaces but capabilities, models and rules.

With that, the very notion of the application begins to dissolve.

Eventually, it should hardly be visible to a human whether a piece of information comes from a CRM system, a production control system or a document management system. What matters at first is only what they want to achieve and which capabilities are available for it. The boundaries between applications remain in place technically. In the interaction, however, they lose importance.

The uncomfortable side

This concept does have a side, though, that matters more than many technical questions:

Whoever generates the component frames the decision.

If I only see what seems necessary at this moment, then someone or something has decided beforehand what is necessary.

Omission is the subtlest form of influence.

Intent-UI therefore needs a counter-principle.

The human must be able to demand the bigger picture at any time. They must be able to understand why a component came into being, why it shows exactly this information and which alternatives were left out.

The system may reduce.

The human must be able to expand.

Without this counter-principle, the concept disempowers the human instead of relieving them.

Two further risks come on top.

Whoever never sees the whole unlearns the system. And when nothing has a fixed place anymore, recognizability is lost.

A dynamic interface must therefore not be confused with a random one. The same intent in the same context should reliably lead to the same, or at least a recognizably related, form.

The fundamental problem still can’t be fully resolved.

Whoever wants human and agent to collaborate better has to accept that somewhere, a choice is made about what is relevant at the current moment.

Intent-UI is therefore not a final answer to this problem.

But the problem doesn’t go away if we keep building static forms either. There, the same choice was merely made months or years earlier by a developer or designer, and then frozen into software.

Not out of nowhere

The individual building blocks of this idea have precursors.

Research on mixed-initiative interaction described the shifting of initiative between human and machine as early as the late nineties. Work on joint cognitive systems treats human and machine as one shared system. Generative interfaces are now an active field in their own right.

Intent-UI does not claim to have invented these ideas.

What is new, in my view, is their connection into one shared principle: an interface that emerges from a concrete intent and a concrete context, an agent that can act as an actor in its own right at the process level, and a shared model of capabilities, basic elements and rules that defines what is possible within it. For forty years we built interfaces for humans operating machines. The coming years will be about building spaces in which humans and machines work with systems together. For this task we still lack a vocabulary. Intent-UI is my proposal for one of these terms.