What Is an On-Device AI Agent?

A financial assistant is only useful if it can see your finances. All of them, every transaction, every balance, every habit you’d rather not have catalogued. That requirement sits very awkwardly with the standard way AI products are built, which is to send everything you say to a server owned by someone else.

How an on-device AI agent works

Nearly every AI feature you’ve used works the same way. You type something. It goes over the network to a datacentre. A very large model processes it there. The response comes back. Your input sits in that provider’s systems logged, possibly retained, possibly reviewed by humans for quality, and possibly used as training data depending on the terms you agreed to.

For asking about the weather, none of that matters much. For “how much did I spend on rent and what should I move into savings”, the calculus is different. That query is a fact about your life, and answering it well requires access to every other fact about your finances.

An on-device agent inverts the arrangement. The model’s weights are downloaded to your phone once. Your query is processed by your own processor. The answer is produced locally. Nothing about the question or the data it touched crosses the network, because there is no network call to make.

Why most AI runs in the cloud instead

It’s worth understanding why this isn’t already standard, because the reasons are structural rather than accidental.

Capability. Frontier models are enormous. They don’t fit on a phone, and won’t. A model small enough to run locally is dramatically smaller, and on open-ended reasoning it is meaningfully worse.

Cost. Serving a model centrally lets a provider amortise expensive hardware across millions of users. Shipping weights to every device means every device needs to be capable enough, a constraint on who can use the product.

Iteration. A cloud model can be swapped tomorrow. An on-device model requires an app update, and users update slowly.

Data. This is the one nobody puts in the launch post. Usage data is valuable. It reveals what users want, where the model fails, and what to build next and, depending on terms, can be training material. A provider that processes nothing gets none of this.

That last point is the real reason the default is what it is. Cloud inference is not merely more convenient; it is more commercially useful to the company building it.

Why the capability gap matters less here

The obvious objection is that a small local model is simply worse. True, in general. Much less true for this specific job.

A financial assistant is not doing open-ended reasoning about the world. It’s doing a set of narrow, well-specified tasks over highly structured data:

• Classifying a transaction into a category
• Noticing that a recurring charge changed, or that spending in a category is unusual
• Summarising a period in plain language
• Turning “send Sam twenty quid” into a structured transaction for you to approve
• Explaining what a fee or a confirmation actually means

These are pattern-matching and structured-extraction problems over a small, well-typed dataset. They do not need frontier-scale general intelligence, and a well-tuned small model handles them competently. The gap between a 3-billion-parameter local model and a frontier cloud model is enormous for writing an essay and modest for “is this transaction unusual for this user”.

“We never see it” versus “we promise not to look”

The strongest thing about local inference isn’t performance. It’s the shape of the guarantee.

A cloud provider’s privacy promise is a policy: we won’t retain this, we won’t train on it, we won’t sell it. Such promises can be sincere and still fail. Policies change with a new privacy notice. Companies get acquired, and the acquirer’s incentives differ. Data gets breached. Governments compel disclosure. Employees exceed their access.

None of those failure modes require anyone to be lying today. They require only that the data exists somewhere it can be reached.

Local inference makes a structural claim instead: the data was never transmitted, so there is nothing to retain, breach, subpoena or sell. That is a categorically stronger statement, and it is the difference between trusting an intention and trusting an architecture.

It’s the same argument as self-custody, applied to data rather than money. A non-custodial wallet isn’t safer because the provider is more trustworthy; it’s safer because the provider’s trustworthiness stopped being load-bearing.

The same idea, applied to your money

Why “we cannot access your funds” is a fundamentally different promise from “we would never access your funds”.

→

What this makes possible

Once an agent can see everything without that data leaving the device, some things become straightforward that otherwise aren’t.

It can hold complete context, every transaction, not the subset you were willing to upload — because there’s no privacy cost to comprehensiveness.

It can act as a filter on your behalf. If a nearby merchant wants to reach people who buy coffee on weekday mornings, the merchant doesn’t need your transaction history to find out whether you qualify. They can state the criteria; your agent evaluates them locally and decides whether to surface the offer. The targeting happens without the data ever moving and if you accept, you’re the one who chose to.

That inversion is the interesting part, and it’s the subject of who should own payment data. Today, relevance requires surveillance: someone must accumulate your behaviour centrally in order to match you to an offer. If matching runs on your device, relevance and privacy stop being opposed. And if the offer has value, the payment for your attention can flow to you rather than to a platform that harvested you.

Being precise about on-device privacy claims

Because this is an area where marketing outruns engineering, the claims worth making are specific ones:

• The model runs on your device. Inference is local.
• Your transaction data is not transmitted for processing.
• The app still communicates with the blockchain, because it must.
• Local inference does not protect a compromised device. If your phone is owned, so is everything on it.
• Model quality is bounded by what your hardware can run.

At DYNK, the agent is called NKI, and it runs on your phone. It’s in active development rather than shipped, a distinction we try to keep visible, because “will run locally” and “runs locally” are different statements and only one of them is currently true.

What we’re confident about is the direction. An assistant that needs to see everything, built on infrastructure where someone else sees everything too, is a contradiction people will eventually stop accepting. The way out isn’t a better privacy policy. It’s not sending the data.