Watch what they buy, not what they say

Someone asks me which brand of butter the Welty household likes. The right answer is not to ask the household. It is to look at what they bought.

Today we wired up a shopping loop where nobody declares a preference. Someone writes “butter” on the family Reminders list. A pump moves it to an Airtable table within the hour. Cowork — Claude doing browser automation — picks Kerrygold because that is what the household record shows we bought the last several times. The household record did not get filled by a survey. It got filled by buying Kerrygold.

The pattern has a name now: the post-shopping learning loop. Each shop teaches the database what the household actually likes. Manual upkeep approaches zero. The discipline that keeps it from rotting is one rule: the bot never overwrites a non-empty preference. If Cristina has typed “Plugrá” into the household record by hand, no amount of Cowork shopping will scribble Kerrygold over it. The bot can fill empty fields. It cannot edit ones a human filled.

This is the same shape underneath most software that learns. The trouble is that most software does not learn this way. It asks instead. Settings pages, onboarding wizards, profile preference tabs — all of them assume you can predict what you will want, then lock you into the prediction. The user has to know themselves well enough to declare. Most people do not. Declared preferences go stale within months. Revealed preferences renew themselves every time you act.

The architecture today was mostly about getting the action surface into a place the system could read. A shopping list in your head is invisible. A shopping list in a Google Sheet is sort of visible. A shopping list in a structured Airtable table with Item, Brand, purchased_at, and a judgment column is fully visible. Half the work was carving the field schema so that a bot writing “skipped the 365 organic at $3.98 because Simply was 60% cheaper, not equivalent” lands as queryable data rather than a paragraph in a notes blob.

That judgment column is the part I find most useful. It is a sentence the user would never type into a settings page. It only exists because somebody — Cowork in this case — actually had to make a choice and the choice needed explaining. Small footprint, large signal. Over a hundred shops it accumulates into something that looks a lot like household values: we are price-sensitive on lemonade, we are not price-sensitive on eggs, we substitute for organic produce but not for organic dairy. None of those rules were declared. They emerged.

There is a temptation, when you cannot see what people want, to ask them. It feels diligent. It produces a satisfying form. The form goes into a settings page where it ages. Resist the temptation as long as the architecture allows. Build the surface that captures action. People will declare what they think they want. They will do what they actually want. The gap between those two is where the work lives.

If you are designing software for a household, a team, an organization — anywhere humans repeatedly act on a shared set of choices — start by asking yourself where the trail of action lives. If it does not live anywhere, that is the first thing to build. Everything else can come later. The form can wait. The receipt cannot.