The two paths of AI: competition for cloud entry or native applications on the user side?
Recently saw Alibaba release the Tongyi Qianwen App, officially entering the C-end app battle. Sam Altman has also repeatedly expressed his obsession with "super apps," continuously integrating various social features into ChatGPT.
In the narrative of major tech companies, the future AI app seems destined to be a replica of the current internet super applications - becoming the sole entry point and consolidating multiple functions into one.
But will the future of AI applications really converge on this one path? Is there the possibility of other avenues?
If we shift our focus away from general AI chat applications and look at programming tools like Cursor and Windsurf, integrating various MCP tools, we might glimpse the distinct pulse of AI native applications.
The Disappearing Moat and Everyone's Sense of Insecurity
In the current AI application ecosystem, if we use a biological organism as a metaphor, it can be broken down into three roles:
* Brain (LLM model provider): Provides reasoning, decision-making, and foundational knowledge. * Body (Client Provider): Provides user interaction interface (UI/GUI), context environment, and memory. * Hands and Feet (Tool Service Provider): Provides specific capabilities, such as search, calendar, booking, payment, and other MCP tools.
In an ideal state, the client (body) links the brain and limbs together to help the user solve problems.
In the internet age, the barriers to applications come from two things: the interface (UI) and the interface (API). Users can only complete specific services through a specific interface. But when demand can be expressed in natural language, the Prompt becomes the new interface, and the API barriers begin to loosen. The "boundaries" between applications start to become unstable.
This leads to an extreme lack of security for every role in the ecosystem:
* LLM vendors fear becoming "pipelines": If they only provide APIs, users won't feel it. Users might use Claude 4.5 today, switch to GPT 5.1 tomorrow, or GLM-4.6, and model vendors could be replaced at any time by cheaper computing power. To avoid being "pipelines", they must enter the client side (body) and keep users within their own apps. * Clients are afraid of being "choked": this is the so-called "shelling" anxiety. If the core brain is in someone else's hands, it could be cut off or prices could rise at any time. As a result, those developing applications are also starting to train their own models, trying to possess a brain. * Tool providers fear "invisibility": For example, if a local lifestyle recommendation platform becomes an MCP tool, where users interact directly with AI for inquiries, this platform would completely degrade into a basic API service provider, and its original interface value and advertising revenue would directly collapse. Thus, they are unwilling to accept this and attempt to forcibly integrate AI functions into their applications in an effort to retain users.
The result of this "everyone's anxiety" is the current chaos: everyone is trying to be a full-stack, attempting to completely control their brain, body, and limbs.
Path One: Cloud Leviathan (Super Entrance)
To alleviate this anxiety, the solution provided by the large companies aligns very well with their habitual thinking: replicating the story of super applications on the internet.
From the perspective of model manufacturers, the assembly of the brain and limbs should ideally not occur on the client side, as that would place control in the hands of the user. They hope the client can revert to a "Thin Client" mode—only retaining the ability to receive voice or text commands.
In this architecture:
The brain in the cloud: Decision-making and reasoning are completely controlled by the vendor. Hands and feet in the cloud: Access the back end of major companies through Function Calling or Plugin. Memory in the Cloud: Users' data, preferences, and history are all uploaded.
This allows for a perfect replication of the logic of super applications, and is even more terrifying than internet super applications. In the internet era, although super applications monopolized traffic, the data between services was still somewhat isolated. However, in "AI super applications," the manufacturers not only control the entry point but also master all the decision-making logic in between through their models.
This is a perfect "cloud leviathan," highly efficient, but users in this system have no privacy or choice, merely being fodder for the algorithms.
Path Two: AI Native Applications - User-side Integration
But there is also another possibility, this trend has already become very clear in the programming field.
Take a look at the current AI editor (IDE): the main body is on the user side, the codebase is local, and all business logic and context are local.
The brain is pluggable: you can configure different models in the IDE, even if the IDE does not support configuration, adding a layer of interface proxy conversion can also solve it. The hands and feet are standardized: The emergence of protocols like MCP has turned tools such as databases, Git, and terminals into standard Lego blocks.
In this architecture, applications are not walled gardens that large companies use to corral users, but rather "exoskeletons" that are worn by users.
In this mode, integration occurs on the client side. The application organizes the user's local data (Context) and calls upon the cloud or local "brain" for processing as needed, then directs standardized "hands and feet" to execute.
The core data and logic remain on the user's side. At least, your data won't all be in the hands of a single vendor; at least, when a certain model becomes dumb, you can switch to a smarter brain.
Of course, this path is not smooth, and the biggest challenge lies in the lack of infrastructure: without the unified identity authentication (Auth) completed by major cloud service providers, it is a huge challenge to integrate various tool services' identities, payments, and build sustainable business models on the client side, and currently, a clear path is not yet visible.
But I believe that decentralized ID (DID) and payment networks in the Crypto field can play an important role here, providing the foundation of trust and settlement for this decentralized AI collaboration. We will discuss this topic in more detail in our next article.
The Game of the Future
The current technological evolution is at a crossroads: on one hand, large companies are trying to "converge" all their capabilities behind their own APIs, building a closed ecosystem; on the other hand, developers are attempting to construct a "decoupled" open ecosystem utilizing technologies such as MCP and Local LLM.
The future depends on the game between users, manufacturers, and developers in the present. Everyone's choices are essentially voting for one of these two futures.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
The two paths of AI: competition for cloud entry or native applications on the user side?
Recently saw Alibaba release the Tongyi Qianwen App, officially entering the C-end app battle. Sam Altman has also repeatedly expressed his obsession with "super apps," continuously integrating various social features into ChatGPT.
In the narrative of major tech companies, the future AI app seems destined to be a replica of the current internet super applications - becoming the sole entry point and consolidating multiple functions into one.
But will the future of AI applications really converge on this one path? Is there the possibility of other avenues?
If we shift our focus away from general AI chat applications and look at programming tools like Cursor and Windsurf, integrating various MCP tools, we might glimpse the distinct pulse of AI native applications.
The Disappearing Moat and Everyone's Sense of Insecurity
In the current AI application ecosystem, if we use a biological organism as a metaphor, it can be broken down into three roles:
* Brain (LLM model provider): Provides reasoning, decision-making, and foundational knowledge.
* Body (Client Provider): Provides user interaction interface (UI/GUI), context environment, and memory.
* Hands and Feet (Tool Service Provider): Provides specific capabilities, such as search, calendar, booking, payment, and other MCP tools.
In an ideal state, the client (body) links the brain and limbs together to help the user solve problems.
In the internet age, the barriers to applications come from two things: the interface (UI) and the interface (API). Users can only complete specific services through a specific interface. But when demand can be expressed in natural language, the Prompt becomes the new interface, and the API barriers begin to loosen. The "boundaries" between applications start to become unstable.
This leads to an extreme lack of security for every role in the ecosystem:
* LLM vendors fear becoming "pipelines": If they only provide APIs, users won't feel it. Users might use Claude 4.5 today, switch to GPT 5.1 tomorrow, or GLM-4.6, and model vendors could be replaced at any time by cheaper computing power. To avoid being "pipelines", they must enter the client side (body) and keep users within their own apps.
* Clients are afraid of being "choked": this is the so-called "shelling" anxiety. If the core brain is in someone else's hands, it could be cut off or prices could rise at any time. As a result, those developing applications are also starting to train their own models, trying to possess a brain.
* Tool providers fear "invisibility": For example, if a local lifestyle recommendation platform becomes an MCP tool, where users interact directly with AI for inquiries, this platform would completely degrade into a basic API service provider, and its original interface value and advertising revenue would directly collapse. Thus, they are unwilling to accept this and attempt to forcibly integrate AI functions into their applications in an effort to retain users.
The result of this "everyone's anxiety" is the current chaos: everyone is trying to be a full-stack, attempting to completely control their brain, body, and limbs.
Path One: Cloud Leviathan (Super Entrance)
To alleviate this anxiety, the solution provided by the large companies aligns very well with their habitual thinking: replicating the story of super applications on the internet.
From the perspective of model manufacturers, the assembly of the brain and limbs should ideally not occur on the client side, as that would place control in the hands of the user. They hope the client can revert to a "Thin Client" mode—only retaining the ability to receive voice or text commands.
In this architecture:
The brain in the cloud: Decision-making and reasoning are completely controlled by the vendor.
Hands and feet in the cloud: Access the back end of major companies through Function Calling or Plugin.
Memory in the Cloud: Users' data, preferences, and history are all uploaded.
This allows for a perfect replication of the logic of super applications, and is even more terrifying than internet super applications. In the internet era, although super applications monopolized traffic, the data between services was still somewhat isolated. However, in "AI super applications," the manufacturers not only control the entry point but also master all the decision-making logic in between through their models.
This is a perfect "cloud leviathan," highly efficient, but users in this system have no privacy or choice, merely being fodder for the algorithms.
Path Two: AI Native Applications - User-side Integration
But there is also another possibility, this trend has already become very clear in the programming field.
Take a look at the current AI editor (IDE): the main body is on the user side, the codebase is local, and all business logic and context are local.
The brain is pluggable: you can configure different models in the IDE, even if the IDE does not support configuration, adding a layer of interface proxy conversion can also solve it.
The hands and feet are standardized: The emergence of protocols like MCP has turned tools such as databases, Git, and terminals into standard Lego blocks.
In this architecture, applications are not walled gardens that large companies use to corral users, but rather "exoskeletons" that are worn by users.
In this mode, integration occurs on the client side. The application organizes the user's local data (Context) and calls upon the cloud or local "brain" for processing as needed, then directs standardized "hands and feet" to execute.
The core data and logic remain on the user's side. At least, your data won't all be in the hands of a single vendor; at least, when a certain model becomes dumb, you can switch to a smarter brain.
Of course, this path is not smooth, and the biggest challenge lies in the lack of infrastructure: without the unified identity authentication (Auth) completed by major cloud service providers, it is a huge challenge to integrate various tool services' identities, payments, and build sustainable business models on the client side, and currently, a clear path is not yet visible.
But I believe that decentralized ID (DID) and payment networks in the Crypto field can play an important role here, providing the foundation of trust and settlement for this decentralized AI collaboration. We will discuss this topic in more detail in our next article.
The Game of the Future
The current technological evolution is at a crossroads: on one hand, large companies are trying to "converge" all their capabilities behind their own APIs, building a closed ecosystem; on the other hand, developers are attempting to construct a "decoupled" open ecosystem utilizing technologies such as MCP and Local LLM.
The future depends on the game between users, manufacturers, and developers in the present. Everyone's choices are essentially voting for one of these two futures.