The most reliable part of the copilot is the part the LLM never touches
Ask a language model to plan a logistics decision and you get the most statistically likely answer, not the cheapest one. So I kept the model out of the math and spent the effort on the boundary between them.
The most reliable part of my agentic supply-chain copilot is the part the LLM never touches.
Why it matters
Operations research is a branch of applied math going back to the 1940s, behind airline scheduling, truck routing, factory scheduling, and supply chain balancing. Some of these problems have a provably best answer. Others are mathematically too hard for that, and the honest goal is the best solution you can certify in the time you have.
Ask a language model to plan one of those decisions and you get neither. You get the most statistically likely answer. One approach returns the cheapest path. The other returns the path that sounds cheap.
For a supply chain manager signing a five-figure logistics contract, the difference is the entire point. Across a quarter, the gap between cheapest and sounds-cheap compounds into the line item that explains why the operating margin missed.
So I kept the language model out of the math. The harder question was how to enforce that line.
How it works
In this copilot the language model is the dispatcher. The math engines are the calculators. The LLM reads the request and picks which calculator to call. It never runs the calculation. The system uses 4 families of math, one calculator per family.
Regime 1. Cheapest routing of goods across a network. Calculator: OR-Tools GLOP.
Regime 2. Scheduling jobs on machines, stops on trucks, and rerouting around a disruption. Calculator: OR-Tools CP-SAT and Routing.
Regime 3. Supplier allocation that stays good even when costs shift in the worst plausible direction. Calculator: CVXPY with CLARABEL.
Regime 4. Inventory placement across a multi-tier supply chain, and tracking how demand swings amplify upstream. Calculator: SciPy SLSQP and FFT.
Two of these solvers return a mathematical proof that the answer is optimal. The rest return the best solution reachable on problems that are provably hard. Knowing which problem is which, and picking the right calculator for it, is most of the job.
Here is what surprised me: the typed contract at that boundary took longer to get right than any of the calculators. Pydantic schemas, 6 FastMCP servers, and a keyword fallback for when the LLM quota runs out.
The boundary is enforced by 124 automated tests and a 98% adversarial-injection threshold in CI, because a boundary you cannot test is not a boundary. My job was to keep the language model from corrupting math that Dantzig and his successors built over the last 75 years.