Inspiration
The RudCo brief described a job we could picture exactly: a quoting specialist reading a messy email, working out that "304 SS sheet 16ga 4x8" and "Stainless 304, 0.060 in, 48 x 96" are the same sheet, checking stock, pricing it, and checking the buyer's certification rules, line after line, while a competitor answers the same request. In distribution the first credible quote usually wins.
The obvious build is to hand the RFQ to a model and ask for a quote. That is also the dangerous one, because a tool that confidently fills in blanks makes its mistakes invisible. We wanted the opposite: an agent that is fast on the routine lines and honest about the rest.
What it does
It turns a messy RFQ (an email thread, a PDF or a spreadsheet) into a reviewable draft quote.
- Reads every line into a specification, keeping the buyer's exact words behind each value.
- Recognises the same item written different ways, converting units, fractions and gauge (which depends on the material) into one standard form.
- Matches to the supplier catalog, by specification or by the customer's own part number.
- Checks stock, prices against a market benchmark, and checks compliance: mill test reports, DFARS on country of melt, specification certifications.
- Answers every line with a status. Clear lines are quoted. Ambiguous ones are priced as labeled alternates with one question. Lines that can't be supplied are a no bid with the reason. Lines with an internal concern, such as a price under the margin floor, are held for the specialist and never shown to the buyer.
- Produces the deliverables: a buyer-facing quote, one email with the open questions, and an internal summary.
A specialist reviews the draft on one screen, where hovering any field highlights the words it was read from, and approves it. Nothing is sent automatically.
How we built it
The core idea is a split: the AI reads and writes language, and rules make every decision. A model splits the RFQ into lines, reads each line into fields, screens for manipulation and words the buyer questions. Unit conversion, matching, pricing, compliance verdicts and line status are plain Python. No model output can set a price or a status.
- Pipeline. Twelve stages, from stripping forwarded email history to a final verification pass. Each stage adds "issues" to a line, tagged as buyer-facing or internal, and one ordered rule table turns the issue list into a status.
- Models through NicrronNinoo. All model access goes through its gateway: Claude Sonnet 5 reads the RFQ, Claude Haiku 4.5 screens for manipulation and words the questions. A second model from a different lab can read every line independently, and disagreement holds the line for review.
- Observability with Block Convey PRISM. Every run is recorded as one trace: each stage, each line and every model call.
- Stack. Python, FastAPI and pydantic. The review screen, the supplier catalog view and the buyer quote are each a single self-contained page with no build step.
- Process. We wrote the product spec first, split it into nineteen task files with explicit data contracts, and built the stages in parallel against those contracts. About 330 tests run with no network, replaying recorded model responses, including a labeled set of 29 RFQ lines.
All business data (catalog, stock, costs, benchmarks, customer part numbers) is synthetic and labeled as such.
Challenges we ran into
- The model would not hold still. The reading model rejects a fixed sampling temperature through the gateway, so a first read can vary. On one live run it listed two line-level standards as requirements for the whole RFQ, and six lines came back as no bid. We added a rule that a requirement only counts as RFQ-wide if its wording appears outside the item lines, and a local response cache so the same RFQ always gives the same quote.
- Stages that passed alone disagreed together. Five stages were built in parallel. Wiring them up showed that the track's second example string never names a form, that "CRS" on bar stock was being treated as a finish mismatch, and that a default we had assumed ourselves was being held against the catalog item.
- Getting the metals right. Dual-certified 304/304L fills a plain 304 request without a question, but must never fill 304H. DFARS turns on where the metal was melted, not where it was made. "Domestic" alone is ambiguous and has to be asked.
- Never guessing without stalling. Asking about everything makes zero mistakes and is useless. Pricing the reasonable options and asking one question was the answer, but it meant every assumption had to be named and shown.
- Keeping internal data internal. Cost and margin sit right next to the price. We built buyer documents from a separate view that has no fields for them, then added a leak check that searches the finished quote and email before approval is allowed.
Accomplishments that we're proud of
- The two example strings from the track brief resolve to the same catalog item, with every assumption stated on the quote.
- A PDF with a hidden instruction to quote every line at one cent is caught, shown to the specialist, and produces exactly the same quote as a clean copy of that PDF.
- Every value on screen can be followed back to the buyer's words, and a value whose quoted source is not in the RFQ is thrown away.
- A sample email thread becomes a draft in about 11 seconds, and a PDF in about 31.
- It says no well: a no bid names the requirement and the fact that failed it, and a held line never reaches the buyer.
What we learned
- Deciding what the model is not allowed to do was the most useful design decision we made. Once prices and statuses came only from rules, most of the trust problems became testable.
- "Never guess" needs a precise list of what counts as a guess. The agent's own headline example needed three assumptions.
- Integration tests on realistic lines found more than unit tests did, and a labeled set of real-looking requests was worth building early.
- Model output varies even when you would like it not to, so the code around it has to check what it is handed.
- Writing the contracts between stages before the stages is what made building them in parallel work.
What's next for RFQ-to-Quote Agent
- Publish accuracy on the labeled set: wrong quotes, correct routing and unnecessary questions.
- Attach PRISM's prompt-injection guardrail, an evaluator and its Knowledge Base to the recorded runs.
- Let the specialist edit a line, with the reason recorded.
- Read a buyer's reply and re-quote only the affected lines.
- Price every quantity break, and add alloy surcharges and cutting charges.
- Learn customer part numbers from confirmed answers.
Built With
- claude
Log in or sign up for Devpost to join the conversation.