Making optimization accessible: AI as the translation layer
Making optimization accessible will unlock immense business value, but it requires solving two distinct translation challenges: defining problems and exploring solutions. AI-enabled tools can help serve as the translation layer for both.
Optimization solves billion-dollar problems (routing, scheduling, resource allocation) but remains inaccessible to most organizations. The methods are mature; the translation to business reality isn’t.
Recent supply chain shocks revealed the stakes: a manager choosing suppliers and routing inventory faces real consequences: excess costs, missed deliveries, cascading disruptions. Options include industry software, operations research (OR) consultants, or custom tools – but gaps persist between business thinking, data representation, and solver logic. Decision makers and solver software frame problems differently.
What would it take to make optimization as accessible as analytics to answer questions like: How should we…
… route deliveries to minimize cost while meeting tight time windows?
… schedule providers to match patient demand while controlling overtime?
… allocate budget across marketing channels to maximize ROI?
… design an electrical grid to balance reliability, cost, and emissions targets?
… price goods dynamically to maximize revenue without losing customers?
I’ve already written about the promise of LLMs for result synthesis and data collection. This time, I’ll take a step back to examine optimization approaches and the key points in the workflow where new tools can provide value to make optimization more accessible to businesses. Optimization requires a uniquely tricky intersection of skills and resources, but data and AI are making it more tractable.
Two translation challenges hinder optimized decisions
In my prior work at Optimatics and current role at RelationalAI, I’ve seen the same pattern: high-impact enterprise problems stall at the translation layer – upstream when defining the problem and downstream when exploring solutions.
Assuming the required data are in good shape, the first hurdle is mapping how a business stakeholder thinks about their problem to how the solvers model it. This requires translating goals, requirements, and options to objectives, constraints, and decision variables. Most optimization attempts stall here, replaced by spreadsheet analysis and gut calls.
Back to our supply chain example. The logistics manager needs to go from a question (how can we minimize transportation costs while meeting customer demand given supplier reliability and potential delays?) to an optimization problem with its own method, objectives (minimize cost), decision variables (routes, suppliers, flow), constraints (demand, budget, capacity), and scenarios (demand, delays).
Even a perfect-looking map hits messy reality: a changed budget assumption, unreliable demand signals, a disruptive storm, or insufficient capacity data. The modeler will need to revise it based on business requirements, available data, and initial solutions.
Once defined, solving is iterative, rarely yielding fruit on the first go. Fortunately, solvers like Gurobi and CPLEX are industrial-grade, and libraries like Pyomo and Pymoo make other approaches accessible. Problem scale – having many variables and constraints, or large data volume – can be a barrier, but scalable compute is making that easier.
Fast forward: the manager now has solutions for baseline and high demand scenarios. This one looks easier on the surface. The modeling and data gaps are filled, so just decide. The challenge is that it may require refinement to make sure it is an optimal and feasible solution, meaning going back to the upstream definition. Harder yet if there are many potential alternatives to weigh across objectives.
Even a provably better solution must be translated for stakeholders to act on, otherwise it’s academic. The supply chain manager needs to extract actionable information from the solutions: performance (cost reduction achieved), actions (production and routing plans), trade-offs (what we’re giving up), limits (blockers to more fulfillment), and risks (what might shift).
Both translation challenges share a common remedy in LLMs with structured context. It doesn’t replace optimization methods: it bridges humans and mathematical expressions. We’ll explore how AI-powered tools help translate upstream business inputs to optimization model and downstream solutions to interpretable decision inputs.
Reasoning effort needs depend on the optimization approach
Translation challenges, and the remedies used to address them, depend on the optimization approach, which depends on the nature of the problem: it could be constrained, linear, convex, simulation-based, stochastic, multi-objective, sequential… For simplicity, I’ll broadly classify solver approaches as exact vs. approximate, since that’s where we see the sharpest divergence in reasoning effort, and thus where AI tools help the most.
Imagine trying to find the highest point in San Francisco. With a topographic map, you walk directly to the peak. Without contours – or when fog obscures which point is even higher – you wander uphill, sampling with error bars, settling for ‘probably high enough.’ And if the terrain keeps shifting? You re-evaluate constantly, aiming for high ground despite uncertainty.
Exact methods like linear programs work best when problems are constrained, linear/convex, and tractable because they exploit structure for optimality guarantees (see contour lines above). The exact route front-loads cognitive effort in modeling and validation. You carefully plot the map, note the boundaries, set the trajectory, and run with it. The prize at the end is knowing you made it to the top, at least until the next earthquake or district redrawing.
Approximate methods (metaheuristics) trade guarantees for flexibility when problems are non-convex, simulation-based, or too large or fuzzy to solve exactly. These methods shift effort downstream to exploration and refinement of candidate solutions, working backwards from aspiration or forwards from baseline to constrain feasibility and capture preference. It means jumping between waypoints with a flashlight, going up as much as you can. You build a probabilistic world model, get a feel for the terrain, can reasonably determine you’re high up, but never quite know if you’re at the peak.
Both approaches need models and data but they differ in when you spend cognitive effort. The crossover at ‘Solve’ captures the key tradeoff: exact methods have done most of their work by that point; approximate methods are just getting started. Real workflows are messier – iteration and feedback loops are inevitable – but the directional pattern holds. Total area under the curve matters too, since effort is cumulative.
The approaches are complementary. You may shift from approximate to exact once the map is clear enough: exploration jump starts hill climbing. AI lowers the barrier for both, making previously expert-only methods tractable. Over time I see both incorporated into common product experience, tailored to user needs and problem type. I’m exploring each through separate tools.
AI unlocks defining constrained problems atop an existing model
Exact methods front-load effort in problem definition, where most attempts fail. AI can compress that burden. At RelationalAI, I’m exploring how to make optimization modeling accessible to data and domain experts with AI and templates. RelationalAI’s key benefit is reasoning atop an ontology that maps data to real-world concepts, rules, and relationships (e.g., warehouses fed by suppliers who ship on certain days), all within the Snowflake data platform.
A shared ontology (aka context layer) makes optimization and analytics scalable; it’s a reasoning substrate with compounding value, integrated with the rest of data stack. The optimization workflow is jumpstarted when formulating a problem using its logic with templates, fed by predictive and graph reasoners (e.g., shortest paths or predicted demand), **then **extended with solutions (e.g., production plans per factory). The ontology is a deterministic complement to probabilistic LLMs, grounding suggestions in verified structure rather than plausible guesses. It can be audited, adapted, and reused – no need to draw the map fresh each time.
Here’s how this looks in practice. The supply chain team’s data analyst has connected and modeled their data in RelationalAI. Now they need to frame an optimization problem – defining an LP/MILP, mapping inputs to constraints and objectives, generating solver-ready Python code. Using the tool, they:
[1] Integrate model: Ground the formulation in an ontology defined on data: the problem lives in concepts, relationships, and properties that can be used in its expressions.
[2] Select problem: Assess whether their question is answerable: do the model and data support it, and is there a clear decision with actionable output?
At each step, the LLM suggests formulations grounded in the ontology: variable types, flagging missing constraints, generating auditable, solver-ready code.
[3] Define variables: Map natural language to typed variables on appropriate concepts/entities, extending the model where needed. Variables correspond to real world measurable indicators and levers, then feed into constraints and objectives.
[4] Define constraints: Translate requirements into mathematical expressions that are guardrails for the solver, defining the solution space boundaries.
[5] Define objective: Convert measurable goals into expressions over variables and attributes.
[6] Validate formulation: Surface misalignment between user intent and encoded model – unused variables, unstated goals, structural gaps – with actionable fixes directly applied to the model, saving time before the solver even runs.
[7] Solve the problem: Use integrated solver to produce candidate solutions for production and routing plans, then, once satisfied, using them to inform their decision, sharing them, and saving them and extending the model.
What might take a week of back-and-forth with the data and OR teams – or a dead end without them – compresses to an afternoon of iteration.
This was a linear approach yielding a single solution. But many real decisions involve conflicting objectives and multiple scenarios – what happens when you need to navigate trade-offs and uncertainty?
AI unlocks multi-objective, multi-scenario solution exploration
Approximate methods shift effort downstream: exploring and refining candidates rather than proving optimality. AI can guide that exploration. In the Decision Assistant, I’m researching how to make solution exploration accessible: navigating multi-objective, multi-scenario search spaces using evolutionary algorithms.
The goal: complement business users’ domain knowledge with technical skills via AI agents while preserving their judgment. I’ve baked best practices like Pareto frontier exploration heuristics into the prompt logic to help interpreting trade-offs across alternatives, along with tools for the agent to access problem data and run optimizations. Context compounds as users curate solutions that reflect their preferences.
Traditional optimization algorithms use a single objective – often minimizing cost deterministically. But most impactful decisions involve conflicting goals amid uncertainty. Effective optimization tools help decision makers balance different objectives and scenarios.
Returning to the supply chain example: the manager needs to balance transport cost against demand fulfillment and delay risk. Squeezing savings isn’t worth a disruption that offsets the gains. Their data team models a peak demand scenario to stress-test resilience.
[1] Understand solutions: Review option/strategy selection and objective performance patterns across scenarios.
[2] Navigate trade-offs: identify primary trade-offs along the Pareto frontier: a map of optimal alternatives that needs to be filtered for real-world preference and feasibility.
[3] Refine and re-optimize Problem: tighten the formulation to filter unrealistic results, or relax it to encourage diversity
[4] Select and compare solutions: curate solutions close to target that are candidates to examine further, guiding user to think at the margins.
[5] Receive a tailored recommendation: based on user preferences, informed by optimization and AI guidance, but ultimately depends on human judgment and accountability.
Instead of manually comparing a handful of alternatives, the manager sifted through dozens of Pareto-optimal solutions in minutes. The outcome: a new plan, validation of existing approaches, or at minimum clearer direction – distilled from an overwhelming solution space.
Unlocks converge: lower barriers, increase business impact
Imagine if organizations could make measurably better decisions across logistics, healthcare, and resource allocation – without waiting on stretched data, engineering, and OR teams. Self-serve analytics evolved from Excel to Tableau to LLM-powered tools handling unstructured data. It’s time to extend that accessibility to prescriptive reasoning – not just what happened, but what should we do – to directly inform strategic decisions.
The timing is right. A few years ago, this wasn’t possible – LLMs couldn’t reliably ground outputs in structured data or maintain multi-step consistency. Today’s models can take an ontology and user inputs, then produce valid formulations or synthesize insights across many alternatives. Four unlocks have converged: LLMs that reliably reason over structured context, platforms fuel them with data and logic, integrated mature solvers, and web tooling to deliver solutions.
AI-enabled tools won’t replace experts – they’ll extend their reach. Experts move up the stack into architecture roles, applying uniquely human skills: agency, judgment, coordination. Most organizations lack OR teams, and even those that have them face bandwidth limits. Many wouldn’t know to apply optimization until they’re aware and able. These tools still require data teams to model data, domain experts for input, and OR practitioners for guidance. But it’s an incremental step toward self-serve problem solving.
The two demos illustrated:
Upstream: Assisted modeling translates business inputs into structured problems
Downstream: Guided exploration navigates and refines solutions
Both apply across approaches – the difference is emphasis. While approximate methods still require problem setup, assisted formulation matters most when precision is critical. Solution exploration matters most when preferences and constraints are ambiguous, although exact problems still benefit from it. And they can sequence: exploring trade-offs first clarifies what matters or is possible, informing tighter realistic formulation. The supply chain manager might use the Decision Assistant to discover lead time matters more than expected, then encode that as a hard constraint in a RelationalAI model.
If your business faces complex optimization challenges, I’m looking for design partners to validate these workflows. And if you’re building at the intersection of AI and OR, I’m seeking collaborators. Please reach out.