Add a food to your catalog

Your homemade protein bar isn't in the catalog. Or maybe it's a regional brand the system has never seen. You want to log it now and tomorrow without having to type the macros each time.

What the agent needs to hear

Behind your sentence, the agent works backwards to three pieces: the food name, the macros, and the basis — whether the numbers are per 100 g (the catalog default) or per serving (a bar, a scoop, a slice). The order of macros doesn’t matter; the agent reads each one by its unit and label. « 250 kcal, 20 g protein, 25 g carbs, 8 g fat per bar » lands cleanly with all four pieces and a per-bar basis.

Optional pieces — brand, serving size in grams, category — slot in if you provide them. « Optimum Nutrition whey, 24 g protein per 30 g scoop » carries brand, macro, and serving size in one sentence. The agent shows you a card with the food preview and asks you to confirm before saving.

Per 100 g vs per serving

The catalog stores macros per 100 g under the hood, because that’s the universal basis. When you say « per bar » or « per slice », the agent asks for the serving weight in grams so it can compute per-100g values from your per-serving numbers. If you give both (« 250 kcal per bar, the bar is 60 g »), the math is automatic. If you skip the weight, the agent asks once.

When the food is something you only ever eat in fixed servings — protein bars, single-serving meals, supplements with a scoop — saving with both per-serving and per-100g values means future logs default to « one serving » without converting to grams every time. That’s the small win that makes custom foods worth saving over typing macros each meal.

What this catalog entry enables

A saved custom food shows up in your search results next to the catalog foods. From there it flows into everywhere foods live: meal logs (« 1 protein bar » resolves directly), recipes (as an ingredient), diet plans (as a meal item or alternative), saved meals. The macros propagate cleanly across all of those.

Custom foods are private by default — only you see them. If the food is one others would benefit from (a popular regional brand), there’s a path to contribute it to the shared catalog with the barcode and proper sourcing. Most custom foods stay private, and that’s fine.

When the agent gets it wrong

The preview card is the chokepoint. If a macro got typo’d — you said « 25 g carbs » and the agent read « 250 g » — name the field: « carbs is 25, not 250 ». If the basis is wrong (you said per-bar and the agent stored per-100g), call it: « those macros are per bar, not per 100 g ».

If the food name collides with an existing entry (you said « protein bar » and there are three in your catalog already), the agent asks whether to update an existing one or create a new entry. Most of the time you want a new entry; « new one, this is the home-made version » disambiguates and creates it cleanly.

What makes the catalog entry worth keeping

Three things decide whether this food is useful tomorrow: the macros are accurate (a typo in protein content skews every future log of this food), the serving size matches reality (a 60 g bar logged with a 30 g serving doubles the macro impact on every log), and the name is one you’ll recognize when you search (« home-made protein bar » beats « Custom Food 1 » when you’re scrolling). The system reads custom foods the same way as catalog foods — once it’s wrong, every future meal log that includes it is wrong by the same amount. Save once carefully, log many times.