Agents do the reading, code does the checking, and a person handles the exceptions. The method behind a real catalogue of 2,000 products, step by step.
Let AI agents do the research and extraction, let code do the matching and checking, and send anything that fails a check to a person. That split is how we built the catalogue behind Tempul Health: more than 2,000 products and 1,700 ingredients, joined by over 10,000 product-to-ingredient links, each one traceable to a source.
This guide is the method, step by step. It applies to any product with a list of parts: food, cosmetics, supplements, chemicals, components. The examples come from Tempul, an Australian health app that scores products from 0 to 100.
Three core tables and a source on every fact. Products, ingredients, and a link table between them that records how much of each ingredient a product contains.
A relational database is the right home for this, because the value is in the links. Tempul runs on Supabase, which is Postgres underneath, so a question like "every product containing this additive" is one query.
Because a model answering from memory will invent an ingredient list that looks right. It has no way to know this year's formula, and it rarely says when it is guessing. On a health app, one invented row can change a score a parent uses to choose baby food.
So the agents are never asked what a product contains. They are asked to find where that is written down, read it, and return what it says along with the link. That one rule is what makes the rest of the pipeline trustworthy.
They look for the primary sources: the label, the brand's own pages, and any published lab report. For each product, an agent searches, opens the pages, and returns structured output: every ingredient with its amount and unit, plus packaging and source, and the URL each value came from.
Ask for a fixed shape, not prose. If the agent returns JSON with the same fields every time, the next step can check it automatically. If it returns a paragraph, a person has to read it, and you have automated nothing. Some models are now built for exactly this: Jev returns decisions rather than text.
With code, not with the model. The same substance arrives under many names: a chemical name on one label, a common name on another, an additive code on a third. Python maps each name to one ingredient record, so a product never ends up with the same ingredient twice under different spellings.
A name that matches nothing is not added straight away. It becomes a new ingredient only once it has its limit, guideline, ban flags and risk level, checked against regulators' own lists such as the FDA's inventory of substances added to food and the EU food additives database. An ingredient the app cannot judge is an ingredient it cannot score.
At the exceptions, and only there. Every row is checked automatically before it goes anywhere near the app. Rows that fail go to a review queue instead of the database.
The checks worth starting with:
This is the part most automation projects skip, and it is the part that decides whether anyone trusts the result. The machine does the repetitive reading. The judgement calls still reach a person, which is the same rule we use for any process worth automating.
In clean batches, with the score calculated by a formula you can explain. Rows that pass every check load into Supabase together. Each category then has its own formula that turns the ingredient data into a score from 0 to 100, and the app shows which penalties a product picked up, not just the number.
Keep the source link next to every value. When someone questions a score, and on a health app they will, the answer is one tap away rather than a search through old spreadsheets.
Tag every product with its market, and give ingredients a name per language. Tempul is launching in South Korea with a catalogue kept separate from the Australian one, because what is on the shelf, and which brands people trust, differs by country. Ingredient records carry Korean names and descriptions next to the English ones, so the same pipeline and the same scoring serve both markets.
Use code for the matching and checking, and use whichever is simpler for running the steps. Tempul's pipeline is Python with AI agents, because name matching and validation are real logic that needs tests. For scheduling runs, sending the review queue to the right person, or triggering a refresh when a brand updates a page, n8n is often the quicker tool. Many pipelines end up using both.
With one category and a small batch. Run fifty products through the whole pipeline, from research to score, before you scale. Look at how many rows reach review and why. That number tells you which check or which source to fix next, and it is far cheaper to learn on fifty products than on five thousand.
If you have a catalogue your team updates by hand today, this is exactly what our AI automation consulting is for. In one session we map your data, pick the sources, and design the pipeline with you.
