Auction intake agent
Turns a receiving clerk's data entry into a written, priced, and bundled auction lot.
- ML engineer, two on the project
- 2025
- archived
- Python, FastAPI, OpenAI GPT, LangChain
- GoPrime Systems, production auction platform
Built for an employer and since retired, so there is nothing to open. This is written from memory rather than from source, and it is deliberately thinner on implementation detail than the rest of these.
When a pallet of items arrives at an auction house, someone has to handle each item by hand: work out what it is, write a title and description, decide what it is worth, and decide which other items it should be sold with.
That is slow, and most of it is the same judgement repeated. The pipeline started where the physical work ended. A clerk recorded what had arrived, and everything after that ran automatically.
The chain
A language model wrote the title and description from the recorded attributes and produced a first-pass price. The item then went to the trained pricing model for the actual valuation, and then to a bundling step that grouped it with similar items into a lot. LangChain held the sequence together over a tool server that exposed each capability as a callable tool.
Bundling was the point of the rest. A low-value item does not cover the handling cost of its own listing, so those items have to be grouped, and grouping them sensibly needs a reliable value for each one first.
Two kinds of pricing
Both the language model and the trained model could produce a price.
The language model gives a plausible number for anything, and it has no way of signalling when it is guessing. The trained model gives a number fitted to what this auction house’s items actually sold for, and it can tell a familiar category from one it has barely seen.
So the generated price was a first pass only, and the trained model produced the number that was used. That model is still in production. The agent around it is not.
Why it was dropped
The client stopped using it, first temporarily and then for good. Nothing broke. The team wanted manual control of intake and did not want those decisions made for them.
The pipeline took decisions that experienced staff had been making and moved them into a process they could not see into or easily override. The individual outputs were fine. The arrangement asked staff to accept a result rather than letting them reach their own faster.
What I would build instead
The same components, but as drafts rather than decisions.
A receiving screen that opens pre-filled with a generated title and description, a suggested price with the model’s confidence next to it, and a proposed lot to add the item to. Every field editable, nothing saved until a person saves it. That removes the typing and the recall, which is where the time goes, and leaves the decisions with the staff.
It would also record every correction a person made, which is both training data for the next version and a measure of how accurate the outputs actually were.
The lesson I took from it is narrow: the pricing model is still running because it never made the decision. It returns a number and a confidence, and someone else decides.