ORPilot: the AI that reinvents industrial optimization

The Promise of AI Optimization

For decades, operations research (OR) has played a discreet yet essential role in business decisions, such as delivery truck routing, factory production planning, supply chain design, and cargo allocation to carriers. The underlying mathematics are mature, and the available solvers are remarkably efficient. However, the real challenge lies in the human expertise required to translate a business problem into a workable mathematical model.

Large language models (LLMs) have been seen as a potential solution to this problem. Growing research, including series like OptiMUS and OR-LLM, has demonstrated that these advanced models can generate correct solver code for well-specified linear programming (LP) and mixed-integer programming (MIP) problems. The results of these studies were impressive, and the demonstrations convincing.

However, when attempting to apply these tools to real-world problems, limitations quickly become apparent.

The Limits of Current Tools

Almost all LLM tools for OR developed so far share an implicit assumption: the problem description is complete, unambiguous, and provided to the AI in a well-formatted prompt, incorporating all necessary data. This assumption is far from the reality of OR problems.

Take, for example, a supply chain team looking to build an optimization model. The initial problem description is often incomplete and ambiguous. A business analyst might say, "we want to minimize transportation costs," without mentioning that each distribution center has a throughput limit, that certain routes do not exist, or that opening a facility incurs a one-time fixed cost. These omissions are not due to negligence but to assumptions that the analyst considers obvious, making them particularly dangerous. An AI system that begins modeling before these details are settled produces a technically correct but practically erroneous model.

Moreover, the data needed to solve these problems is often too large to be integrated into a single prompt. A supply chain problem could involve hundreds of production sites, distribution centers, customers, and thousands of products over multiple periods. The demand table alone could contain millions of entries. Integrating this into a prompt is impractical. Even if it were possible, flooding the context window with raw data significantly increases the risk of hallucinations.

Additionally, the available data does not always match what the model requires. For instance, the model might need a distance matrix between all pairs of locations, while what is available is a table of GPS coordinates. The model might need aggregated demand by product and period, but what is available is a transaction log with one line per order. Bridging this gap—calculating derived parameters from raw data—is a significant engineering step that existing LLM tools for OR do not handle automatically.

Once a functional model is in place, portability and reproducibility become crucial. If you want to rerun the model on updated data, switch from Gurobi to an open-source solver, or hand off the model to a colleague on a different machine, you have to start from scratch unless the tool produces a durable, solver-independent artifact. Most tools generate solver-specific code and nothing else.

These challenges are not exceptions but standard conditions for any real-world OR deployment. Existing LLM tools for OR have been built for a different world, a textbook world, and show their limitations as soon as they step outside of it.

Introducing ORPilot

ORPilot is an open-source AI agent designed from the ground up for production conditions. To my knowledge, it is the first LLM-based OR tool explicitly designed for the messy, large-scale, data-rich reality of industrial optimization.

Most AI tools for optimization jump straight to writing code as soon as you describe your problem. ORPilot does something different: it first asks questions.

This design decision, which prioritizes understanding over speed, reflects a unique guiding principle: an AI agent should operate in the same way as a qualified human OR consultant.

A good consultant does not walk into a client meeting and start writing a mathematical model on the whiteboard. They ask questions. They listen carefully. They react when something is ambiguous. They ensure that the data is in the right format before modeling begins. Only after all this do they pick up the pen.

The ORPilot pipeline reflects this discipline through five connected steps in sequence.

Step 1: Interview Agent

The interview agent is the entry point. It receives your initial description of the business problem, which may be vague, incomplete, or even contradictory, and engages in a structured dialogue to fill in the gaps. The key design principle is that no modeling begins until the interview is complete.

The agent is tasked with identifying gaps in information in the current description, asking at most one targeted clarification question per turn (to avoid overwhelming you), and finishing once the objective function, decision variables, constraints, and data requirements are all specified unambiguously.

In practice, this means conversations like:

• ORPilot: "Once a facility is opened, does it remain open for all subsequent periods, or can it be closed later?"

• ORPilot: "Does this model handle a single type of product or multiple products?"

• ORPilot: "You mentioned a transportation cost. Is this cost per unit shipped, per shipment regardless of quantity, or something else?"

Before finishing the interview, the agent presents a complete structured summary with the objective function, decision variables, constraints, parameters, indices, and gives you the chance to correct anything before this summary is passed downstream. This serves as protection against the most common failure mode in LLM tools for OR: modeling the wrong problem.

Step 2: Data Collection Agent

This step has no equivalent in most existing LLM tools for OR. It is one of the most significant structural innovations of ORPilot.

Most existing LLM tools for OR assume that data is embedded in the text of the problem, small enough to fit into a prompt. For textbook problems, this works. For real-world problems, it fails in two ways. First, real datasets are too large. For example, a supply chain problem with 500 customers, 500 products, and 12 periods would have 3,000,000 demand entries. Second, embedding data into the prompt increases the risk of hallucination and unnecessarily consumes the context window.

ORPilot's response is to treat the data as separate from the prompt. The data resides in CSV files. The AI accesses it only by writing and executing code. The job of the data collection agent is to determine exactly what these CSV files should look like.

Based on the problem specification from the interview agent, the data collection agent determines:

• What entities (sets) exist in the model

• What attributes (parameters) each entity requires

• The precise schema for each required table: column names, types, semantics

It presents this specification to you and waits for you to provide all the files in the correct format. It validates completeness before proceeding.

Crucially, the agent is flexible: if you do not have a particular piece of data ready for the model (for example, the model needs a distance matrix but you only have GPS coordinates), you tell the agent what you actually have, and it updates the schema accordingly—passing the gap to the next step to be managed.

Step 3: Parameter Calculation Agent

Almost all existing LLM tools for OR assume that the numerical quantities needed for the model appear directly in the data provided by the user. In practice, this is almost never true. Two examples that constantly arise in real OR problems:

• A vehicle routing model needs a pairwise distance matrix. The user has GPS coordinates. Calculating Euclidean or geographical distances is a transformation entirely outside the scope of LP/MIP formulation.

• A multi-period production model needs aggregated demand by period. The user has a transaction log with one line per order. The model parameter is a sum aggregation that must be calculated from the raw data.

The parameter calculation agent fills this gap automatically. It receives the problem specification and the raw CSV files, then:

• Identifies which model parameters cannot be read directly from the raw tables

• Generates a Python script to calculate these derived parameters

• Executes the script in an isolated environment

• Writes the results as additional CSV files, passed to the modeling step

This ensures that by the time the modeling agent sees the data, it is clean, correctly typed, properly indexed, and ready for the model. In our experiments, this step has significantly reduced code generation failures and the number of attempts.

Another common situation where the parameter calculation agent could be useful is in calculating BigM values. In some experiments I conducted on ORPilot, the parameter calculation agent computed a BigM value needed for the constraints linking continuous shipping variables to binary facility opening decisions. This is a derived parameter that would be impractical to ask the user directly.

Step 4: Code Generation Agent

With a complete problem specification, raw data, and derived parameters in hand, the code generation agent produces a complete Python solver script for your chosen backend. ORPilot currently supports five backends: Gurobi, CPLEX, PuLP, Pyomo, and OR-Tools.

The generated code is immediately executed in an isolated environment. If something goes wrong—syntax error, runtime exception, or an infeasible/unbounded solver result—the complete error message and traceback are sent back to the LLM along with the previously generated code. The agent retries, up to a maximum number of attempts configurable by the user.

In practice, the majority of failures are...