Why Android and iOS will never be enough for an AI-first smartphone

Over the past year, I’ve found myself repeatedly hitting the same limitation with “agentic AI” tools. They’re impressive at first — summarising emails, setting reminders, even writing code — but only within a narrow set of built-in capabilities. The moment you try to stretch them into something slightly more ambitious or personalized, they simply aren’t designed to go there.

To go beyond these constraints, we can take two approaches. One is structured tool exposure — frameworks like the Model Context Protocol (MCP), which allow external cloud services to hook into your agent of choice. Anthropic, OpenAI, and most other platforms support MCP. The other is more experimental: giving agents, like OpenClaw, broader system-level access to our personal machines.

This is where ideas like letting an AI read your emails, manage your smart home, or trigger real-world actions start to emerge. But it raises a much more fundamental question about the future of our increasingly AI-centric mobile operating systems: are we mistakenly shoehorning a new way of computing into something that was never built for it?

How does AI actually do anything?

Before we go there, one often misunderstood concept about agentic AI is how it actually works. When you ask an AI to set a calendar event or generate a text document, it isn’t executing those tasks directly. Gemini doesn’t peer through your Gmail app to check your inbox, or scroll Chrome in the background to find the info you’re after. It’s still just a language model reading text in and producing text out — that’s all it can do.

However, that text output can include structured “tool calls” — requests for external systems to do something on its behalf. A separate platform layer intercepts these requests, runs the appropriate software, and returns the result back to the model before it, in turn, hands its answer back to you.

For example, let’s ask Gemini to summarise a webpage. Google’s AI model doesn’t browse the internet on its own little computer somewhere. Instead, it calls a fetch tool, receives the page’s raw HTML, and then generates the requested summary. In some sense, that orchestration layer is the really vital cog that turns your AI from a chatbot into a proper personal assistant.

In practice, every AI capability is just a set of external functions it has to ask someone else to execute, ranging from on-device code snippets to calling out to another service or MCP. While our first smartphone assistants could only perform basic tasks like setting alarms and checking reminders, Google and Apple are now moving quickly to embrace a broader approach to AI tools. But what’s the best way to actually do it?

Is it time for an entirely new AI OS?

I don’t think we want to revisit the Rabbit R1, but hopefully you can see there’s potential value in platforms built for AI-first use rather than shoehorning features into systems that were never built with them in mind. Deciding exactly what data and tools AI can access, how these are controlled, and in what scope, is a bigger problem than it might seem at first and one that doesn’t necessarily align with today’s app-first model.

Take powerful, popular AI tools like Claude Code and Codex, which, with a little effort, can branch out from their code-first origins into talking to other services and even run small tasks on your behalf. Ironically, Microsoft has cottoned onto a reasonable idea with its Project Solara prototype, an OS built specifically to run specialized AI agents for specific tasks. Though I’m not completely convinced by an AI-led UI experience, and this doesn’t exactly sound like the sort of expansive platform AI would really need to flourish.

Google is working on its own solution to this problem for Android with its new AppFunctions framework, whispered about at I/O 2026. In a nutshell, this experimental API allows apps to expose tools to Android’s Gemini AI agent, enabling direct communication between apps and AI. That’s certainly a step in the right direction, akin to an on-device version of an MCP server — the apps are just local rather than in the cloud.

Google’s approach is quite likely to succeed at the core objective of making Gemini far more useful and “agentic.” AppFunctions are very simple for developers to build on, run on-device with no latency and enhanced privacy, and interact directly with the app state. It also leverages Android’s permission and privileged-agent model, which is a good security feature for blocking functions you don’t want to run.

AppFunctions and MCP are highly interoperable, but Google’s approach still appears quite restrictive compared to what’s already possible on other platforms. For instance, we’re limited to the functions exposed by apps and the OS, and still lacking any hint of long-term project scratchpads or self-learning capabilities.

AppFunctions are useful for task automation but structurally incapable of supporting more autonomous workflows that span multiple systems or of maintaining state across long-term tasks on their own. Asking Gemini to book a cab, add milk to your shopping list, and cancel a hotel booking will be game-changing enough for many users, but AppFunctions seems unlikely to open the door to your phone managing your stock portfolio, budgeting, and booking an entire vacation away, or building its own solutions to unique problems.

AI-first for an AI world

Of course, those more advanced, multi-step, long-task use cases are exactly what make some existing tools a security nightmare to use in practise. An agent that understands you, your needs, and your data is far more powerful than just expanding tool calling, but it’s also inherently riskier, especially when given unfettered access to your accounts and documents. However, these benefits can be realized with careful scoping; essentially, giving an AI a carefully bounded environment of its own to accomplish specific tasks.

Proper sandboxing is the key, but that’s not as easy a solution as it might seem. Containers and virtual machines are too resource-intensive to spin up for multiple agentic tasks. WebAssembly (WASM) shows promise for lightweight, secure applications, but the specification is a broken mess when it comes to cross-language support for developers. There are also lingering questions over sensitive data management and history (you don’t want your AI to retain context of your emails in plain-text memory), per-task permissions and shared memory, and how to handle authentication between agents and services. Whoever solves these problems will have a very powerful AI-centric tool at their disposal that could potentially upend Android and iOS as the AI platforms of the future.

Until then, AppFunctions, MCP, and similar frameworks are incredibly useful because they make today’s operating systems accessible to AI. They’re the future of mobile AI in the short term, but crystal ball gazing a bit further ahead is far less clear. Given how the wind is blowing, it seems agent-service integrations could be the future rather than apps.

Do you really need a 300MB taxi app when an MCP request will do? Do we want cluttered app drawers and notification shades when everything is at the end of a quicker voice command? If AI really is the primary way we will interact with computing in the future, we may need to rethink what a smartphone operating system is built to do from the ground up.