Lean LLMs, Heavy Lifting: When Workflows Beat Bigger Models

Seats are not just seats.

For an airline, a seat can be sold as a cheap restricted fare, a flexible economy fare, or not sold at all. A passenger who cannot buy one fare may upgrade, switch flights, or disappear into a competitor’s booking funnel. Multiply that across routes, departure times, fare classes, demand segments, aircraft capacity, and network balance rules, and the innocent phrase “optimize ticket sales” becomes a fairly effective trap for language models.

That is why the most useful part of the paper behind today’s article is not its benchmark table, though the numbers are strong. It is the Singapore Airlines-style revenue management case. The case forces the question that enterprise AI teams should care about: can an LLM turn a messy business problem plus external datasets into a usable optimization model, or does it merely write impressive-looking algebra until someone checks the bill?¹

The paper’s answer is cautiously positive, but only after a design change that sounds unfashionably practical. The authors propose LEAN-LLM-OPT, a three-agent workflow for large-scale optimization auto-formulation. Its core message is simple: bigger models and longer context windows help, but they do not remove the need for structured decomposition and reliable data handling. In other words, stop asking one model to be the analyst, database clerk, operations researcher, and solver engineer at the same time. Even very clever interns need a process.

The airline case reveals the real failure mode

The Singapore Airlines case uses a choice-based revenue management setting built around a generalized Sales-Based Linear Programming formulation. The task is not merely to allocate seats. It must reason over fare types, average prices, customer choice behavior, attraction values, shadow attraction values, demand by origin-destination pair, flight capacity consumption, and, in the network-planning variant, flight-selection constraints.

The paper builds two Air-NRM benchmarks from this setting:

The second task is the more business-revealing one. It asks the system to recommend a subset of flights while also determining fare-class capacity allocations. That means the generated formulation has to connect revenue terms, capacity constraints, binary flight-selection variables, cardinality limits, and flow conservation across airports. Miss one linkage and the model may still look like optimization. It just optimizes the wrong business.

This is where LEAN-LLM-OPT performs best. On Air-NRM-CA, LEAN-LLM-OPT with GPT-4.1 reaches 93.3% modeling accuracy, while the gpt-oss-20B version reaches 86.7%. On Air-NRM-NP, the GPT-4.1 version reaches 92.1%, and the gpt-oss-20B version reaches 82.5%. Gemini 3 Pro remains competitive in the airline setting, but the ablation results are the useful part of the story.

That table is the paper’s best business lesson. The failure is not “the model does not know optimization.” In the ablation discussion, the base GPT-4.1 model can generate some generic non-negativity constraints. That is the easy part. The difficult part is knowing which rows and columns matter, where coefficients belong, and how each dataset feeds into each equation.

Tools-only systems can retrieve flight capacities, passenger counts, ticket prices, and attraction values, but they struggle to place those numbers correctly. Workflow-only systems understand the abstract model better, but cannot reliably extract all necessary parameters. The complete system works because it combines both: a modeling procedure and a data-handling layer.

That is not a small distinction. Many enterprise AI pilots fail by treating “can read files” and “can reason over the business process” as the same capability. They are not. One is access. The other is controlled use.

LEAN-LLM-OPT works like a small modeling office

The system has three agents, but the point is not “multi-agent” theater. The point is role separation.

First, a classification agent identifies the problem type: network revenue management, resource allocation, transportation, facility location, assignment, sales-based linear programming, mixture, or other. This classification is not just a label for a dashboard. It determines what kind of formulation pattern the system should retrieve and how the next agent should reason.

Second, a workflow generation agent retrieves relevant reference examples from Ref-Data and builds a step-by-step workflow. For common problem types, the workflow is type-tailored. For mixture or “other” problems, the system uses a more type-agnostic abstract model plan.

Third, a model generation agent follows the workflow, calls data tools, retrieves relevant rows or columns, and produces the mathematical formulation and optional solver code.

That may sound like a complicated way to prompt an LLM. It is better understood as a lightweight version of how a human OR analyst works. A competent analyst does not stare at a CSV and “be creative.” She first identifies the problem family, recalls similar formulations, locates the relevant parameters, defines variables, writes the objective, adds constraints, checks domains, and only then translates it into solver code.

LEAN-LLM-OPT turns that tacit sequence into an explicit workflow.

The system is strong because it narrows the model’s job

The paper’s central misconception target is worth stating plainly: large context windows do not automatically solve large-scale modeling.

Large-scale optimization problems are hard for LLMs for two different reasons. The first is semantic: the model must understand the business intent and identify the right formulation family. The second is mechanical: it must move the right numbers from external datasets into the right places in the formulation.

Throwing more tokens into the prompt does not make those two problems disappear. In fact, the paper’s Large-Scale-OR analysis shows that many baseline models degrade as input size grows. This matters because the benchmark’s inputs are not toy word problems. The authors construct Large-Scale-OR, a 101-entry benchmark where problem descriptions are paired with external datasets. Half of its instances involve at least 100 variables, and the average token count is far larger than small-scale benchmarks such as NL4OPT, MAMO, and IndustryOR.

The paper also creates Ref-Data, a 96-entry reference dataset. Importantly, the reference examples are much smaller and semantically different from the benchmark instances. That design choice matters because the system is not supposed to memorize answers. It is supposed to use reference problems as modeling guides.

The key mechanism is selective structure:

This is why “workflow beats bigger models” is not a slogan here. It is a mechanism. The workflow reduces the burden on the model precisely where brute-force generation is fragile: planning, retrieval, and coefficient alignment.

The benchmark results support the mechanism, not just the leaderboard

On Large-Scale-OR, the strongest LEAN configuration is LEAN-LLM-OPT with GPT-4.1. It achieves 83.2% exact-match modeling accuracy and 85.1% modeling accuracy by optimal value. The gpt-oss-20B version reaches 77.2% exact match and 80.2% optimal-value accuracy.

The exact-match metric is important. The paper distinguishes between two evaluation modes:

1. Modeling accuracy by optimal value: whether the generated model produces the same optimal value as the ground truth.
2. Exact-match modeling accuracy: whether the formulation itself matches the ground truth, aside from variable naming.

This distinction is not pedantic. An incorrect formulation can sometimes produce the correct optimal value by accident. In real operations, that accident becomes a delayed failure: the formulation may break when demand shifts, capacity changes, or new constraints are added. The paper finds that the two metrics are usually close, so optimal-value accuracy is a reasonable proxy, but the existence of discrepancies is exactly why formulation quality matters.

The comparison with base models is stark:

The most interesting comparison is not LEAN versus a weak model. It is LEAN versus its own base models. GPT-4.1 alone gets 14.9% exact-match accuracy. Wrapped in LEAN-LLM-OPT, it reaches 83.2%. gpt-oss-20B alone gets 25.7%; wrapped in LEAN, it reaches 77.2%.

That is not merely a model improvement. It is a system-design improvement.

The paper also tests a type-agnostic LEAN variant by routing all problems through the abstract workflow rather than using type-tailored workflows. This variant performs worse than full LEAN but still outperforms most competing methods. The likely purpose of this test is robustness: it asks whether the system collapses when it cannot rely on precise problem-type tailoring. It does not. But the drop also shows that type-specific modeling knowledge still matters.

The small-scale results prevent the wrong conclusion

One could misread the paper as saying LEAN-LLM-OPT is only useful for large external-data problems. The small-scale benchmark results complicate that.

On NL4OPT, MAMO Easy, MAMO Complex, and IndustryOR, LEAN-LLM-OPT with GPT-4.1 performs at or near the top. It reaches 94.7% on NL4OPT, 93.5% on MAMO Easy, 71.4% on MAMO Complex, and 65.0% on IndustryOR. The gpt-oss-20B version also improves sharply over its base model.

These results are useful, but they are not the main thesis. They show that the workflow does not harm small-scale formulation and may still help. The stronger claim is about scale: once datasets become external, heterogeneous, and long, ordinary prompting and even strong model capability become unreliable. LEAN’s advantage grows because it changes the task structure.

The paper’s figures on input size and output size help interpret this. LEAN remains comparatively strong as input size increases, while many baselines deteriorate. Performance still drops as the number of output variables grows, which is expected. More variables mean more coefficient placement, more linkage constraints, and more opportunities for subtle errors. The system is not magic; it simply fails later and less often.

That is a useful kind of progress. Boring, measurable, and therefore suspiciously enterprise-ready.

What businesses should infer — and what they should not

The paper directly shows that a structured agentic workflow can substantially improve LLM-based optimization auto-formulation on curated benchmarks and a simulated airline revenue management case. It also shows that tools and workflows are complements, not substitutes.

Cognaptus’ business inference is narrower but important: for many decision-heavy workflows, the valuable AI layer may not be a larger model. It may be a workflow compiler that translates domain practice into repeatable agent steps.

For business leaders, the lesson is not “replace operations researchers.” That is the lazy interpretation, and lazy interpretations usually have excellent slide decks.

The better interpretation is this: organizations may be able to reduce the manual bottleneck around draft formulation, scenario setup, and solver-code generation. Human experts still need to validate the formulation, check assumptions, review data quality, and decide whether the optimization target is actually the right business target.

In practice, a production version would need at least four layers:

1. Problem intake: structured capture of objective, decision scope, data sources, and constraints.
2. Workflow library: reference formulations for recurring business problem families.
3. Tool layer: reliable data extraction, schema inspection, unit handling, and solver integration.
4. Validation layer: formulation checks, feasibility checks, sensitivity analysis, and human approval.

LEAN-LLM-OPT mainly demonstrates the value of layers two and three. It strongly hints at the importance of layer four, but does not fully solve it.

The limits are practical, not cosmetic

The paper focuses mainly on linear programming and mixed-integer linear programming. That is already a large and commercially important world, but it is not all optimization. Nonlinear models, stochastic programs, robust optimization, dynamic programs, simulation-optimization hybrids, and messy real-time control problems add different failure modes.

The datasets also matter. Large-Scale-OR is carefully constructed. Air-NRM is based on simulated datasets from a booking simulator trained with Singapore Airlines’ real sales data. That is much closer to business reality than a toy benchmark, but it is still not the same as a live deployment where data definitions drift, business rules change, and downstream users creatively misunderstand the model. Humans remain undefeated at making clean systems dirty.

The paper’s own conclusion points toward another boundary: the workflow is still enforced largely through semantic instructions. LLM behavior remains probabilistic. A future production system would need stronger guarantees around constraint satisfaction, auditability, and tail-risk control. That probably means combining LLM workflows with formal validation, solver diagnostics, and rule-based guardrails.

So the practical claim should be disciplined:

• The paper shows strong evidence that structured workflows can make LLMs much better at optimization auto-formulation.
• It does not prove that LLMs can autonomously own high-stakes operational decisions.
• It suggests that the next competitive advantage in enterprise AI may come from encoding expert workflows, not merely renting the newest model endpoint.

The quiet lesson: model intelligence needs organizational design

LEAN-LLM-OPT is interesting because it makes LLMs look less like standalone brains and more like employees inside a well-designed office.

One agent classifies the work. Another builds the modeling procedure. A third executes the formulation while using tools to retrieve data. The result is not glamorous. It is, however, closer to how serious analytical work actually gets done.

That should make AI teams slightly uncomfortable. Buying a stronger model is easy. Building a disciplined workflow library is slower. Connecting that library to data tools is annoying. Validating generated formulations is even more annoying. Naturally, those are exactly the parts that matter.

The paper’s airline case makes the point cleanly. The system succeeds not because it “understands airlines” in some mystical way, but because it is guided through the correct sequence: identify the revenue-management structure, retrieve the relevant flight and fare data, place the coefficients into the right equations, enforce capacity and network constraints, and generate solver-ready output.

That is the future of useful enterprise AI: not a bigger brain in a box, but a smaller brain inside a better operating procedure.

Cognaptus: Automate the Present, Incubate the Future.