Much of my beloved experience w/ software entails clicking from tab to tab to tab.
But, what if somethings like going to fundamentally change about browser experience?
At MCP Apps Night, hosted by CopilotKit at WorkOS in San Francisco, I went expecting to learn more about agentic interfaces. I left thinking about something more basic: what is an app when the interface no longer has to remain inside it?
MCP Apps lets a server send an interactive interface into an agent host. It’s very cool. A user can work with a map, form, approval card or dashboard without leaving the convo, and the resulting state can return to the agent’s context.
The tech idea is fairly straightforward. However, its consequences are less settled it seems.
The web, in smaller pieces
Ido Salomon, co-creator of MCP Apps and creator of AG-UI, began with a familiar picture: thousands of tabs opened in pursuit of one task.
“What if every app in the world can send its UI component… so you’re not stuck with thousands of tabs when you’re trying to execute different tasks?”
Planning a trip might require a booking site, a map, a shopping cart and a handful of dashboards. Yet a user rarely needs each entire app. We just might need a room selector from one, a map from another, a payment approval from way over somewhere else.
Ido put the design question plainly:
“What does the user actually need for this interaction? What’s the actual utility to deliver?”
Then he gave the evening its most useful phrase:
“You break it down to the atoms.”
This is a actually a more subtle shift than declaring the end of apps or the birth of an entirely new web. The web is not disappearing into agents. But interestingly, its interfaces are becoming smaller, more portable and easier to drum up just where the work already is.
An app becomes less of a destination and more of a set of capabilities. An agent can select the most useful pieces, put them in context and connect what the user does next to the larger task.
Ido Salomon, up in the wee hours of the morning - live from Israel!
Ido described the developer promise this way:
“With MCP Apps, you can write your application once and have it run on every host out there.”
That aspiration depends upon open standards, broad host support and details still being worked through. But the direction is clear enough: the interface is beginning to travel.
Tyler Slaton
Three layers, one conversation
The alphabet soup can quickly obscure the idea. MCP Apps, AG-UI, A2UI, CopilotKit. One useful question from the audience simply asked how the pieces fit together.
Tyler Slaton, founding engineer at CopilotKit, described CopilotKit as a frontend stack for agents because it can bring agent experiences into web and mobile apps, Slack, Teams, command lines and other surfaces.
AG-UI handles the exchange between the agent and those interfaces. MCP Apps lets an external service send its own interactive component into the experience. CopilotKit provides the tools to render and orchestrate the result.
Or, in Tyler’s better analogy:
“AG-UI is basically like you give all of these tools as Lego blocks and then the agent delegates which Lego blocks are there and in what order they’re in.”
The agent can also act through tools defined in the frontend:
“The agent just says, ‘Hey, I want you to execute this tool.’ That execution takes place in the frontend.”
This changes the interface from a screen the agent talks about into part of the agent’s operating environment. The model can call an action, the frontend can execute it, and the user can see and shape what happens.
The protocols are not trying to do the same job. They are separating capability, transport and presentation so that each can evolve without every developer rebuilding the whole stack.
by Pratik @prat3ik * Founder @ TestDino
What remains for the maker?
One audience member asked the question that hangs over almost every new layer of AI development:
“Why wouldn’t Claude itself generate an app for me, rather than show me an app which was created by some developer?”
It was not only a technical question. It was a market question. If models can generate an interface at the moment of need, are developers building on a foundation the model companies will soon absorb?
Ido did not dismiss the concern. He drew a line between generating some UI and creating the requirements, services and experience that make an application durable.
“I don’t think all UI will be generative… there is so much requirement that goes into UI and experiences and services that isn’t an agent doing something randomly in some widgets.”
This may become a useful distinction. Gen UI can absorb disposable interfaces, the temporary form, visualization or control that exists only for the present task. Developer-built apps remain important where an interface embodies proprietary services, institutional knowledge, regulatory constraints, accumulated customer understanding or ongoing responsibility.
The dividing line may not be generated versus built. It may be disposable versus durable.
Andrew Khadder
What the model sees
The same question appeared twice during the evening: when an MCP App is rendered inside a conversation, should the model receive a screenshot, the DOM or something else?
Humans need the rendered interface. The agent may need only a structured account of what the interface contains, what state has changed and which actions are available.
Andrew Khadder, a founding engineer at Manufact (YC S25), favored describing the interface to the model:
“The better way to handle that is through describing the UI to the agent… which is a lot easier on the context window.”
That highlights a key difference: people need a visual UI, while the agent just needs the raw data.
We may see a map. The model may receive locations, selected markers and the available actions. We may see a waitlist card. The model may receive the candidate’s status, preferences and the fact that an approval is required.
The challenge is keeping those two realities synched. A beautiful interface whose semantic state is incomplete will likely confuse the agent. A precise machine description whose visual state is misleading will confuse the person. Agentic UI must serve both without assuming they perceive software in the same way.
Work is already leaving the app
Tobin South of Anthropic offered what initially sounded like an aside:
“I do almost all of my coding in Slack with Claude Tag. No one in SF has caught on to this yet, but it’s an incredible way to do all of your engineering entirely through Slack in threads.”
The comment belonged more centrally to the evening than it first appeared.
Claude Tag brings Claude into selected Slack channels, where people can delegate work, share context and continue the same thread as a team. Anthropic describes it as an evolution of Claude Code and says its internal version creates 65% of its product team’s code.
The significance is not simply that coding can happen in Slack. It is that the place where a team already communicates can become the surface through which software work is delegated, observed and resumed.
Andrew’s demonstration pushed the same idea from engineering into event operations. Voice became the control surface. The agent moved among registrations, team messages, attendee data and an expense report while showing only the interfaces needed at each moment.
“The whole point is that I didn’t need to build out a whole dashboard interface to handle this.”
Later he summarized the experience more vividly:
“Codex is practically just like my control panel… I don’t need to be typing anymore. I can just talk to it kind of like it’s Jarvis.”
The dashboard did not vanish. It was decomposed. The agent became the place where its useful pieces met.
A door that changes its lock
The room became most interesting when the discussion moved from interfaces to trust.
An audience member asked what prevents a subtly malicious MCP App from compromising an agent. The immediate answers included marketplace review, app verification, sandboxing and runtime scanning. All are familiar from earlier software ecosystems.
But remote MCP servers introduce a sharper version of the supply-chain problem. Tobin explained why:
“MCP has this unique feature compared to a lot of APIs: you can just change the tool list at any time.”
A service can expose a different set of tools when a user reconnects. That flexibility can support customization, experimentation and rapid fixes. It also means the capability invoked today may not be identical to the capability reviewed yesterday.
Tyler offered an uncomfortable analogy:
“Imagine if that happened for Node packages… At any point in time your Node code can change and you have no control over that. That’s effectively what we’re accepting at the moment.”
OpenAI’s review process, as described during the discussion, treats a tool’s input and output schema as a contract. Material schema changes require resubmission. Other participants argued for versioned tools, signed snapshots and continuous scanning because a dependency that was safe at approval can become vulnerable later.
The hard question is no longer simply, “Do I trust this app?” It becomes more exact:
Is this the same capability that was reviewed? What changed? Who approved the change? What authority does the current version possess? Can the action and the code that produced it be reconstructed later?
As interfaces become more fluid, trust must become more precise.
The convenience of not asking
Security discussions often end by placing another confirmation dialog in front of the person. The room understood why that does not scale.
Tyler described the experience of repeatedly approving individual permissions:
“As a consumer of MCPs, I don’t care what the tools are… if I have to go and click ‘yes’… it’s like a horrible user experience.”
Tobin pushed the argument further:
“Empirical evidence is that auto mode reduces risks over humans who generally just click yes.”
The paradox is familiar. Asking for permission at every step appears safer, but humans quickly stop reading. A system that evaluates each action against explicit policies may exercise more care than a tired person clicking through the twentieth prompt.
Trust may move away from repeated human approval & toward continuously verified autonomy. Fewer clicks, but more machinery beneath each one.
This does not eliminate human control. It changes where control is expressed: budgets, scopes, approved tools, version constraints, escalation thresholds and durable logs rather than a reflexive yes attached to every action.
The purchase that never happened
One short audience question exposed the edge of the evening’s architecture:
“Was there a payment system that you used in your demo that made the order?”
Andrew explained that the order was simulated. In a production version, he might use browser or computer control with existing credentials.
In a way, the feigned transaction spoke more plainly than a successful one.
The agent could assemble the interface, read operational state, communicate with the team and initiate an order. But when value needed to cross the boundary, the system fell back toward infra designed for a person operating a browser.
This is where agentic UI meets machine commerce.
Work on payment protocols such as MPP & x402 becomes relevant here, but the payment event is only part of the design. Who authorized the spend? What limits applied? What evidence binds payment to the requested work? What happens if delivery fails? Can a receipt become part of the agent’s durable context rather than an artifact stranded in another system?
An agent that can press “buy” is useful. An agent that can prove why it was allowed to buy, what it purchased and whether the promised result arrived is something more.
photo by Pratik @prat3ik * Founder @ TestDino
The web comes when called
The evening ended with a short round of community demos.
I came away less convinced that agents will replace app UIs than that they will change the scale at which we encounter them. Sometimes we’ll probably still want the complete product, its history, navigation and carefully designed environment. At other times, we may need only one capability for a few seconds.
The app does not disappear. It becomes available in pieces.
The interface does not become irrelevant. It moves closer to the task.
And the agent does not become the web. It becomes one place where the web can assemble itself around what we are trying to do.
The next web may still have pages. We may simply spend less time looking for them. Hopefully.
Sources
A2UI flow