Why agents on your phone need a different model from chat assistants
When we tell people we’re building “AI agents that live on your phone,” the first response is usually a sensible question: isn’t that just ChatGPT with a different icon? It is not. The two things look adjacent on a product roadmap and turn out to be near-opposites once you start designing them. This post is the version of that conversation we wish we could just hand someone.
There are four axes where chat assistants and phone agents diverge: the interaction shape, the attention budget, the side-effect surface, and the privacy posture. Each of them, taken separately, would be enough to justify a different architecture. Together, they justify a different mental model entirely.
Interaction shape: one conversation vs many silences
A chat assistant is a single continuous session. You open it, you ask, it answers, you reply, the context grows. The model is in your foreground attention from the moment you launch it to the moment you swipe away. Even the “assistant” branding leans on this: it’s the entity you talk to, not the one you let get on with things.
A phone agent is the inverse. Most of its life is silence. The conversation that creates it might last two minutes; the agent it produces might run for months, mostly without surfacing to you at all. The interaction model is closer to “hire, then ignore” than “chat, then keep chatting.” The success metric is fewer notifications, not more. You want to forget it’s there until it has something to tell you.
This sounds like a UI cosmetic difference. It isn’t. It changes what the LLM is for. In a chat assistant, the LLM is the product — every output you see is something the model generated. In a phone agent, the LLM is the compiler. It runs once, during the brief authoring conversation, to turn your description into a small executable agent. The runtime that actually does the work — reading screens, finding elements, tracking prices, classifying emails — doesn’t need an LLM at all. The LLM’s job ends when the agent is born.
Attention budget: scarce, asymmetric, hostile
Chat assistants compete for foreground attention. The bet is that what they return is worth the time you spent reading it. The unit is “minutes of focused use” and the assistant’s job is to make those minutes feel productive.
Phone agents are scored on a different unit: interruptions per week. The phone is the most contested surface in your life. Anything that buzzes more than it earns will be uninstalled. So an agent that fires three notifications a day to tell you nothing happened is worse than no agent at all. An agent that fires one notification a month to flag the one thing that did happen is excellent.
This rewards a specific kind of restraint that doesn’t show up in chat assistants. The agent has to be confident before it talks. It has to know what “boring” looks like, so it can stay silent through it. It has to default to “save for later review” rather than “interrupt the user.” None of these are properties an LLM has out of the box. They’re properties of the scheduler, the threshold logic, and the agent’s own model of how often it’s allowed to interrupt.
Side-effect surface: messaging vs side-effects on the world
A chat assistant’s side-effect surface is the conversation window. It produces text. You read the text. That’s the entire contract.
A phone agent’s side-effect surface is the apps on your device. It taps buttons on Instagram. It marks emails as read. It opens Amazon to look at a price. It maybe — depending on how cautious you’ve configured it — drafts a reply to a message in WhatsApp. Each of those is a real action with real consequences. “Drafted a tweet” is not the same as “posted a tweet.” “Marked unread” is not the same as “archived.”
That asymmetry has two consequences for the design. First, every action has to be reversible or guarded. A phone agent that auto-replies to messages and gets one wrong is genuinely harmful in a way no chat answer ever is. Most agents default to “draft, do not send,” with the human in the loop for the irreversible step. Second, the agent has to know which app surface it’s on and behave like a guest there. The price-watcher agent on Amazon doesn’t go clicking around looking for things to do; it opens the wishlist, reads the prices, closes the app. That discipline is part of what we mean by “agent” — it implies a scope.
Privacy posture: it’s a different threat model
The chat-assistant privacy story is mostly about what you typed in the chat. The data the model processes is the data you fed it. That’s manageable: you can choose not to paste things in.
The phone-agent privacy story is about everything the agent can see. The Android Accessibility Service can read UI trees from any app you give it permission to read. That includes screens you didn’t think about: a banking app that happens to be open behind a workflow, a private message you scrolled past on the way to your wishlist. Even if the agent only acts on the price field, the system saw the rest. Where that data goes matters enormously.
The honest engineering answer is that this can’t be a cloud product without a credible local fallback. The agent should be able to do its job without ever sending screen contents off the device. If you need an LLM for screen understanding, it should be small enough to run locally. If you need transcription, it should be a local speech model. If you need long-term memory, it should be in a local SQLite, not someone’s vector database.
This is what we mean when we say Ukkin is “local-first by design.” It’s not a marketing claim; it’s a design constraint imposed by the threat model. If the agent has to be paranoid about what it sees, the only way to make that workable is to keep what it sees local.
What this means for what we ship
The shape of Ukkin falls out of these four constraints. The authoring surface is conversational because that’s the most natural way to describe a workflow you want to forget about. The agents themselves are small classes that extend RepetitiveTaskAgent and live in a sibling SDK, so the compiled output of a conversation is just code. The scheduler is device-aware because the attention budget is the scarce resource. The Accessibility integration is wrapped in a “guest in the app” discipline. The on-device path — vision, speech, eventually the language model itself — is the privacy posture made concrete.
None of this rules out also having a chat assistant on your phone. It rules out chat assistants being phone agents. They’re two different products with overlapping inputs and very different shapes. The reason we ended up building the second is that the first already exists, repeatedly, and most of what people actually want from “AI on my phone” is the second.
If you’ve been thinking about building something in this space, the most useful piece of advice we can give is: pick which one you’re building first, and let the other one be a separate product. Trying to be both is how you end up with a chat assistant that doesn’t quite do tasks and an agent that doesn’t quite talk to you.