ShahryarAhmad

05  How an AI feature survives contact with users

The API call is not the hard part.

Getting a model responding takes an afternoon. What decides whether the feature is still working in six months is the list below, and none of it shows up in a demo.

Refusal before answers

The first list to write is what the assistant must not attempt — money, account state it cannot verify, anything where being confidently wrong costs more than being slow. Written after launch, it is written from complaints.

Escalation that keeps context

A user handed to a human should not have to start again. If escalation costs them their history, they stop using the assistant and route around it, and the deflection rate that justified the whole feature quietly decays.

On device or worth the round trip

Latency, privacy and offline behaviour decide where inference belongs, not preference. Some of it has to run on the phone; the rest is a network call that will sometimes fail, and the interface has to be honest about which it is.

Cost per user, not per call

A feature priced at a fraction of a cent per call is priced at a real number per thousand active users per month. Knowing that figure before launch is the difference between a feature and a liability.

What it does when it is wrong

Uncertainty is an outcome, not a wording problem. An answer, a refusal and an admission that it does not know are three different states, and a model that only ever produces the first one is the one users learn to distrust.

App Review, for AI specifically

Generated content, data handling and what a feature discloses before it collects anything are all reviewed, and an AI feature is stopped for reasons most teams meet for the first time on submission. Cheaper to know beforehand.