What the counter actually needed
An automotive parts counter answers the same question all day: do you have this part, and how many. The answer lives in a stock record that the person at the counter cannot check while a customer is waiting, so it is answered from memory and corrected later.
The requirement was not a dashboard. It was a way to ask that question in the tool the business already uses, and get an answer that is either correct or explicitly declines to guess.
What was built
A stock enquiry agent reached over WhatsApp. There is no application to install and no new device at the counter. A question arrives as an ordinary message; the agent parses it, looks the part up, and replies.
The design rule that governs the whole build is that the agent must never state a stock fact it cannot derive from the authoritative record. Declining to answer and handing off to a person is always a permitted response. A confident wrong answer is not. In a parts business, a wrong count is worse than no count, because a wrong count gets acted on.
Where it has actually got to
The service runs and responds. The business logic has been validated against fixtures — a fixed test set of parts, counts and phrasings — and behaves correctly against them.
It has not been confirmed against live stock data at the counter. Until it has, this deployment is Unproven, and nothing on this site will describe it otherwise. The status register states what would have to happen for that to change: the agent answering live stock questions for a named operator, with a record of that session held.
What another institution can take from it
Two things transfer, regardless of sector.
The first is the channel decision. Meeting people in the tool they already use removes the adoption problem entirely, and adoption is where most institutional deployments fail rather than at the model.
The second is the refusal rule. A narrow agent that declines cleanly is more useful than a broad one that improvises, because the person receiving the answer can tell the difference between a fact and a guess. That rule is worth writing into the specification before any code is written, because it is very difficult to add afterwards.
Last reviewed 4 August 2026 · See the full status register