Solver-Ready Formulation Handoff

also known as Declarative Model Handoff, LLM-to-Solver Formulation, Formulate-Then-Solve, 制約条件の登録をLLMに任せる

Have the agent emit a declarative optimisation model — decision variables, objective, hard constraints — in a solver-agnostic representation, and let an exact solver produce the decision with its feasibility or optimality certificate.

Context

Planning problems in logistics, energy dispatch, workforce rostering and production scheduling carry hard constraints — vehicle capacity, generator ramp rates, delivery time windows, conservation of flow — that a schedule either satisfies or does not. An agent handed such a problem in natural language can answer it in two ways: reason its way to a schedule directly, or write the problem down as a formal model and pass that model to an exact solver. Solvers for these problem classes have existed for decades and return provable answers; what has been scarce is the expertise to translate a business situation into the model they consume, which is why many such problems are still solved by hand.

Problem

A schedule produced by sampling carries no proof. Nothing in it tells an operator whether every ramp-rate limit holds, whether the assignment is the cheapest available, or whether the problem was infeasible from the start, and a hard physical constraint admits no partly-satisfied answer — a plan that breaks one is not a slightly worse plan but an unusable one. The reasoning trace that produced the schedule is also the wrong artefact for review: an auditor has to follow prose rather than read constraints. When the input data changes, a broken-down truck or an updated price, the entire run has to be repeated at model-call cost, and the new answer need not be consistent with the previous one.

Forces

Formulating an optimisation problem is the scarce skill, and translating a described situation into variables and constraints is something the model does well, while solving the resulting model exactly is something it does badly.
Direct optimisation by prompting has headroom on problems no formal model captures; the tool-augmented route gives up that headroom in exchange for auditability, and the survey literature frames this as the central trade-off between the two architectures.
An exact solver returns a certificate — an optimality gap, or a proof that no feasible assignment exists — that a sampled plan cannot provide, but it answers exactly the model it was given, so a mis-transcribed constraint is answered confidently and wrongly.
A solver-agnostic representation costs an extra compilation step and the engineering to maintain it, and buys re-solving on changed data with no further model calls.
Natural-language problem statements are ambiguous and incomplete, so a formulation needs systematic validation and iterative repair before a solver is worth running on it.

When to use

The problem has hard constraints that a plan either satisfies or does not, such as capacity, ramp rates, delivery windows or conservation of flow.
An operator or auditor has to see why a plan is acceptable, not only what the plan is.
The same problem is re-solved often on changing data, so re-deciding by prompt each time is expensive and inconsistent between runs.
A mature exact solver already exists for the problem class, and the missing piece is the translation from the described situation into its model.

When not to use

The objective is genuinely fuzzy or contested, and forcing it into a formal objective would discard the part that actually matters.
No tractable formulation exists for the problem class, or instances are large enough that an exact solve does not return inside the decision window.
A rough, fast answer is sufficient and nobody will audit it afterwards.
The decision is one-off, so building and maintaining a representation and its compilers costs more than the decision is worth.

Example

A depot manager types out tomorrow's deliveries: twelve vans, driver shift limits, chilled goods that have to arrive before eleven. The agent does not answer with a route list; it writes the vans, stops and time windows down as a formal model and hands that to a routing solver. The solver returns an assignment and reports it is within two percent of the best possible. When a van breaks down at six the next morning, the same model is re-solved in seconds without asking the model anything.

Diagram

flowchart TD A["Situation described in natural language"] --> B["Agent emits formulation: variables, objective, hard constraints"] B --> C["Solver-agnostic intermediate representation"] C --> D{"Validation: indices, units, bounds, feasibility"} D -- "violated check" --> B D -- "passes" --> E["Deterministic compile to solver backend"] E --> F["Exact solver"] F --> G["Assignment + status: optimal with gap / feasible / infeasible subset"] G --> H["Operator reads plan and certificate"] I["New data"] --> E

Solution

Therefore:

Split the work at the point where guarantees begin. The agent reads the situation and pins down the sets, parameters and data sources, then emits a declarative model: decision variables with their domains, an objective, and the hard constraints, each one traceable to a sentence in the source statement. That model is written in a solver-agnostic intermediate representation rather than in one vendor's API, so it compiles deterministically to Gurobi, CPLEX, PuLP, Pyomo or OR-Tools without another model call. Before any solve, a validation step checks index consistency, units, variable bounds and feasibility on known instances; when a check fails, the specific violation is handed back for repair rather than the whole problem being regenerated. The solver then produces the assignment together with its status — optimal within a stated gap, feasible, or infeasible with an inconsistent subset of constraints named. What reaches the operator is the assignment and that status. The agent's remaining job is to explain the solver's output, reading its numbers rather than recomputing them, and when the data changes tomorrow the same representation is recompiled and re-solved with no model in the loop at all.

What it gives you

The answer arrives with a solver status — proven optimal within a gap, feasible, or infeasible with the conflicting constraints named — which a sampled plan cannot supply.
Hard constraints are enforced by construction inside the solve rather than checked afterwards by a reviewer who may miss one.
Changed data is re-solved deterministically from the existing representation with zero model calls, so two consecutive answers rest on the same model and can be compared.
The reviewable artefact becomes a list of constraints instead of a reasoning trace, which is what an operator or auditor can actually check.
Problems previously left to hand-built spreadsheets reach the exact solvers that were always available, because the formulation step no longer requires an operations-research specialist.

What it costs you

The solver answers the model it was given, so a constraint transcribed wrongly produces a confidently optimal plan whose certificate is about the model rather than about reality.
Only problems that fit the solver's class are served; forcing a genuinely fuzzy or contested objective into a linear one discards the part that mattered, and gives up the headroom the direct-prompting route retains.
Formulation errors are silent without validation — the power-systems work needed systematic validation and iterative repair to reach feasibility at all — so the validator becomes load-bearing infrastructure.
Exact solvers can blow up in runtime as instances grow, so a correct model may still fail to return inside the decision window.
An intermediate representation and its backend compilers are real software to build, test and version, which a single prompt does not need.

What this pattern forbids. The agent must not emit the decision itself; it emits only the formulation, no plan reaches an operator without the solver status and certificate that produced it, and re-solving on changed data must not call the model again.

The smaller patterns that complete this one —

usesStructured Output★★— Constrain the model's output to conform to a JSON Schema (or similar typed shape).

And the patterns that stand alongside it, or against it —

alternative-toCode Execution★★— Let the model emit code, run it in a sandbox, and treat the run as the answer instead of trusting the model to compute in its head.
alternative-toDistributed Constraint Optimization·— A group of agents jointly assigns values to shared variables to minimise (or maximise) a global cost defined by inter-agent constraints, exchanging only the messages needed.
complementsHybrid Symbolic-Neural Routing★— Per query, route between a symbolic path (rule engine, knowledge graph) and a neural path (LLM), using the LLM for interpretation and the symbolic layer for exact constraints.
complementsMRKL Systems (Modular Neuro-Symbolic)★★— Route each request through an LLM dispatcher to specialized symbolic or neural expert modules (calculator, knowledge base, code executor) rather than asking one LLM to do everything; integrate the modules' results for the final response.
complementsSemantic-Layer Query Guardrail★— Route natural-language data questions through a curated semantic layer so the model selects and parameterises vetted metrics and dimensions instead of free-authoring raw SQL against production data.
complementsTool-Output Arithmetic Trust✕— Anti-pattern: the agent compares, ranks, or sums correctly returned tool data in its own head instead of offloading the computation to a deterministic tool, emitting confident wrong aggregates.
complementsFormal-Proof Compliance Gate·— Require every agent-proposed action to ship a machine-checked proof that it satisfies the binding regulatory invariants, and reject deterministically any action whose proof does not check.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance

Source: patterns/solver-ready-formulation-handoff.md on GitHub · commit 240ffcd · view history
Added to catalog: 2026-09-09
Last updated: 2026-09-09
Contribute: open an issue or PR at github.com/agentpatternscatalog/patterns.