Phones are the device regular people use AI on most frequently, yet the task completion rate is absurdly low. If you set up a coding Agent in front of a computer, it can grind away on its own for twenty minutes. In those twenty minutes, it will comb through a dozen files and casually refactor a complex engineering project. Switch to a mobile screen, though, and daily interactions mostly remain stuck in back-and-forth chat. The exact same underlying LLM, separated by two different form factors—desktop versus phone screens—ends up delivering results that are an entire order of magnitude apart. Simply put, AI on phones is still just a chatbot companion that can only talk.
This huge gap actually lies outside the model itself. We need to understand that an Agent capable of working autonomously consists of two core components. One is the decision-making brain—the LLM itself. The other is the execution environment where tools actually run—the hands and feet working on behalf of the brain. On desktop, this execution environment comes with a natural default answer: the built-in command-line console. The brain decides what commands to issue, the program runs directly, and if it hits an error, it falls back and retries. Mobile operating systems, by design, blocked this path right from the start for security reasons. iOS blocks Apps from spawning child processes, isolating Apps within their own dedicated sandbox areas. Both App stores have explicit restrictions against downloading and executing code. It’s like putting layer upon layer of shackles on AI—without reliable hands and feet for execution, no matter how smart the brain is, it can hardly push concrete tasks forward. When you ask a genius whose hands and feet are completely bound to do work, the result obviously won’t be great.
However, things have taken a turn. On August 18, a Chinese company named APUS open-sourced a project on GitHub called PhoneBuddySDK. It’s a library for App developers: you stuff it into your iOS or Android App, and your App gains an AI Agent, offering a new solution to mobile OS constraints. Before diving into this open-source code, let’s map out the existing routes for mobile Agents. Understanding these old paths helps us clearly see where this new solution fits and what engineering bottlenecks it actually addresses. You have to know the background to really see what’s going on.
Let’s examine the existing Agent forms on mobile one by one. If you look closely, you’ll find every path is missing a key puzzle piece. The most common in daily life is chat applications. Products like ChatGPT and Doubao host their brains on cloud servers. Via vendor-provided interfaces, the model can search for information on the web or generate a few images. What it simply can’t touch are local files, photos, or other third-party Apps on the device. This toolset is defined uniformly by the provider in the cloud, so if an independent App wants to tap into similar deep capabilities, it can’t find an entry point at all. They are like deities living in cloud castles—seeing far, but unable to manage the everyday chores inside your phone.
Following the OS entry points further down, let’s talk about system-level voice assistants, which have the deepest access. Siri occupies the deepest system entry point, invoked with a long button press or a single phrase. Unfortunately, how deep it can go depends entirely on the hardware vendor’s unilateral implementation. Third-party Apps can only expose a small set of action commands to it through minimal system-provided interfaces. The orchestration logic remains closed off to developers. The assistant itself has long stayed at surface-level interactions like setting alarms and checking the weather. If you ask it to do something complex, it will just give a silly response or say it doesn’t understand. It sits closest to the OS, yet remains the most rigid.
Now look at the third category: treating the phone directly as a remote control and offloading the work to a remote server or computer. This approach is nothing new on the desktop side—Claude Code, Codex, and Cursor all execute long-running tasks inside their own managed cloud sandboxes, as I covered in an earlier article. The mobile version is a natural extension of this. Tencent’s WorkBuddy allows users to send messages on their phones to dispatch tasks to cloud servers or personal computers (Tencent Cloud Documentation). Doubao also launched a new feature on August 17 enabling phones to remotely control authorized computers (Report). This route pushes capability to the max—think about it, there’s an entire computer behind it at its disposal. The trade-off is equally clear: the execution environment stays entirely remote. Screen content, file interactions, and operation logs all reside in the cloud or on another machine. If your phone loses internet connection, you can’t issue new commands or receive progress updates—though the cloud task itself is likely still running, so you can just check back for results once reconnected. The permission boundaries are also drawn entirely on the remote end. The phone acts merely as an initiator and receiver, taking on no concrete execution actions itself. It’s just like playing a cloud game on your phone: the screen is on your device, but all the computing happens in a far-off server room.
Though these three forms seem diverse on the surface, they share a
common trait: none of their execution environments reside inside the
mobile App’s own process. They either sit in the vendor’s cloud, in the
OS layer, or on another remote device. The reason for this huge gap lies
in strict platform constraints. iOS blocks the fork call
with zero engineering compromise. Apps must stay obediently inside their
own isolated sandboxes. Store reviews strictly regulate code execution.
Apple’s review guidelines explicitly require Apps to be self-contained,
prohibiting the execution of downloaded code that changes functionality
(Guideline
2.5.2). Google Play’s rules are equally strict, banning the download
of native executable code from outside the store, leaving an exception
only for scripts inside an interpreter (Original
Policy).
Taking all these constraints together, the primary problem for mobile Agents can be framed as a spectrum. On one end of the spectrum is the cloud, where the brain is strongest but furthest from the phone’s context. On the other end, context is right at hand, but the platform strips away the execution infrastructure entirely. The two ends are naturally at odds, because moving context comes at a cost. You either move context to compute power, or move compute requests to context. Desktop Agents bypassed this bottleneck thanks to a default command-line console. The lack of a default answer on mobile forces every route to find its own point on this spectrum. Everyone is trying their own trick to pull it off.
Let’s look at one end of the spectrum first: some solutions choose to place execution actions furthest away, relying on cloud or remote hosts. This represents the extreme of having the strongest brain. Tasks run comfortably inside virtual machines in the cloud or on the user’s personal computer. Remote machines feature complete development environments with everything at hand, and long-running tasks aren’t bound by phone battery life. The trade-off here is just as extreme: its eyes and hands/feet are severely constrained—it can’t read files on the phone, nor trigger other Apps. The phone only dispatches commands and receives final results, meaning context must be moved wholesale to the cloud. Once data leaves the local device, if the phone loses internet, all you can do is wait; control channels are temporarily severed, and permission settings are drawn on the remote end.
Next, look at moves at the OS level: some tech giants choose an
intermediate assembly strategy with the OS as the proxy, minimizing
context movement at function-level granularity. Apple offers App Intents
for Apps to expose specific capabilities to Siri and the OS. Starting
from iOS 26, the Foundation Models framework opens an on-device model
(~3B parameters) and tool-calling mechanisms to third parties (Documentation).
This year’s WWDC featured a dedicated session guiding developers on how
to add security checkpoints to intelligent features (Session
Video). Google introduced AppFunctions in Android 16. The core idea
is to make each App an on-device MCP server inside the phone. Apps
declare which functions they can execute using annotations. The OS
centrally maintains a global registry, and callers must request the
EXECUTE_APP_FUNCTIONS permission before invocation (Official
Documentation). This permission model resembles database privilege
tables, declaring and granting capabilities item by item. The current
state remains in early exploration: the Jetpack library for AppFunctions
was still in alpha as of July 2026, and Gemini’s deep integration is in
private preview.
Within this category exists a higher-privilege variant: OEM-level GUI Agents. Doubao Phone Assistant’s partnership with nubia phones chooses to read screen content directly and simulate clicks, operating across all App boundaries (nubia Announcement). On the surface it appears most powerful, holding the broad permissions. Yet because the specific semantics of every action are hidden inside complex UI interaction details, security auditing is far harder than with declarative interfaces. It’s tough to tell what it actually clicked on, making the security cost of this black-box operation quite high.
If you find the OS moving too slowly, developers can choose to keep execution inside the App process. This assembly strategy splits and recombines the two ends of the spectrum: keeping the brain in a cloud API while moving the hands, feet, and eyes into the App, achieving zero context movement within the App scope. Developers embed an Agent engine directly into their App codebase. The depth of capability is defined by the developer, with all data staying strictly inside the App sandbox. The same engine can be reused across both iOS and Android. The upper limit of what it can reach is bound by the host App’s own permissions—an Agent in a photos App can’t touch system contacts. That’s the trade-off of in-process execution, and also the direct source of clear system boundaries: how much power you want depends on how much power the App itself holds.
These three routes are essentially three assembly strategies along the spectrum. OS interfaces handle cross-App orchestration—the OS holds the complete registry and permission system, fully justified. In-process runtimes offer developers the freedom to choose their spot within their own App. The significance of PhoneBuddySDK lies in how it parameterizes this trade-off: developers select the capability set, and the boundaries are strictly drawn. It might not be the absolute perfect spot, but it gives developers their own tool to choose a point on the spectrum. It also represents the most deeply realized in-process implementation among currently public samples. While others are still pacing outside the door, it has already stepped inside and started decorating.
The underlying engine of PhoneBuddySDK is written entirely in Rust. It embeds into the App process via C interfaces alongside Swift and Kotlin bindings, open-sourced under the Apache 2.0 license. The v0.1.1 release notes state that the code was ported from xAI’s open-source grok-build project. It forcibly compresses the desktop Agent execution machinery into a single App process. Tool-calling loops, streaming content output, session state management, and subtask orchestration all execute inside the process, with zero child processes. That’s its trick—carving a sanctuary inside a nutshell.
The most valuable reference point of this project is that it didn’t fake a command-line terminal to trick the underlying model. Instead, it re-implemented every capability required by the Agent in code, wrapping each operation in a controlled execution fence. I went into the source code and counted them—these cages are actually written in the code, no fluff.
The outermost restriction applies to file access. All path strings
received by file tools must pass through a resolve
function. The program first performs lexical normalization, verifying
that the target path indeed falls within the designated
root directory. If the path already exists on the
filesystem, the program resolves the real path again to guard against
symlink escape risks (fs.rs).
Even if the model hallucinates an absolute path outside the App
directory, the system stops it right at this step.
Moving inward, another restriction locks down network requests. The
core web_fetch tool by default rejects any intranet address
access. Blacklist rules cover loopback addresses, RFC 1918 private
subnets, CGNAT subnets, and benchmark reserved ranges, among others.
Even if developers explicitly enable local access, the system only
allows explicitly declared loopback hostnames (ssrf.rs).
This design guards against a maliciously manipulated Agent secretly
scanning service ports on the local network connected to the phone.
Next, let’s look at restrictions on script execution. The model can
write JavaScript code and hand it to the in-process embedded
boa interpreter to execute. The file operation interfaces
exposed to these scripts consist of only three functions, corresponding
to reading files, writing files, and listing directories. Every call
must pass through the exact same file cage checks without exception. The
script environment lacks network interfaces and system call functions.
Loop iteration limits are capped at 20 million, and output string
lengths are capped at 30,000 characters (script.rs).
Yet another restriction manages subtask lifecycles. Subtasks are not
created using process fork operations. Instead, they run as
async tasks inside the same process, each maintaining an independent
conversation loop capped at a maximum of 10 interaction turns. External
callers can query task status at any time, wait for execution results,
forcibly terminate execution, or resume state from a checkpoint (task_manager.rs).
This ensures that even if a task strays off course, it can be pulled
back at any time, keeping everything under control.
The final restriction handles failure convergence. If the exact same tool is invoked with identical parameters 8 consecutive times, the system injects a warning message into the model. If repeated 16 times, the entire interaction turn terminates immediately. The system also specifies a default limit of 24 execution turns per user message (doom_loop.rs). For scenarios where the model loops repeatedly in place, clear circuit-breaker conditions are built into the code. This prevents meaningless battery drain and token consumption. The moment something looks off, it pulls the plug right away.
On top of these five strict boundaries, it provides a restricted
toolbox. Common commands like cat, ls,
sort, and find are simulated in Rust within
the process. The model assumes it holds a full system command line, but
each command it issues actually maps to a deterministic logic
implementation under the hood. It’s like handing the model a set of toy
tools—they look real, but act entirely well-behaved when used.
To be honest, this project is still very young. It was made public on
August 18. Checking its repository code, I found 24 stars, only one
visible contributor, no issues or PR records, and no security policy
file attached. On the second day after launch, the author released a
patch fixing packaging issues. The performance numbers in the README and
claims of reaching Claude Code levels are strictly vendor-asserted, with
no independent third-party verification so far. After reading through
the source code, I also spotted two points of doubt. The documentation
claims that the C interface boundary uses catch_unwind to
catch Rust panics, but no such call can be found in the current source
directory, and the release build profile still specifies aborting the
process immediately upon panic. The web_fetch tool only
re-checks the final destination address after all redirects are
completed, lacking a hop-by-hop interception mechanism, meaning
intermediate redirects could theoretically connect to internal IP
addresses before triggering a block. For now, these two details remain
doubts awaiting response from the maintainers, and should not be treated
as final conclusions yet. Let’s not rush to judgment.
At this stage, it’s still too early to use it directly in production. Treating it as a solid architectural reference sample is just right. It provides a clear answer: boundary design for mobile Agents must always take priority over mere feature stacking. Missing features can always be added later; but once permission boundaries fall, the more capable the system, the more dangerous it becomes.
Back in November last year, I wrote an article discussing AI-native software engineering (Beyond DRY). It contained a core premise: once AI gains the ability to generate software on the fly, software deliverables shift from fixed-feature finished products to generative kernels. This kernel comprises three key components. Core Suites provide irreplaceable foundational capabilities, like the pre-drilled seat panels and legs of IKEA furniture. Guided Knowledge acts as instruction manuals written for AI, which the model reads in seconds to replace domain experience accumulated by human engineers over years. Leveraged Tools convert uncertain, error-prone AI tasks into deterministic operations, serving as that standardized Allen key.
Applying this framework to PhoneBuddySDK’s design, you’ll find it fully demonstrates one practical form of a generative kernel on mobile. Every single layer of the three-part kit corresponds to a concrete implementation entity in the codebase—fitting seamlessly with zero discrepancy.
Core Suites correspond to the underlying execution machinery itself: tool-calling loops, streaming communications, session state management, combined with the restricted capability set enclosed by five boundaries. Individual App developers would find it extremely difficult to build these low-level modules on their own. Cross-platform compatibility, operational stability, and detailed boundary auditing each demand massive, sustained engineering effort. The workload is too heavy for solo efforts.
Guided Knowledge is embedded in system prompts and tool specifications. Sandbox rules, path format requirements, and conditions for stopping execution are instructions that the model reads to learn how to operate in a fresh mobile environment. A code commit on the second day after this open-source project launched focused precisely on slimming down system prompts and splitting specific tool usages into individual tool specs. This action itself is the meticulous maintenance of specifications written specifically for AI—just like writing an onboarding manual for a new employee.
Leveraged Tools are embodied in customized system commands and script engines. One of the model’s most unreliable behaviors is generating system operations commands out of thin air on the fly—where syntactically correct commands with severely off-mark semantics are all too common. By replacing common commands with deterministic function implementations and substituting arbitrary code execution with restricted scripts inside a sandbox, the system pulls the unreliable code generation process back onto a deterministic track.
There’s another, smaller isomorphic example: the VoiceFlowKit project that I maintain. It’s a Swift library for adding real-time voice input to any iOS App. Its Core Suite encompasses microphone data capture, WebSocket data transmission, and a speech transcription pipeline. Guided Knowledge is embodied as an independent skill file written for AI agents working inside someone else’s codebase. Leveraged Tools include test stubs, audio metering utilities, and strictly typed error enums. Without directly touching low-level WebSocket communications, AI can still reliably assemble stable feature integrations. Its README explicitly states: “designed as a generative kernel for AI integrators”.
The harsh platform constraints on mobile actually force this development pattern into a purer form. The essence of a generative kernel on mobile is allowing developers to secure a parameterized trade-off point between the two ends of the spectrum: using the cloud for the brain, local resources for hands, feet, and eyes, and drawing the capability boundaries themselves. On desktop, developers could get away with being lazy by simply assigning a command-line console to the model—if something breaks, just restart it. Mobile platforms offer no off-the-shelf command-line environment, turning the capability mechanism itself into a product that demands careful design and attention. Whether the five boundaries are drawn accurately directly dictates the overall quality of this intelligent kernel. Constraint is also a form of creativity.
Next time you encounter any mobile Agent solution—whether it’s an open-source SDK, an OS-native feature, or a cloud service—ask it five specific questions: Where is the file boundary drawn? What traffic does network egress block by default? Which system interfaces can the script environment access? Can subtasks support external observation and forced termination? How does a failure loop halt automatically? If it gives clear answers, the solution treats capability granting as a genuine product design. If it can’t, the more powerful its claimed capabilities are, the more cautious you should be about the unknown risks introduced. We want an obedient helper, not a bull in a china shop smashing everything in sight.
The lesson mobile brings to the entire Agent industry has long reached beyond phone hardware itself. In the desktop era, the default answer for execution environments was always readily available, so capability granting could easily be hand-waved away. Mobile platform constraints have removed this default option. Every vendor is now forced to answer the exact same serious question: What can your Agent actually touch? The teams that can answer this question with concrete products are the ones delivering the next-generation kernel for the AI era.