AI-Native Apps are Not a Chat Box. Three Protocols Just Proved It.

In the space of three weeks at the end of 2025, three separate camps shipped a protocol for the same thing.

On 21 November, maintainers from Anthropic and OpenAI published MCP Apps, an extension that lets a server deliver an interactive interface to whatever host the user is sitting in front of [1]. On 15 December, Google open-sourced A2UI, a format for agents to describe interfaces that a client then renders with its own native components [2]. Both landed next to AG-UI, which had already been doing its own version of the job for the agent frameworks [3].

They disagree about nearly everything. How the interface travels, and who is allowed to render it. They agree on one thing, and it is the thing worth stopping for.

All three exist to let an AI agent put a real interface back in front of a human. A chart you can read. A confirm step you can check before you press it.

If a chat window were the destination, nobody would be building the road back.

I want to start there, because the question underneath the protocol argument is bigger than which protocol wins. It is what an AI-native application even is, and whether the thing you shipped last quarter counts. I will come back to all three near the end, in plain language, with a rule for which ones you need. First I want to give you a test.

The test

I have stopped asking products what model they run.

The question I ask instead is the one I would put to your roadmap. How much work does the application still make the human do?

Not how much typing. How much assembly. How much of the job of working out which capability to use, in what order, with what information carried between the steps, is still sitting on the person holding the phone.

That question sorts the room fast, because there are only three answers.

In a classic application, the human does all the assembly. The software offers capabilities and you arrange them. You know which screen you need, you know what to enter, and you carry the context from one step to the next in your head.

In an AI-enhanced application, the human still does all the assembly, but with better help along the way. Search understands you now. There is a summary at the top. Something explains a chart. Every one of those is a real improvement and none of them takes the assembly off you.

In an AI-native application, the system does the assembly and hands you back something to approve.

That gives you the cleanest way I know to tell the second rung from the third. AI-enhanced applications make the existing work easier. AI-native applications make the existing work somebody else's.

The same app, three times

Take a banking app, because everyone has one and everyone hates part of it.

The classic version: you want to pay four invoices. You open Payments. You select or create each beneficiary. You type amounts and references. You pick the account. You confirm, four times. If you also need to keep enough in the account for next week, that part happens in your head, or on paper, or not at all.

The AI-enhanced version: the same app, plus a button that explains your spending and an assistant that can answer how much you spent on restaurants last month. Genuinely useful. Now open Payments and type the four amounts.

The AI-native version starts somewhere else. You say: pay everything due before Friday, but leave me three thousand available, I am travelling next week. The system reads the invoices, checks the due dates, works out what that leaves you, proposes a batch with two payments moved to Monday, tells you why, and waits.

Same bank. Same underlying systems. Very possibly the same model behind all of it. Only the third one changed who does the work.

And notice what the third one accepted that no screen in the first two could. There is no field anywhere in your banking app for "but leave me three thousand." That is not an input. It is a constraint, and constraints are exactly what a form cannot take. A form collects values. It has never been able to collect the reason behind them.

The itinerary

Here is the image I keep coming back to, and I will use it for the rest of this piece.

A booking site makes you assemble a trip. Flights first, then work out the transfer, then the hotel, then check the whole thing lines up and nothing overlaps. A travel agent takes the constraint instead. In Barcelona by ten on Thursday, home for dinner Friday, under nine hundred euros. Then they go away and do the assembly.

But they still hand you an itinerary. Printed, itemised, in order, with the times on it. You read it. You spot that the Friday train is too tight and you say so.

Delegation did not remove the artifact. It removed the assembly.

Hold on to that, because it is the whole reason three companies spent the end of last year arguing about how to print the itinerary.

A hundred thousand skills and nobody could use them

If you want proof that a conversational surface has nothing to do with any of this, the industry already ran the experiment at enormous expense.

By 2019 there were more than a hundred thousand Alexa skills [4]. Voice interface. Natural language. Every ingredient of the promise, years before anyone said the word agent in a board meeting.

And to use one, you had to know the magic words. Alexa, ask this brand to do that thing. You had to know the skill existed, know its invocation name, and know the phrasing it expected. A hundred thousand capabilities sitting there, and the human was still the integration layer. You were doing the assembly with your mouth instead of your thumb.

Then Amazon rebuilt it. Alexa+ arrived in February 2025, and with it a new set of developer kits that Amazon's own blog titles AI-native. The sentence in that announcement worth reading twice is the least dramatic one on the page [5]:

To access your services, customers no longer need to remember specific phrases or commands.

That is it. That is the whole difference, written by the company that spent a decade learning it the expensive way.

The conversation was never the AI-native part. Removing the assembly work was.

What it looks like when a product passes

Abstractions are cheap here, so let me be concrete. Three examples, each making a different point.

Start with the claim that files itself. Your flight is cancelled at ten past six in the morning. In the classic version, you find out at the gate, and three weeks later you remember there was insurance, and you go looking for a form, and the form wants a booking reference and a cancellation notice you no longer have. In the AI-native version, by the time you have landed somewhere else the claim is drafted, the cancellation notice and the boarding pass are attached, and it is waiting for you to read it and press one button. The point of this example is that nobody asked. The work started itself.

Then the return that takes one decision. You bought boots. They do not fit. Classic version: find the order, select the item, choose a reason from a dropdown that does not contain your reason, print a label you have no printer for, find a drop-off point. AI-native version: you send a photo and say these do not fit. The system identifies the order, checks you are inside the window, sees you work from home on Thursdays, books the courier for Thursday, and asks you one question. Half size up, or refund. The point of this one is the arithmetic. Twelve steps became one decision, and the one decision left was the only one that actually needed a human.

And then the boring one that already ships. An engineer asks whether release 4.2 is safe to go out. Answering that needs the tracker, the deployment pipeline, the error monitor and the last two incident reports, and it normally needs a person to open four tabs and hold the picture together in their head. Assembled, it is one answer with the four sources shown underneath it. I include this example because it is not speculative. Versions of it are running in production today, which is a useful corrective to a section that could otherwise read as futurism.

The part people get wrong in the other direction

Having said all that, there is a failure mode on the opposite side, and I see it more often now than the first one.

AI-native does not mean everything becomes a conversation.

A calendar picker communicates a date faster than a sentence can. A chart shows you a spending pattern in a second. A toggle is unambiguous. A confirmation screen with the amount and the account on it is safer than any amount of well-phrased reassurance, because you can check it.

So the rule I would write on the wall is this. Never use conversation where a button does the job better.

The strong pattern puts natural language on the way in and an ordinary interface on the way out. Chat is the door, not the room. You state the intent however you like. The system does the assembly. Then it hands you back the itinerary: a proposal, itemised, with the reasoning visible and a confirm step you can actually inspect.

That handing back is precisely what the three protocols are for. Bear with me for one more section first, because there is a consequence that changes the strategy before it changes the code.

The surface stops being mobile

Once the system does the assembly, the assembly no longer has to happen where your icon is.

This is already literal. MCP Apps means a product's own interface can render inside somebody else's assistant. When Anthropic shipped it in Claude in January 2026, the launch partners were ordinary working software: Canva, Figma, Slack, Asana, Box [6]. A user gets an interactive piece of Canva inside a conversation with Claude, and Canva did not have to build Claude anything. A2UI comes at the same problem from the other side, so that one agent response can render as Flutter widgets, or Angular components, or web components, depending on what the person happens to be holding [2].

Make it physical. You are driving. You say you are going to be late for the three o'clock. The system moves the meeting, messages the two people who need to know, and reads you back what it did so you can say no. There is no screen involved and no app was opened. Your product either participated in that moment or it did not.

Intent arrives wherever the person is. A watch, a car, a terminal, a colleague's assistant. You do not get to choose which.

So here is the bet I am making, and I want to be honest that it is a bet. I think the durable asset stops being your screen and becomes your capability surface. The set of things your product can do that something else can call, with the permissions and the guarantees attached.

Now let me argue against myself for a moment. App icons are not disappearing. Plenty of what gets demoed as agent traffic today is demoware, and the graveyard of people who predicted the death of the app is well populated. I am not going to join them.

So let me win on the narrower version, which I think is bulletproof. Even if the icon survives all of this completely untouched, the assembly still moves. The user stops being the integration layer. That is true whether the assembly happens inside your app, inside somebody else's, or in a car with nobody looking at anything.

Where is the new idea

There is a sharper pushback than mine, and it comes in two parts. Both are good.

The first is that none of this is new. We have been told for twenty years to decompose the monolith, expose clean typed services, own our data contracts and stop letting the front end reach into the database. Every AI-native architecture diagram is a service-oriented architecture diagram with a model bolted on the top. So where is the new idea?

I concede that one completely, and the concession is my argument.

Yes, it is the same advice. That is exactly why most companies cannot become AI-native. The bottleneck was never access to a good model. Good models are a purchase order away and they get cheaper every quarter. The bottleneck is twenty years of unfinished integration work that has, finally, found a caller willing to pay for it. Every capability you never exposed properly, every system with no API, every piece of context locked in a document store nobody indexed. All of that used to be technical debt with no deadline. Now it is the reason the assistant cannot do anything.

A brilliant model sitting on top of forty inaccessible systems is a brilliant chatbot. I have spent a book's worth of thinking on how these systems get orchestrated, and the unglamorous truth is that almost none of the difficulty lives in the model.

The second part of the objection is about people, and it is the one I take more seriously. Users do not actually want to delegate. Clippy failed. Siri stalled. People say they want an assistant and then go back to tapping the button, because tapping is fast and legible and reversible, and delegation is none of those three.

Except we have already been through this, at scale, and I told you the story two sections ago. A hundred thousand skills, and the thing users rejected was not delegation. It was fake delegation, where the machine talked like an assistant and you still had to know the invocation phrase. They were right to reject it. It was a worse form with a friendlier voice.

How you actually build one

If you want to move a real product, here is what the work is. Six things, and notice that only the last one mentions a model at all.

1. The deterministic core stays in charge. The AI proposes, the ledger disposes. Authorization, balance checks, limits, compliance screening and posting stay ordinary software with ordinary guarantees. Treat every request the model generates as untrusted input, because that is what it is. Nothing about going AI-native requires you to give up repeatability where repeatability is the product.

2. Expose narrow typed tools, not database access. Give the system a function that prepares a transfer draft, not a connection string. Give it a function that books an available slot, not admin rights on the calendar. Here the permission envelope is the design, and it belongs in the first sketch rather than the security review.

3. Fix the context layer, because that is the actual bottleneck. This is the same point as the objection above, now written as a task. The question is whether the thing your system needs to reason about is reachable, current, and permission-aware. Usually it is not.

4. Give it a way to render, not just to talk. This is the one everyone underestimates, and it is where the three protocols come in. I will do them properly in a moment.

5. Evaluation replaces the pass/fail test suite. This is the change that catches teams out. A completely green CI can ship a badly degraded AI release, because nothing in your test suite knows what a plausible wrong answer looks like. You need a set of golden examples, the hard cases, the failures you have already seen once, and a gate that runs before rollout rather than a dashboard that tells you afterwards.

6. Measure cost per successful task, not cost per call. Intelligence has a marginal cost, which is new for software people. Duolingo put generative AI inside its paid tier and then told shareholders what it cost: gross margin fell from 73.0% to 71.1% year over year, and the company pointed at the generative AI expense of expanding that tier as the main reason [7]. AI being expensive is not the lesson. The lesson is that a cheap model needing three attempts can quietly be the expensive one, and you will never see it if you are counting calls.

The three protocols, and which ones you need

Back to where we started. People keep lining these three up as competitors, and that is why the comparison never resolves. They are three different joints in the same skeleton. Once you see which joint each one is, the confusion goes away.

Underneath all of them sits MCP itself, which is how an agent reaches tools and data in the first place. Assume that. The three below are about what happens when the result has to reach a person.

AG-UI is the wire. It is an event stream between your front end and your agent backend [9]. The run started. The model is producing text. A tool is being called. The shared state just changed. The agent is waiting on a human. That is what your interface needs to know to stay in sync with something that thinks out loud and takes minutes rather than milliseconds. AG-UI's own map of the territory is the clearest one-line summary in the whole space [3]:

MCP gives agents tools; A2A allows agents to communicate with other agents; AG-UI brings agents into user-facing applications.

MCP Apps is how you ship an interface into somebody else's house. Your server declares an HTML template up front, under a ui:// address. A tool points at it. The host renders it in a sandboxed frame, and that frame talks back over the same JSON-RPC as the rest of the protocol [10]. The declaring up front is the clever part: it means the host can inspect what it is about to run before it runs it [1]. This is how your product turns up inside somebody else's assistant without them building anything for you. The specification has since reached Final status on the extensions track, and it has been live in Claude since January 2026 [6].

A2UI describes an interface instead of shipping one. Same problem, opposite answer. The agent sends a tree of components and the data behind them, as JSON. Your client renders that with its own approved widgets, which means it looks like your app, on whatever platform your app happens to be. The project sums up the difference in six words [8]:

Declarative data format, not executable code.

So which do you need.

If you are building your own AI-native product and you control the front end, you want AG-UI for the connection, and A2UI for the moments the agent needs to produce a surface you did not design in advance.

If you want your product reachable inside other people's assistants, you want MCP, and MCP Apps for the times a paragraph of text is not enough.

Most serious products will end up needing both, because of the thing I said earlier. You do not get to choose where the intent arrives.

And one piece of honesty, because this is young. Two well-funded answers to the same question is the definition of an unsettled standards fight, and I am not going to tell you which one wins. Keep the rendering layer thin and behind an adapter. The argument about what the paper is made of is not over.

Where this leaves you

The itinerary survives. The assembly does not.

That is the shape of the change, and it is why I opened with three protocols instead of a prediction. Three groups of serious engineers, working from different assumptions and different commercial interests, all arrived at the same requirement in the same month: an agent has to be able to hand a person something they can look at, check and approve. Not a transcript. An artifact.

They still disagree about how, and I would not wait that argument out. Their disagreement is the tell that we are early, which is the good part. Ground that is still moving is ground you can still take a position on.

So I would not spend the next quarter arguing about whether your product is AI-native. It is a label and it will be worn out by Christmas. Bring the other question to your next roadmap review instead, and ask it about every screen on the list.

How much work does this still make the human do?

References

1. Model Context Protocol, "SEP-1865: MCP Apps, Interactive User Interfaces for MCP." https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp
2. Google Developers Blog, "Introducing A2UI: An open project for agent-driven interfaces," 15 December 2025. https://developers.googleblog.com/introducing-a2ui-an-open-project-for-agent-driven-interfaces/
3. AG-UI, the Agent-User Interaction Protocol. https://github.com/ag-ui-protocol/ag-ui
4. Amazon Alexa Developer Blog, "Celebrating 100,000 Alexa Skills," 26 September 2019. https://developer.amazon.com/en-US/blogs/alexa/alexa-skills-kit/2019/09/congratulations-alexa-skill-builders-100-000-skills-and-counting
5. Amazon Alexa Developer Blog, "Introducing AI-native SDKs for Alexa+," February 2025. https://developer.amazon.com/en-US/blogs/alexa/alexa-skills-kit/2025/02/new-alexa-announce-blog
6. Anthropic, "Interactive connectors and MCP Apps," 26 January 2026. https://claude.com/blog/interactive-tools-in-claude
7. Duolingo, Q1 2025 shareholder letter. https://www.sec.gov/Archives/edgar/data/1562088/000156208825000098/q1fy25duolingo3-31x25share.htm
8. A2UI project site. https://a2ui.org/
9. AG-UI documentation, Agent-User Interaction Protocol. https://docs.ag-ui.com/
10. Model Context Protocol Blog, "MCP Apps: Extending servers with interactive user interfaces," 21 November 2025. https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/