The Future of Apps Might Need Less UI

Mark Vavulov

I’ve been experimenting with web applications that have built-in chat interfaces. The chat knows what’s on the page, understands what I’m looking at, and can directly manipulate the application’s state.

It feels surprisingly natural. Instead of navigating menus or learning a complex interface, I can simply say:

  • Change this to match the others.
  • Find alternatives to it.
  • Select these.
  • Move this to the top.
  • Add another like this.

The assistant already knows the context. I don’t have to explain what page I’m on or describe what I’m looking at. I can point at something with language instead of with a mouse.

This changes how applications can be designed. Instead of building increasingly sophisticated interfaces for every feature, applications can expose some of that complexity through natural language.

Filtering is a simple example. Many applications have elaborate filtering UIs with nested conditions, sorting rules, and include/exclude logic. Instead, a user could simply say, “Filter by that,” “Only show active projects,” or “Sort these by revenue.”

Natural language becomes another interface to the same capability.

The same capability, addressed by language instead of controls CONTROLS say it › Change this to match the others.
The same capability, addressed by language instead of controls.

An Assistant in Every Application?

At the same time, we’re learning that users may not actually want every application to ship its own chatbot.

The popularity of ChatGPT and Claude subscriptions suggests that people prefer building an ongoing relationship with a small number of general-purpose assistants. Those assistants remember preferences, writing style, and previous conversations across many tasks.

An application-specific chatbot starts from scratch. Its memory is limited to that application, and anything the user teaches it stays there.

The Context Reconstruction Tax

If people prefer using a handful of assistants across all their applications, those assistants need to interact with external software. Today, MCP largely solves this by letting applications expose tools that an assistant can call.

But something important is still missing.

When an assistant lives outside the application, the user has to reconstruct context that the application already has. A simple request like “change this” often turns into:

  • Find the object.
  • Confirm it’s the correct one.
  • Make the change.
  • Fetch it again.
  • Verify the result.

The intent was simple. The conversation wasn’t.

Outside the app, change this expands into a five-step round-trip ASSISTANT APPLICATION 1 · find 2 · confirm 3 · change 4 · fetch 5 · verify
Outside the app, “change this” expands into a five-step round-trip.

The user ends up translating what is already obvious on the screen into explicit instructions for another system.

The Missing Layer: Shared Context

MCP tells an assistant what it can do.

It doesn’t tell the assistant what the user is looking at right now.

Applications could expose a small amount of semantic context alongside their tools:

  • which domain objects are visible
  • which object is selected
  • which collection or view is active

This isn’t frontend state or DOM information. It’s simply a mapping between the visual interface and stable domain objects.

For example:

The user is viewing projects 123, 456, and 789. Project 456 is currently selected.

Now the assistant knows exactly what “change this” refers to.

A stable mapping between what is on screen and the domain objects behind it VIEW project-123 project-456 project-789 CONTEXT visible: 123, 456, 789 selected: 456 view: projects
A stable mapping between what’s on screen and the domain objects behind it.

A Surprisingly Simple Architecture

The architecture is simpler than it first appears.

The frontend continues doing what it’s good at: presenting the UI.

The assistant operates through the application’s existing domain API rather than manipulating the DOM or understanding React components.

The flow becomes:

  1. The application shares semantic context.
  2. The assistant performs mutations through the domain API.
  3. The backend reports what changed.
  4. The frontend refreshes the affected data using its normal data flow.

Context flows to the assistant.

Mutations flow through the API.

Updates flow back to the UI.

Context in, mutations through the API, updates back to the UI context mutation changed data FRONTEND renders the UI ASSISTANT reads context DOMAIN API applies mutations
Context in, mutations through the API, updates back to the UI.

View Actions

Not every action changes the underlying data.

Filtering, sorting, selecting, and navigation only affect the current view. Those can be exposed as a small set of view actions alongside the application’s domain tools.

The assistant describes the desired outcome, and the frontend applies it through its existing UI mechanisms.

Computer-use agents can approximate this by interpreting pixels and clicking around the interface. But pixels don’t reliably expose stable identifiers, hidden state, or active filters.

Explicit semantic context is both more reliable and gives the application complete control over what it shares.

Applications Should Vend Context, Not Assistants

The future may not be one chatbot inside every application.

It may be a small number of assistants that move with us across all of them.

Applications should continue owning their domain model, permissions, interface, and APIs.

They don’t necessarily need to own the assistant relationship.

Instead, they need to expose two things:

  • what an assistant is allowed to do
  • enough context for the assistant to understand what the user is doing

MCP provides the capabilities.

A shared context layer provides the missing reference point.

Together, they allow a request as simple as “change this” to stay simple.