A flagship phone can run big games smoothly, and the gap with computers shrinks year by year. But put an Agent to work on a phone and the picture is completely different: it can’t execute a single command, can’t touch files, can’t call tools. Compute keeps rising; operability hasn’t followed.
What lets Agents work on a computer
An Agent’s capabilities on the desktop rest on decades of accumulated infrastructure: the file system, the command line, FFmpeg, Git, Bash. One concrete scenario: a brand-new Linux distro has been installed, networking isn’t configured, and the various config files offer no way in — after installing ZCode, everything is handed over to it. Some systems even ship a dedicated command-line tool that delineates for the Agent what may and may not be changed; if the UI crashes or the screen goes black, the Agent can repair itself.
The toolchain also extends the output beyond code. The soundtrack for a promo video can be written in Python and MIDI, following the rhythm of the video so you can’t tell it was generated by a program; with tools like Blender, 3D modeling and rendering live in the same executable world. These capabilities share one precondition: the Agent can execute things within the system.
The sandbox blocks the same capabilities
None of this runs on a phone. Node and the usual scaffolding and component tools won’t run inside the app sandboxes of iOS and Android; debugging channels like Android’s ADB have also been locked down more and more in recent years. The result: on a phone with compute to spare, an Agent can access nothing — having an on-device model alone is useless, because the model is local while its hands and feet are tied.
One specific bug shows how small the gap can be. A small app built to replace a fitness app — recording rides and announcing kilometers covered — took half a day to a day to develop on the computer, but only in testing on the phone did it turn out the location permission had never been requested, and the entire recorded ride read zero speed. The problem wasn’t compute, and it wasn’t hard to fix — with on-device debugging, it would be one line adding a permission request. The hard part isn’t technical; it’s that the phone leaves developers no place to do it.
The same contrast shows up in interaction. Voice-driven computer use is becoming more common, and real-time speech models are being released in rapid succession; on the phone, though, this kind of interaction is largely confined within individual apps — the OS offers no deeper entry point, so no amount of voice capability gets anywhere beyond the app it lives in.
Context, too, stays on the computer side
Beyond execution capability, context also tilts toward the computer. A personal Memory can simply be the file system and documents — mount your own storage and it syncs automatically, no third-party service required; multimodal images and video have somewhere to live. On a phone, information is locked inside individual apps; even downloading a file from the cloud, just finding it afterwards is a struggle.
So the practical division of labor becomes: put the execution environment on a computer or a machine you control. One person loaded several purchased Coding Plans into a virtual machine on a Raspberry Pi, letting the Agents schedule themselves and cover for each other; scheduled jobs, information triage, and PR reviews all run on that little machine. In this round of division of labor, the phone is mostly the end that gives orders, not the end that does the work.
The box the system draws, and the gaps in it
Under these constraints, today’s viable paths all stay within what the system allows, each with its cost:
Cloud execution is the natural choice for offloading heavy work — it saves battery and local resources — but the parts that need to interact with on-device information always remain on the phone, and that is precisely the hardest part.
Vendors’ own channels are the privileged path. Phone makers can use system-level capabilities to connect a phone’s assistant to a computer, operate across devices, even read favorites and photos inside apps. This is an in-system channel; ordinary developers can’t get equivalent access.
Removing system protections would indeed open more up, but the cost is clear: after rooting or unlocking, apps can detect it, and banking apps simply stop working; the debugging interfaces under developer mode are more loosely guarded, but that is just the current state, not a generalizable solution. Treating “unlocking” as a universal fix leaves the risk on the user alone.
The community is also probing the gaps the system leaves. One direction borrows the browser component built into iOS — it is a system component with broader permissions than ordinary apps — to run Node.js and the command line; another compiles and renders a UI locally straight from a .swift file: the AI writes a file, you confirm, and the app runs. Both of these claims currently exist only at the level of demos and discussion; whether the libraries can pass app review, and how stable they are, still need engineering verification. What makes them worth mentioning is that they name the nature of the problem: the restriction comes from system policy, not from technical impossibility.
Compute is in place; the environment isn’t
In the Agent era, the gap between phone and computer is no longer about the chip. Files, commands, the permission model — the things that let an Agent work — the phone either lacks or withholds. A cycling app’s bug shows the gap can be as small as one permission request; the vendor channel shows the key is held by the system; the community libraries show gaps exist but remain unverified. Compute is in place; the open question is when the software environment catches up — that is what decides whether the phone is the Agent’s remote control, or its workstation.