essay
Why We Are Building AANI
AANI is my long-running question about what useful AI looks like when reliable internet is not part of the deal.
Most AI products are built for a user with a fast connection, cheap data, a recent phone and a few seconds of patience. I do not always have all four, and neither do most of the people around me.
That gap is why I started AANI.
The question
What should AI look like when internet is not guaranteed?
Not as a fallback screen. As the actual design brief. If a tool only works in perfect conditions, it excludes a lot of the people who would get the most out of it, and it does so quietly, because the failure shows up as a spinner rather than a message.
What that looks like in practice
A few of the cases I keep testing against, because they are the ones I actually watch happen:
- A student with a textbook chapter on their phone who wants it explained, on a data bundle they are rationing. The whole exchange should cost nothing after the first download.
- A trader recording sales by voice at the end of a day, in a market with no usable signal, who needs the record to be there and correct when the phone reconnects.
- A health worker filling a form in a village, where the form has to validate and save locally and sync later without a duplicate.
- Someone on a feature phone with no data at all, asking a question over SMS, where the whole answer has to fit in a couple of messages.
None of those are solved by a better model. They are solved by deciding where the work happens.
What we are exploring
AANI is research more than product right now. The pieces I am working through are local-first workflows, small models running on the device, SMS as a real interface rather than a novelty, offline storage with deferred sync, and hybrid edge and cloud routing.
The small models are the part that changed most recently. Gemma 3 1B, Llama 3.2 1B and 3B, Qwen2.5 at half a billion parameters and Whisper tiny for speech all run on hardware people actually own, once quantised through something like llama.cpp. That was not true two years ago, and it moves the question from whether local is possible to which tasks belong there.
The direction is that capability should degrade in stages instead of collapsing. On a strong connection, use the cloud. On a weak one, answer locally and sync when there is room. With nothing at all, answer from what is already on the device or say plainly that it cannot.
Why the constraint changes the product
Connectivity is not one variable among many. It sets the interface, the cost of each answer, the data flow, what the user can reasonably trust, and where the bar for a good enough response sits. Change it and you are designing a different product, even if the model underneath is the same.
That is the part I keep testing. A model that can answer is not the hard problem anymore. A system that stays useful when the network, the device and the budget are all working against it still is.
Where it goes
AANI does not have a launch date and I am not going to invent one. It is the place where I work out how the rest of what I build should behave when conditions are not ideal, and pieces of it keep ending up in the things I actually ship.
I write the working notes as I go. The most recent one is Offline AI is a product requirement.