October 17, 2026 · 6 min read

Batch code traceability for a small manufacturer: software first

By Sahan, co-founder, systems and delivery

Batch code traceability software for a small manufacturer needs to do four things: issue a unique code for every production batch, tie that code to the product and its expiry date, keep an edit history nobody can quietly rewrite, and let you answer “where did this lot go” in minutes. That is a database with a sign-in and a form. It is not an AI problem, and we will say so plainly before we say where an agent might help.

This post is the honest version of a build we run in our own food manufacturing business. Most of it is ordinary software. One small part of it could use an agent, and we have not built that part yet.

Why the 24-hour clock matters

Traceability has moved from good practice to a dated legal requirement in two of the biggest food markets.

In the United States, the FDA’s food traceability rule requires covered firms to assign traceability lot codes and keep key data elements at critical tracking events. Records must be available to the FDA within 24 hours of a request, and in an outbreak or recall the agency can ask for a sortable spreadsheet inside the same window. According to the FDA’s rule page, as read in October 2026, the original compliance date of January 20, 2026 has moved to July 20, 2028, after Congress directed the agency not to enforce earlier. The requirements themselves did not change.

In the European Union, Article 18 of the General Food Law (Regulation 178/2002) sets a “one step back, one step forward” duty: you must be able to say who supplied you and who you supplied, and produce that on request. The Commission’s guidance suggests keeping such records for five years as a baseline, although the regulation itself sets no minimum.

If you export, you may sit under both. If you sell only locally, a retailer or a certification auditor will still ask the same question: show me this lot, forward and back.

What a batch code system actually has to hold

Here is the minimum, in the order a recall would use it.

Record	What it holds	Why a recall needs it
Product list	Every product, pack size and code	Ties a code to what is in the pack
Batch	Code, production date, shelf life, expiry	The unit you recall
Price history	Price and effective date	Keeps the product list honest over time
Edit history	Who changed what, and when	Proves a code was not altered after the fact
Dispatch link	Which orders carried which batch	Answers the forward question

The last row is the one small plants miss. A batch register that stops at production tells you what you made. A recall needs what you shipped, which means the batch has to be linked to the dispatch records.

Why the paperwork keeps mattering

Recalls are not rare events that happen to other people. A peer-reviewed analysis in the journal Foods, published in September 2026, studied 24,761 FDA product recall records from fiscal years 2013 to 2025. Microbiological hazards made up 46.2% of records and allergens 27.1%. Both categories are the kind where the speed of finding the affected lots decides how much product has to be pulled.

The study classifies recalls by hazard, not by how quickly the manufacturer traced the lots, so it does not show that slow tracing caused harm. It does show why “which lots, shipped where” is the question you will be asked.

What we built, step by step

We built a batch coding tool for our own food factory. It is a small internal web app, and these are its jobs.

Hold the product and price list. Staff maintain products with their prices, and every price change is stored with its date.
Issue and record batches. Each production batch gets a code, with the shelf life and expiry date recorded against it.
Keep an edit history. Every change to a product, price or batch is written to an audit trail with who and when.
Back itself up. A scheduled export copies the data to a spreadsheet outside the main database, so a database problem does not take the register with it.

Notice what is missing from that list: an agent. Nothing here decides anything, unlike the jobs running across our agent fleet. A person issues a code, the app records it, and the history is kept.

The mistake we fixed

An early version of the tool used a shared PIN login, with the PINs stored in plain form and no row-level access rules on its tables. We caught it in a review, turned those rules on for every table, and replaced the PIN login with the company’s normal sign-in. The standalone login page was retired and now redirects to the main factory system.

We mention it because small internal tools are where this kind of shortcut survives longest. If a batch register holds your recall evidence, it deserves the same access control as your accounts.

Where an agent adds something, and where it does not

We do not call this system an agent, and we would not sell it as one. Here is the honest split.

Job	Plain software	Agent
Issue a batch code	Yes, a form with a rule	No
Store expiry dates	Yes	No
Keep edit history	Yes	No
Warn that a batch is approaching expiry in stock	Scheduled query	Only to route it to an owner
Spot a batch with no dispatch link after its ship date	Query	Chases the person who owns the gap
Run a mock recall on a schedule and time it	Script	Writes up the result and opens tasks for the slow steps

That last row is the useful one. Certification schemes expect you to test your recall procedure. BRCGS guidance is commonly read as expecting traceability to be demonstrated within about four hours, with a quantity check, though we could only confirm that wording from secondary sources, so check the current standard text before relying on it. A scheduled mock recall that picks a random batch, traces it forward and back, times each step and files the gaps is a good job for an agent: repetitive, checkable and easy to ignore when done by hand. We have not built that for this tool. It is the first thing we would add.

The status of this system, stated plainly: it is built and in use, but it does not yet report runs to our monitoring, and it has no background agent. We are not publishing volumes for it.

What it would cost as a Sprint

If you want a batch register on your own accounts, the AI Workforce Sprint fits: a fixed-scope build of one working app or agent, from $9,500, in 4 to 6 weeks, shipped to your own GitHub, Supabase and Netlify with sign-in, documentation and a recorded handover. Prices are current as of July 2026 on our pricing page.

For a build like this the written scope would name your products, the batch code format, the dispatch link, the access roles and whether the mock recall job is in or out. You own the delivered code, data and documentation. If you are not sure traceability is where to start, the $1,900 operations audit ranks your options first, and the fee is credited against a build if you proceed.

The same dispatch data also feeds export documentation, which is worth designing together.

Start async

If your batch records live in a spreadsheet and your recall plan is “ask the shift lead”, describe the setup at /start. Start async: no call follows. A written reply arrives within one business day, with a fixed price in writing.