When Operations Research Meets Agentic AI

Classical operations research (O.R.) models (i.e., mixed-integer linear programs, multi-echelon inventory solvers, and network flow formulations) provide mathematical optimality and strict constraint satisfaction, but they are blind to the unstructured signals that actually drive disruption: supplier emails, port advisories, engineering change orders, and contract rate cards. 

Large language models (LLMs) read those signals fluently, but they fail when asked to allocate inventory or settle invoices directly because they optimize token plausibility rather than feasibility. This article argues for a specific division of labor, in which the language model compiles, the solver decides, and a deterministic guardrail admits, and describes a three-stage closed-loop architecture built on that principle, along with the design lessons that emerged from taking it into production.

The Great Divide: Rigid Solvers vs. Fluent Prompts

For decades, the gold standard in enterprise decision-making has been mathematical optimization. Whether allocating safety stock across regional fulfillment centers, routing omnichannel orders, or auditing non-bill-of-materials (non-BOM) manufacturing expenses, O.R. provides something no conversational AI can guarantee on its own: provable feasibility. When a solver emits a distribution plan, executives know the plan respects dock capacities, supplier lead times, and working-capital budgets.

Yet, in global operations, solvers suffer a persistent vulnerability: the formulation bottleneck.

When disruption strikes – for example, when a contract manufacturer reports a yield drop in a free-text shift log, a carrier issues an unstructured congestion bulletin, or a vendor submits a rate-card variance for expedited rework – the solver cannot read any of it. Analysts spend days reading email, estimating impact parameters in spreadsheets, updating constraint tables, and re-running batch jobs. Throughout that re-planning lag, automated systems continue executing against stale assumptions.

The tempting shortcut is to hand the whole problem to a frontier model: paste in the disruption alert and the inventory table, and ask it to re-optimize. In production, this fails for three structural reasons:

• Language models do not evaluate feasibility regions; they predict plausible token sequences. Asked to re-allocate tens of thousands of SKUs across dozens of nodes under capacity and budget constraints, LLMs routinely violate conservation of inventory, allocating the same physical unit twice, or exceeding throughput ceilings, while producing output that reads authoritatively.
• Without an objective function anchoring the loop, agents overreact. A minor qualitative warning becomes a sweeping quarantine or a panic re-order, amplifying the bullwhip effect the optimization was meant to dampen.
• Approximation is unacceptable in financial settlement. An agent that approximates a rate-card formula instead of executing exact constraint matching changes a controls problem into a leakage problem.

The academic community has already mapped part of this territory. The “OptiGuide” framework demonstrated that LLMs can make optimization accessible. For example, the framework enables a human to ask, “What happens if we switch suppliers?” in plain text and receive an explained answer without exposing proprietary data to the model.¹

That work established the interpretive half of the problem. What remains open is the autonomous half: how a system can ingest unstructured disruption signals and act on them continuously without a human in the formulation loop and without ever admitting an infeasible plan into an ERP.

That requires treating the language model as a compiler rather than a solver.

A Three-Stage Neuro-Symbolic Architecture

The governing constraint on the design is simple: agents never propose quantities. They translate language into mathematics on the way in, and mathematics into language on the way out. Everything between is deterministic.

Figure 1: Neuro-Symbolic Operations Research and Agentic Optimization Closed-Loop Architecture.

Stage 1: The Semantic Constraint Compiler

The pipeline activates whenever an unstructured signal enters the ecosystem, such as when an engineering change order restricts a sub-tier component revision, a carrier issues a weather advisory, or an invoice claims non-BOM overtime rework.

Rather than asking the model what to do, the semantic constraint compiler performs a strictly bounded translation. Unstructured text and PDF rate cards become typed, schema-validated perturbations to a pre-verified model – changes to the constraint matrix, the right-hand side, or the cost vector. Critically, the agent writes no solver code. It emits structured deltas against a formulation that engineers have already reviewed. For example:

• A carrier advisory reporting a 72-hour customs delay at a port hub is parsed into affected lane IDs, matched against master data, and expressed as an update to the stochastic lead-time distribution for those lanes.
• A multi-page supplier contract is parsed into machine-readable piecewise-linear rate tables, enabling automated three-way matching against factory telemetry and authorized work orders.

Anything the compiler cannot map to a known schema entity is subjected to human review rather than guessed. This is the single most important safety property in the design.

Stage 2: Causal Graph Analytics and the Optimization Core

Once the unstructured world has been compiled into verified parameters, control passes to the deterministic core:

• Causal commonality search. Before re-allocating inventory or halting a lane, the engine traverses a directed graph of suppliers, manufacturing lines, and distribution hubs. Multivariate commonality analysis distinguishes an isolated station anomaly from a systemic component excursion, the difference between a false-positive supply hold and a justified one.
• Shadow-priced virtual pooling. Enterprises conventionally protect B2B manufacturing and direct-to-consumer channels by ring-fencing inventory into separate physical silos, which forces each channel to carry its own safety buffer. The alternative is a unified physical pool governed by a mixed-integer linear program paired with a contextual bandit policy that tunes risk-aversion weights. Channel protection becomes a pricing decision rather than a partitioning decision. Shadow prices recovered from the dual solution of the linear relaxation at each re-solve determine how aggressively capacity is reserved for high-priority SLA commitments.

The theoretical justification is classical. The square-root law of inventory pooling holds that consolidating independent stocking points reduces required safety stock substantially; ring-fencing forfeits exactly that benefit. Virtual pooling recovers it without physically relocating stock.

Stage 3: Feasibility and Tail-Risk Guardrail

Before any re-allocation, routing update, or settlement reaches an ERP or warehouse management system, it passes a deterministic admission gate:

• Feasibility and conservation verification. The guardrail confirms flow conservation, dock capacity limits, and budget caps. Where a compiled parameter update renders the model infeasible, the solver extracts the irreducible inconsistent subsystem (IIS), the minimal set of mutually contradictory constraints, and surfaces precisely those to a planner.
• Monte Carlo tail-risk simulation. Proposed allocations are stress-tested across simulated demand and transit-time scenarios. If value-at-risk at the chosen confidence level exceeds the enterprise’s stockout tolerance, autonomous execution is blocked and a decision brief is routed to a human.
• Closed-loop feedback. Realized fulfillment cost, delivery-date accuracy, and planner overrides return as a reward signal, refining the bandit’s risk-aversion weights over time.

Design Lessons from Production

The architecture above is the easy part to describe. The lessons that shaped it are less obvious.

Infeasibility is a communication channel, not an error. The instinct is to treat “infeasible” as a failure state requiring escalation. In practice, the IIS is the most valuable output the system produces. It converts “The AI’s suggestion didn’t work” into “These three constraints cannot simultaneously hold, so which one do you want to relax?” That reframing is what makes planners trust the system rather than route around it.

Schema rejection beats schema tolerance. Early designs let the compiler make a best-effort mapping when a parsed entity was ambiguous. This is precisely where silent corruption enters: a plausible-but-wrong lane ID produces a feasible, optimal, and completely wrong plan, far more dangerous than an infeasible one. Strict rejection with human escalation costs throughput and buys correctness.

Shadow prices are the natural interface between AI and O.R. They are simultaneously a mathematical object the solver produces natively and an economic quantity a planner intuitively understands. Exposing them turned the optimizer from a black box into something operators could argue with, which is when adoption actually happened.

• Guardrails must be deterministic. A second language model reviewing the first model’s output feels like defense in depth, but correlated failure modes make it closer to theater. The admission gate must be code that evaluates constraints, not a model that evaluates plausibility.
• The hard problem is mis-specification, not infeasibility. Stage 3 catches plans that violate constraints. It cannot catch a plan that is optimal for the wrong problem because Stage 1 mis-compiled a parameter. Guarding that boundary, through schema validation, confidence thresholds, and sampled human audit of compiler output, is where the ongoing engineering effort concentrates

Evaluating Your Own Organization

Teams considering this pattern should instrument it before adopting it. The measurements that matter are enumerated in Figure 2. The final row deserves emphasis. A system that is never overridden is either extraordinarily good or not being used for consequential decisions. Distinguishing the two requires looking at decision volume alongside override rate.

The three principles the analytics community should take away from this are:

1. Treat LLMs as constraint compilers, never as constraint solvers. Use them to extract parameters, parse contracts, and translate alerts into mathematical notation. Never let a probabilistic model bypass a deterministic solver when allocating physical assets or financial capital.
2. Replace physical inventory silos with shadow-priced virtual pools. Static ring-fencing traps working capital. Coupling real-time disruption sensing with stochastic optimization lets inventory be shared across channels while SLAs remain mathematically protected.
3. Make your AI firewall deterministic. Runtime safety cannot rest on prompt engineering. Every autonomous recommendation should clear an explicit feasibility check and a tail-risk test before a single transaction touches production systems.

Operations research has spent decades building exactly the machinery this moment requires: feasibility guarantees, duality theory, stochastic modeling, and infeasibility diagnosis. The opportunity is not to replace that machinery with language models; it is to finally give it eyes.

Reference
1. Li, B., K. Mellou, B. Zhang, J. Pathuri, and I. Menache, 2023, “Large Language Models for Supply Chain Optimization,” https://doi.org/10.48550/arXiv.2307.03875.