While I will defer details of the use-cases for SiteCraft to the blog post dedicated to the subject (Introducing SiteCraft: Prescriptive Location Intelligence for Multi-Location Businesses), I will provide a heavily simplified version here: SiteCraft helps you choose locations for your multi-location business. It gathers data, models the problem, solves the model, and interprets the results.

While there are multiple paths the agent can take, one typical path is that of modeling and solving a Optimal Facility Location problem, OFL for short. This post describes a set of lessons learned in ensuring explainable and dependable output, especially in modeling, and in solving the modeled optimization problem.

Modeling

OFL problems are often described using a Mixed Integer Linear Optimization problem, which consists of a linear objective, and a set of linear constraints, in addition to constraints on a subset of variables to be integer values, hence the "Mixed Integer" part, which will then be passed to a solver to obtain the results.

While modern LLMs demonstrate a great ability in mathematical modeling, they still make preventable mistakes in several areas, including ensuring the model is actually valid.

SiteCraft uses a cycle of modeling and critique agents. The modeling agent, as its name suggests, proposes a mathematical model to solve the problem at hand. The critique agent then makes sure all variables have sufficient descriptions, the proposed model is sound, among many other criteria.

Make Invalid States Unrepresentable

In the early stages of development one problem was plaguing the system's performance: the proposed optimization problem was not actually linear!

This lead to long cycles of the critique agent arguing with the modeling agent to sort the problem out, and occasional failures in the later code generation and solving stages. This is where I found the age-old industry adage "Make Invalid States Unrepresentable" to be really helpful.

While the modeling agent uses prose to describe each of the variables, the justification for their presence, and how they are derived from the underlying data, using a structured output for the normal form of the optimization problem in the agent's output solved this problem completely.

If the agent has to provide a list of used constants, variables, the objective the form of inner products of a vector of constants, and a vector of variables, etc., almost all structural problems with the optimization problem are now unrepresentable.

This has the added bonus of enabling deterministic treatment of some of the solver's quirks, which we will go into shortly.

Instruct the Agent on Strengths and Weaknesses of the Chosen Solver

While it might be tempting to give the agent a large corpus of research on the topic of mathematical modeling, we found it to have little to no effect on the quality of the generated models. On the other hand, instructing the agent on the specifics of the solver worked miracles.

Each solver comes with its own set of strengths and weaknesses. One might do better than others with large duality gaps, one might suffer from a large number of integer constraints, one might even be able to handle positive semi-definite problems!

Know your solvers well, and instruct your agent accordingly. As an example, SiteCraft may decide to avoid a min-max problem by using a binary search over a variable, not because the problem is invalid, but because solvers struggle with such problems.

Now if the problem is described in a structured output, as described in the previous subsection, one can also add a suite of deterministic against such weaknesses. In SiteCraft, this proved to cut the modeling/critique cycle shorter in a statistically significant way.

Code Generation

The agent needs to generate code not only to solve the OFL problem, but also to prepare the data to be fed to the solver. The former turns out to be the easy problem, and the latter the hard one!

Give the Agent Access to a REPL

As it happens, modern LLMs are quite good at generating solver code given a description of an optimization problem. Cleaning the data is another beast though. The data might have missing values, in some cases over the whole area of interest, might have multiple types in a single field, or be simply misrepresented in the documentation API.

This makes a wholesale "generate code, execute" cycle unusably slow and error-prone. We found the way we humans tend to do data-cleanup (e.g. in a Jupyter notebook) a great aid to the AI agents as well. The agent has access to a sandboxed live environment in which it can run short snippets of code until it has molded the data into its desired shape.

Measure Your Data

Variable with too little variation over the area of interest are a mortal enemy of an optimization problem, since they don't provide any signal to discriminate between sites. We found it incredibly useful to give the agent a summary of the data for each variable, including percentage of missing values, the number of distinct values, and the variance, among others.

The agent can decide to move forward, or back to an earlier stage to search for more data, or redo the modeling if the data is lacking in some way.

Lint the Generated Code

This one is solving a speed problem, as the agent was able to generate the correct code given enough time. But using a bespoke linter (mostly based on the generated code's abstract syntax tree) we managed to cut the iterations in half!

We collected the logs of the code generating agents, both in cases that it failed, and cases that it took the agent too many cycles to converge. The logs were then fed into a coding agent (Claude Code in this case) and asked to add rules to our linter to catch those problems early. The coding agent then opened well-scoped and easy to review PRs, since it only introduced new code, and in a very restricted area of the project.

Conclusion

Building an optimization agent that produces dependable, explainable output turned out to be less about making the LLM smarter and more about shaping the space it works in. The most impactful interventions were quite similar in training a student in mathematical modeling: share the knowledge, teach them to use the tools at their disposal, and make sure they can iterate fast.

Another common thread is determinism. Wherever we replaced a long, uncertain cycle of agent reasoning with a hard constraint or a fast deterministic check, the system became not only faster but more reliable. None of these lessons are novel on their own, most are borrowed from how careful human practitioners already work, but they transfer to an AI agent more directly than we expected. As the agents themselves improve, we expect the raw modeling and coding to become the easy part, and the surrounding scaffolding to remain where the real engineering lives.

Interested in SiteCraft or evaluating how your expansion decisions are made today? Reach out to us at datachef.co/contact or connect with us on LinkedIn.

#LocationIntelligence #AIAgents #MixedIntegerProgramming