Turning the OS into an Agent: A Prototype Phone Without an App Grid

On Reddit, a developer showcased a prototype phone project called Nagi that he has been working on for several months, and posed a rather direct question: would you actually carry a phone like this with you?

Product Concept: The Home Screen Isn't an App Grid, It's an Agent

The core premise of Nagi is quite radical — there is no full screen of app icons. What you see when you light up the screen is an Agent working on your behalf: what it's currently handling, what it's already completed, and which things need your decision. Interaction goes back to the most primitive form — "speaking" or "typing" — and the rest is left for it to execute.

This approach is fundamentally different from the current mainstream idea of "stuffing an AI assistant into the system." Most manufacturers add a voice entry point on top of the existing app ecosystem, keeping the home screen logic unchanged. Nagi does the opposite: it puts the Agent in the foreground and demotes Android apps to underlying capabilities that can be invoked but no longer occupy entry points.

The developer emphasized that he wants real feedback rather than upvotes, which suggests the project is still in an early validation stage, with the UI and interaction still carrying obvious signs of being a prototype.

Technical Breakdown: Local Models, Model-Agnosticism, and MCP-First

Nagi makes several notable trade-offs in its technical implementation.

A local LLM handles intent, memory, and context. According to the developer, context data does not leave the phone unless you actively connect to a cloud model. This is a selling point in privacy-sensitive scenarios, but it also means the device has to bear the inference load, which imposes certain hardware requirements.

Model-agnostic design. Users can connect OpenAI, Anthropic, run local models, or simply use the default configuration. This open posture reduces concerns about being locked into a single vendor, but it also brings challenges for consistency of experience — differences in instruction-following capabilities across models will be directly reflected in the Agent's performance.

Execution path: MCP / API first, driving native apps as a fallback. The developer admits that directly controlling regular Android apps is a "rather rough" path. This actually points to a common challenge for the entire category: when the target service does not provide an API or MCP interface, the Agent can only operate the interface by simulating clicks, and both stability and efficiency drop noticeably.

MCP (Model Context Protocol) is a protocol open-sourced by Anthropic at the end of 2024, aiming to establish a standardized communication interface between large language models and external tools and data sources. Before MCP, every AI application that wanted to connect to an external service (such as a calendar, map, or email) usually needed to write a separate set of adapter code for that service; as the number of services grew, adaptation costs increased linearly. MCP's approach is similar to USB-C: the model side only needs to implement a client once, and the tool side only needs to expose a standard server, and the two sides can interoperate. For Agent phones like Nagi, MCP-first means that when the target service provides an MCP interface, the Agent can take a semantically clear and highly structured invocation channel, with success rates and controllability far higher than simulated clicks.

However, MCP's current ecosystem coverage is still limited, and many mainstream consumer applications have not yet provided official MCP servers. This is also the fundamental reason Nagi has to retain the fallback path of "driving native apps." Protocol standardization solves the problem of "how to call," while "whether there is anything to call" still depends on the service provider's willingness to integrate.

Model-agnostic means that the system architecture is not tied to any specific large model vendor, and users can freely switch among OpenAI, Anthropic, local open-source models, or other backends. This approach is becoming increasingly common in current AI products, mainly for three reasons: first, to avoid vendor lock-in, so that when a vendor raises prices, limits usage, or changes its API, the product is not forced to adjust accordingly; second, to let users choose according to privacy and cost preferences, so sensitive data can go only through local inference; third, to facilitate continuous tracking of model iterations, so new models can be quickly integrated after release without restructuring.

The cost is consistency of experience. Different models differ significantly in instruction following, tool-calling formats, context windows, and multi-step reasoning capabilities. The same Agent workflow may succeed in one run on a strong model but fail repeatedly on a weak model. Therefore, model-agnostic products usually need an additional layer of capability detection and degradation strategies. This also explains why Nagi includes "default configuration" as one of the options — it provides a tuned baseline for users who do not want to tinker.

Interaction Design: One Physical Button and Reusable "Experiences"

Nagi keeps only one physical button on the hardware: press and hold to speak, tap to record a note. This design compresses input methods to the bare minimum, consistent with the idea that "the home screen is the Agent."

More interesting is the concept of Experiences — reusable multi-step workflows, such as "call a car to go home," "plan a trip," or "clean up the inbox and draft replies." Users do not need a builder or code; they only need to describe it once in natural language to generate a new workflow.

This is equivalent to dropping the threshold for "automation scripts" to zero, while shielding ordinary users from the complexity of workflow orchestration. However, based on the description, the quality of Experiences depends heavily on the underlying model's comprehension ability and the coverage of MCP interfaces.

Running a local LLM on the device does not mean moving a cloud model into the phone as-is. Instead, it usually uses small models in the 1B to 8B parameter range, compressed through quantization (such as 4-bit quantization) to reduce memory usage and power consumption. Current mainstream flagship phones generally have 12GB or more of RAM, which is barely enough to carry inference for small and medium-sized models, but it will squeeze memory space for other applications, and the heat and power consumption caused by continuous inference remain obvious bottlenecks.

Another common path is cooperation between phone manufacturers and chipmakers to use NPUs to accelerate inference and keep models resident on dedicated hardware. Regardless of the approach, local model capabilities are clearly weaker than cloud-based large models, so actual products often adopt a hybrid strategy: lightweight tasks such as intent recognition and memory retrieval stay local, while complex reasoning calls the cloud as needed. Nagi claims that "unless you actively connect to the cloud, context does not leave the phone," which in engineering terms means it presses the entire Agent loop onto the device side, imposing hardware requirements an order of magnitude higher than ordinary "local wake-word recognition."

Real-World Constraints: Dual Resistance from the App Ecosystem and User Habits

Nagi retains compatibility with regular Android apps — they can still be installed and used normally, just no longer occupy the home screen. This compromise is pragmatic, but the problem follows: when users need to actively open an app, how do they find it? The original post does not elaborate on navigation details.

Another real issue is habit. Over the past decade or so, smartphones have trained users to form a conditioned reflex of "find the icon — open the app." Changing this path requires not only technical capability but also strong enough persuasion. By throwing the question to the community, the developer essentially acknowledges that this has not yet been solved.

A Direction Worth Watching

Nagi may not become a mass-produced product, but the question it raises is solid: if the Agent is truly reliable enough, is it still necessary for the app grid to occupy the home screen? This round of reconstruction attempts from the system layer to the interaction layer is being taken seriously by more and more teams.

For developers, the model-agnostic plus MCP-first architecture is worth referencing; for ordinary users, whether they are willing to hand over the phone's home screen may depend on exactly how much the Agent can get done.

One-line Summary

Nagi, a prototype phone, removes the app grid and makes the Agent the home screen entry point, exploring a new form of phone interaction.

Paragraph Summary

Nagi is a prototype phone project that a developer has worked on for several months. Its core premise is to remove the app icon grid and make the Agent that is doing the work the home screen. Technically, it uses a local LLM to handle intent, memory, and context, adopts a model-agnostic design, and allows users to connect OpenAI, Anthropic, or local models; task execution prioritizes MCP and APIs, with driving native Android apps as a fallback, though the author admits this path is rough. In interaction, it keeps only one physical button and introduces Experiences — users can generate reusable multi-step workflows simply by describing them in natural language. The biggest real-world resistance comes from the app ecosystem and user habits: after retaining Android app compatibility, how users actively open a given app is a question the original post does not answer.