Order intake agent for a wholesale back office
Orders arrive as email, PDF and photographs of paper. An agent reads them; a person approves them.
- Area
- AI agents and process automation
- Written
- 2026
- Built with
- Python
- Claude API
- Queue workers
- PostgreSQL
- React
Inside this project
The problem
A wholesaler receives orders in every format a customer feels like using: a PDF attachment, a photographed order pad, a message that says “same as last time but double the 400ml”. Someone reads each one and re-types it into the ERP. It is slow, it is the least popular job in the building, and the typing mistakes reach the warehouse.
Full automation is the wrong target. The right target is: the agent prepares the order, a person confirms it in seconds instead of minutes.
How we build it
1. Intake, not chat
A mailbox and an upload endpoint feed a queue. Nothing runs on a live conversation; every document becomes a job with an id, so a failure can be retried and a result can be explained.
2. Extraction against your own catalogue
The model returns a structured draft order — customer, lines, quantities, requested date — and every line is matched against the real product catalogue with a confidence score. Unmatched lines stay unmatched. The agent is not allowed to invent a SKU that resolves cleanly.
3. A review queue built for speed
The reviewer sees the source document on the left and the draft order on the right, with low-confidence fields highlighted and focused first. Keyboard only: tab, correct, approve. Every correction is stored as a labelled example.
4. Evaluation, so changes are measurable
A held-back set of real documents with known-correct outputs, run on every prompt or model change. Extraction accuracy per field is a number in CI, not an impression formed in a demo.
What you would get
- The intake pipeline and document store
- A typed extraction schema tied to your catalogue
- The review queue, with an audit trail per order
- An evaluation suite and a report you can read before deploying a change
Where it gets hard
The 5% of documents that are genuinely ambiguous will eat the project if you let them; they belong in a queue for a human, not in a cleverer prompt. Model updates shift behaviour, so the evaluation suite is the deliverable that keeps the rest honest. And the ERP write is the step that needs the most care — idempotent, reversible, and never the same transaction as the extraction.
Typical architecture