A freight brokerage we work with had found a shortcut. Dispatchers were copying load-board postings into a general-purpose chatbot and asking for a quote. It was fast. It was also wrong in ways nobody could see, because the number came back with the same confidence whether the model had understood the lane or hallucinated the fuel surcharge.
This is a common pattern and a revealing one, because the underlying need is legitimate. A posting is messy text: origin, destination, equipment, weight, dates, sometimes a commodity, sometimes a note about a liftgate or a tarp. Turning that into a price involves reading, and models read well. The mistake is letting the thing that reads also decide the number.
What a quote is
A quote is a sum of lines. Linehaul from a rate benchmark for the lane and equipment, a fuel component from a published index, accessorials from a table, a margin from policy. Each line has a source and each source has an owner: the rate benchmarks are updated by the pricing lead, the fuel index monthly, the margin policy by the owner.
When the quote is produced by code, every line is visible, every source is current, and a dispatcher who disagrees can see which line to argue about. When the quote is produced by a model, there are no lines. There is a number and a paragraph of justification that reads like lines but is not computed from anything.
The split that works
The quote desk we built does three things in sequence, and the model is involved in two of them.
Parse. The model extracts the fields from the posting: origin, destination, equipment, weight, pickup and delivery dates, accessorials, commodity. This is what models are for. A regex parser does the same job without a key, less well, and the system falls back to it when the model is unavailable.
Price. A deterministic engine turns the fields into a quote, line by line. Corridor distance comes from a city table and haversine with a map-service fallback. Linehaul comes from the lane benchmark. Fuel comes from the current index. Accessorials come from the table. Margin comes from policy. The engine is code the brokerage can read, covered by tests that run without any network.
Review. The model reads the posting and the finished quote together and looks for anything the parser missed: a note about a residential delivery, a hazmat flag buried in the commodity line. It may propose an adjustment, and the adjustment is capped at a small percentage of the computed price. The cap is enforced by the engine, not by asking the model nicely. The reviewer’s note is shown beside the quote, so the dispatcher sees both the computed number and the reason for any change.
Why the cap matters
The cap is the design. Without it, the review step quietly becomes the pricing step: the model nudges every quote toward what “feels right”, and within a month the engine is decorative. With it, the model can catch the things a parser misses, which is valuable, while the economics of the brokerage remain in the hands of the people who set the benchmarks.
The size of the cap is not a magic number. It was chosen with the brokerage as the largest adjustment a dispatcher would make on their own authority before asking a manager. That is the right way to set it: the model gets the discretion of a junior dispatcher, no more.
What changed
The dispatchers did not stop using a chat interface. They paste the posting into the quote desk exactly as they had pasted it into the chatbot. What they get back is different: a quote with its lines, a reviewer’s note, and a parse they can correct if the model misread the posting. Quotes went from a number with no provenance to a document the pricing lead could audit.
When the benchmarks moved, the pricing lead edited a table. Nobody opened a prompt.
The general rule
Anything that is a function of your business’s numbers should be computed by code you own. The model belongs at the edges: reading unstructured input, drafting unstructured output, and reviewing within a tolerance you set. This is true of quotes, of insurance coverage checks, of lead scores and of anything else where someone will eventually ask “where did that number come from” and need a better answer than “the model said so”.
About the authors. Neugent Consulting designs and builds AI systems for operators. The examples in this piece come from client work; clients are anonymised and details are simplified.
