An agent is only as good as its environment

The simplest way to describe our approach is that we spend our effort on the environments that we work in and that the agent works in, rather than on the agent itself. Three ideas run through everything below.

The first is that plain text is ready for agents. Our notes, code, data and manuscripts live in org-mode and Markdown files that an agent can read, search and edit with the same tools it uses on source code. Nothing has to be exported or scraped first.

The second is that abilities should be installable. When an agent needs to know how to set up a VASP calculation or diagnose a stalled interior point solve, that knowledge should not live in a prompt someone pasted once. It should ship as a skill or an MCP server, versioned alongside the code it describes, and be installable with one command.

The third, and the most important, is that software should report its work. Agents are fluent, but fluency is not correctness. The tools we build for agents return structured results, validate their input, raise typed errors instead of returning a plausible wrong answer, and are tested against references we trust. That gives us something to check the agent’s claims against.

The diagram shows how the pieces fit together. You set the goals and check the results. The agent does the work through abilities that knowhow installs, using four groups of tools. Underneath is plain text, and around all of it are checks the agent cannot talk its way past. The rest of the post follows the diagram from top to bottom.

The workbench: scimax for VS Code

scimax for VS Code is where the work happens. It brings the scimax environment I built in Emacs to VS Code, and it is one plain-text environment for the whole research cycle. I think in it, with a journal, notes, an agenda, and a searchable database of every org file I have. I compute in it, with runnable Python and Jupyter code blocks inside the document. I write in it, with org-ref citations, BibTeX tools and manuscript publishing for journal submission. I publish from it, and I present from it, using Marp decks with a pen, a laser pointer, a timer and live Python.

Because all of this is plain text, an agent can work with it as easily as I can. A TODO is just a headline in an org file, and scimax gathers those headlines into an agenda. Claude can read that agenda and update it too.

The agent-facing part of scimax is a command-line tool and four skills. The scimax CLI covers the agenda, search, the org database, the journal, tasks and projects, citation checking, export, tangling, publishing and slide builds. scimax skill install adds skills that teach an agent how to use it, so it can act as an executive assistant over my notes: a morning briefing, triaging tasks, finding what is blocked, or working out the critical path through a project. Sites built with scimax publish can include an “Ask” chat that finds the relevant sections and writes an answer with citations, using a language model that runs in the reader’s browser, so there is no server to maintain. This site has one. scimax for VS Code has had 838 commits since January 2026, about 72% of them co-authored with AI.

Giving agents abilities: knowhow

The skills that come with scimax are one example of a broader pattern, and knowhow is how we manage it. knowhow is a package manager for agent capabilities. uvx knowhow add owner/repo --skill name installs skills, slash commands, subagents, hooks and MCP servers from any git repository. It works with Claude Code, Codex, OpenCode, Gemini, Cursor and Copilot, and it records what it installed in a lock file so a project’s agent setup can be reproduced. knowhow replaces an earlier tool of ours called skillz.

knowhow also carries a library of our own: 44 skills for scientific, laboratory and programming work (ASE, VASP, pymatgen, Opentrons robots, design of experiments, electronic lab notebooks and scientific review, among others), along with subagents, commands and hooks. Some of the hooks are guardrails rather than abilities. One keeps an automatic lab-notebook record of what the agent did, and another keeps it from writing secrets into files.

The most useful thing about knowhow may be the convention it set. Every package in the rest of this post ships its own skill in skills/<name>/SKILL.md, next to the code it describes. The instructions change when the code changes, and knowhow add can install any of them.

Knowing what we know: litdb and crucible

Research starts with the literature, and agents are notorious for inventing it. Our answer is to give the agent a library that we curate, so it searches real papers instead of what it half-remembers.

litdb is a local database of the papers I care about, with natural-language search. Its MCP server is read-only by design. An agent can run semantic and full-text searches, find papers similar to one it already has, pull new work from OpenAlex, and return citations and BibTeX entries that point to real records. It can even generate the collaborator list an NSF proposal requires, which is the kind of tedious, checkable task that suits an agent well.

crucible works one level up. An LLM distills papers, notebooks and data into an interlinked org-mode wiki, one article per concept, with an SQLite graph of the links behind it. Ingesting happens in two steps: the agent first proposes which articles to write or update, then writes them. Once the wiki exists, an agent can use the crucible CLI to search it, follow backlinks, find related articles, and look for gaps such as orphan articles and sources that have not been distilled yet. crucible publish turns the wiki into a website using scimax.

These tools are not wired together in code, but they make one workflow. litdb finds the papers, crucible distills them into concepts, and scimax is where I write with them and publish the result. org-ref citation keys run through all three, so a claim in a draft can be traced back to a paper in the database.

Computing with agents: fairchem-mcp and discopt-calphad

Most atomistic simulation workflows were designed for people. You write a script, submit it, wait, and read the output. When an agent drives that workflow, it does the same thing in a loop: write a script, run it, wait, read a log file, and guess what went wrong. Every step reloads the model, and the agent finds out that a calculation went badly only after it is over. We wanted computation that an agent could work with interactively, and results that carry their own evidence of correctness.

uvx knowhow add jkitchin/fairchem-mcp --skill fairchem-mcp --mcp fairchem

Solvers that explain themselves

Since December 2025 we have started 15 public repositories in differentiable programming and optimization. Together they hold about 1.8 million lines of source and tests, roughly 1.1 million in Python and 0.66 million in Rust, and they have had about 63,000 downloads from PyPI in the last 180 days. Projects like these usually take a team years. The map above, from an earlier post, shows how they relate.

Optimization turns out to be a good domain for AI-assisted development because the answers can be checked. A reported optimum either satisfies the optimality conditions and matches the reference solution, or it does not, and there are large public benchmark sets that say what the right answer is. The same property makes these solvers good tools for agents to use, as long as the solvers explain what they did. That was a design goal from the start.

difflow is a JAX framework for differentiable chemical process flowsheets, for simulation, optimization and technoeconomic analysis. Its MCP server lets an agent build a flowsheet one step at a time: choose the species, add units, connect streams and set feeds, with undo and redo when it makes a mistake. Then it can solve the flowsheet, run sensitivity analyses and sweeps, optimize it, propagate uncertainty, and estimate costs. When a flowsheet does not converge, which is the normal state of a new flowsheet, the diagnosis tools return structured findings and suggested remedies rather than a stack trace, and converge tries the remedies in turn. Each tool is labeled as reading, editing or executing code, and one server configuration removes arbitrary Python execution entirely, for when you want the agent to stay inside the modeling tools. difflow can use pounce and discopt as its solvers.

pounce is a family of interior point solvers written in Rust. It began as a port of Ipopt and now covers nonlinear, conic and quadratic programs. Every solve writes a JSON solve report, so an agent reads structured data instead of parsing an iteration log. The pounce-studio MCP server has about 30 tools built on those reports. Before a solve, an agent can analyze the problem and check the starting point. After a solve, it can diagnose the result, find where progress stalled, look at the convergence trace and the restoration phases, compare two runs, and verify the solution independently. If that is not enough, it can step through a solve in a live debugger. pounce also includes commands for adversarial testing and for reviewing sensitivity results.

discopt is a modeling language and solver for mixed-integer nonlinear programs, and it has more agent-facing features than anything else we have built. It ships 17 expert subagents (for MINLP solving, convexity detection, Ipopt, benchmarking and more) and commands for each stage of modeling: formulating, diagnosing, debugging, reformulating, explaining a model, converting it between formats, and reporting on benchmarks. It also has a tool-call interface for building models from a natural-language description. The agent creates variables and adds constraints and logical conditions through tool calls, and the expressions it writes go through a safe parser instead of being executed as code. When a model is infeasible or a solve goes wrong, discopt produces reports on infeasibility, convexity and provenance that an agent can act on.

Around discopt is a growing set of plugins that bring the same approach to particular domains. Each one checks its input against a schema, solves the problem, and reports the result, through a skill or an MCP server. discopt-mkm does microkinetic modeling for catalysis, including degree of rate control and limiting potentials. discopt-grid does power systems optimization, and it was built largely by an autonomous agent loop working from a written specification and implementation plan. discopt-doe adds design of experiments, with agents for estimability and identifiability analysis. discopt-flowsheet raises typed errors instead of returning silently wrong answers. discopt-course is an optimization course in which Claude Code is the teaching assistant, grading against rubrics. discopt-calphad, covered in the computing section, is one more plugin.

Where this is going

The direction is agents that run the whole loop, from literature to computation to experiment to paper, with people setting the goals and checking the results. The recent roadmap for AI in heterogeneous catalysis describes that future for one field (Xin et al., 2026). The software here is our attempt to build the environment it needs.

If I had to compress the approach into advice for students, it would be four things. Own the verification: you are responsible for every number, line of code and citation, so learn enough of the fundamentals to know when an answer is wrong. Write things down in plain text, where an agent can read them. Specify, then delegate: the skill that matters now is stating a problem precisely, with tests or checks that define when it is done. And be ambitious, and disclose. Attempt projects that were out of reach, and take responsibility for what you generate.

AI does not reduce the need for expertise. It makes judgment more valuable.

All of the software is on our software page and at github.com/jkitchin.

Why global optimization of the surrogate matters

The usual way to optimize a neural network or a smooth tree is gradient-based: start somewhere, follow the gradient, restart a few times. That works when the surrogate is nearly convex. When the surrogate has several basins, which is common for exactly the response surfaces we care about (selectivity versus temperature and pressure, cost versus a handful of design variables) you have little control over which one you find. The jax-difftree docs say it plainly: inverse design over a soft tree is local, and multistart is the practical fallback.

A MIP solver works differently. It bounds the objective over regions of the input space and discards regions that cannot contain the optimum. When it finishes, the optimality gap is zero (or a tolerance you chose), and that is a statement about the whole box, not about the neighborhood of a starting point. For smooth networks you can get the same guarantee from deterministic global MINLP solvers (Schweidtmann and Mitsos 2019), but for piecewise-linear models the problem is a MILP, and MILP solvers are fast, mature and free (HiGHS (Huangfu and Hall 2018) solves every MILP in this post).

There is a second reason that matters just as much in practice. A surrogate embedded as constraints composes with everything else. You can put two unit-operation surrogates in one flowsheet, add a budget constraint, choose between discrete equipment options, and still get a global optimum of the combined problem. A predict function cannot do that.

What “MIP-representable” means

The building block is the ReLU, . If you know bounds with , one binary variable encodes it exactly:

When the constraints force , and when they force . This is the big-M formulation, and it has been used for trained ReLU networks for some time (Fischetti and Jo 2018; Tjeng et al. 2019; Grimstad and Andersson 2019). Stronger formulations exist (Anderson et al. 2020), and Vielma (2015) is a good general reference. The same idea covers hinge terms , absolute values, linear splines (with SOS2 or segment binaries), and tree routing (one binary per leaf).

Two consequences follow from that formulation and show up in every section below. First, the bounds and come from bounds on the inputs, propagated through the model. Every input must have finite bounds, and tight bounds give small big-M constants, which gives fast solves. Loose bounds are the most common cause of a slow MILP. Second, the formulation is exact only for piecewise-linear pieces. A SiLU, tanh or softplus activation, a cubic spline, or a polynomial term is not piecewise linear, and you either retrain with a piecewise-linear choice or move to a nonlinear solver.

It helps to name the levels of representability, since not every model lands in the same place.

Uncertainty adds one more ingredient. For several pycse models the predicted standard deviation is a second-order cone in the network’s internal variables, so robust objectives like become mixed-integer second-order cone programs. We come back to this in the pycse section.

Getting a surrogate into a solver

There are three routes from a trained model to an optimization problem, and our packages use all of them.

Direct Pyomo embedding. The model writes its own variables and constraints into a Pyomo Block (Bynum et al. 2021). You pass in your own Pyomo variables as inputs, and the block links them to the surrogate. This is the most flexible route and the one every package here supports (to_pyomo in pycse, jaxsr and jax-difftree, embed_in_pyomo_model in jax-ldt). Any Pyomo MILP solver works: HiGHS, Gurobi, CPLEX, SCIP.

OMLT. OMLT (Ceccon et al. 2022) reads a neural network (usually from ONNX) and builds a Pyomo block with a choice of formulations, such as ReluBigMFormulation. OMLT also has tree formulations, including linear model decision trees (Ammari et al. 2023). In our packages, pycse’s LLPRRegressor exports to ONNX and directly to an OMLT NetworkDefinition (to_onnx(), to_omlt()). One caveat: jax-ldt also writes ONNX, but OMLT cannot read it. OMLT’s ONNX reader understands neural-network layers (Gemm, MatMul, ReLU), and the tree-routing operations (Gather, LessOrEqual) are rejected. That is why the tree packages ship their own adapters.

discopt. discopt is our hybrid MINLP solver with a JAX backend. jax-ldt (embed_in_discopt_model) and jaxsr (to_discopt) write directly into a discopt.Model, and jax-difftree reaches discopt through the jax-ldt spec (more on that below). The advantage of discopt is that the same model can hold MILP surrogate blocks and nonlinear constraints, which is where jaxsr’s allow_nonlinear=True and pycse’s SISSO export are headed. pycse itself writes Pyomo, but the ONNX file from LLPRRegressor.to_onnx() can also be read by discopt.ml.load_onnx.

Whatever the route, the pattern is the same: declare bounded input variables, embed the surrogate, add your constraints, set an objective on the surrogate output, solve, and then check the answer against the model’s own predict.

pycse.sklearn models

pycse has the broadest coverage. A new module in pycse 2.13.0, pycse.sklearn.mip, holds the formulation machinery once, and each estimator only describes its trained weights. A model implements mip_network(), which returns its weights as plain numpy layer specs (Affine, ReLU, PiecewiseLinear), a TreeModel of leaf boxes, or a symbolic expression. A single function, add_to_pyomo, turns any of these into constraints, so the bound propagation, the big-M formulation and the tests are shared across models. For the user it is one call:

import pyomo.environ as pyo
from pycse.sklearn import DPOSE

model = DPOSE(layers=(2, 32, 16)).fit(X, y)       # ReLU by default

m = pyo.ConcreteModel()
m.T = pyo.Var(bounds=(300, 500))
m.P = pyo.Var(bounds=(1, 10))
m.budget = pyo.Constraint(expr=m.T / 100 + m.P <= 12)   # your own constraints
m.nn = pyo.Block()
model.to_pyomo(block=m.nn, inputs=[m.T, m.P])        # input bounds come from your vars
m.obj = pyo.Objective(expr=m.nn.y[0], sense=pyo.maximize)
pyo.SolverFactory("highs").solve(m)

Internal input and output scaling is folded into the exported weights, so m.T, m.P and m.nn.y are in your units.

jax-ldt: linear and hyperplane decision trees

jax-ldt fits linear-model decision trees, where every leaf holds a linear regression instead of a constant, and hyperplane trees, where the splits are oblique hyperplanes chosen from sparse combinations of the inputs. Both are piecewise linear by construction, so they were designed from the start to be embedded. The package was motivated by our work with the Laird group on hyperplane trees as surrogates for chemical process design (Sunshine et al. 2025), which builds on linear model decision trees in OMLT (Ammari et al. 2023). Optimization over tree models more generally goes back to Mišić (2020) and ENTMOOT (Thebelt et al. 2021).

The MILP formulation lifts the features into the transformed (hyperplane) space, uses one binary per leaf, writes the routing as big-M constraints, and linearizes the leaf outputs with big-M as well. The result is an exact MILP. The same formulation is available in Pyomo and in discopt:

import discopt
from jax_ldt import HyperplaneTreeRegressor
from jax_ldt.export import embed_in_discopt_model

model = HyperplaneTreeRegressor(max_depth=4, max_bins=6, min_samples_leaf=15)
model.fit(X, y)

m = discopt.Model("min-y")
x = m.continuous("x", shape=(2,), lb=-2, ub=2)
y_expr = embed_in_discopt_model(model, m, x)
m.minimize(y_expr[0])
result = m.solve()

For Pyomo, embed_in_pyomo_model(model, m, m.x) builds the same formulation on a sub-block, so several trees can share one model. For axis-aligned trees with constant leaves there is also a lighter adapter, to_discopt_decision_tree, which uses discopt’s built-in tree formulation.

The canonical export is a JSON spec (to_json / from_json), and every other format is regenerated from it. That turns out to be useful beyond jax-ldt, because jax-difftree writes the same spec.

Caveats. Big-M constants are derived per node and per leaf from the input bounds, so bounds are required. You can override them with big_m=, and they are validated when the inputs are bounded. The ONNX export is for inference with onnxruntime, not for OMLT, as noted above. The tree’s uncertainty estimates are stored in the spec but are not part of the MILP.

Docs: MIP export, discopt integration. Examples: 04_mip_optimization.ipynb, 07_pyomo_embedding.ipynb.

jax-difftree: differentiable soft trees

jax-difftree takes a different route to a tree. Instead of growing it greedily, it fits a fixed-depth soft tree end to end with gradients (Hehn et al. 2020), with oblique splits and sigmoid routing. Soft trees are smooth and train well, and they can match derivative data (Jacobians from a simulator) as well as values. They are not piecewise linear, though, so getting a MILP takes one extra step.

The workflow is to train with affine leaves, harden the tree so that each point routes to exactly one leaf, and then export the crisp piecewise-affine model:

from difftree import DifferentiableTreeRegressor, export
import pyomo.environ as pyo

model = DifferentiableTreeRegressor(
    depth=3, leaf_type="affine", jacobian_weight=1.0, hardening=True
)
model.fit(X_tr, Y_tr, dydx=J_tr)
print(model.hardening_report_)            # soft vs hard error, before and after

m = pyo.ConcreteModel()
m.x = pyo.Var(range(2))
m.y = pyo.Var(range(2))
tree = export.to_pyomo(model, m, x=m.x, y=m.y, bounds=(lo, hi), method="bigm")
m.obj = pyo.Objective(expr=m.y[0])
pyo.SolverFactory("appsi_highs").solve(m)

The Pyomo export is written as a generalized disjunctive program: each leaf is a Disjunct holding its polytope and its affine model, and a Disjunction makes exactly one leaf active, which Pyomo then transforms (here with big-M). For discopt, export.to_json writes the jax-ldt v1 spec, so jax-ldt’s from_json and embed_in_discopt_model consume a difftree model unchanged. All outputs share one partition, which means a multi-output tree for a unit operation needs only one set of binaries.

Caveats. The soft/hard gap is the main one. The MILP optimizes the hardened tree, not the soft one you trained, so check soft_hard_gap (and train with hardening=True) before trusting the optimum. The leaf polytopes are closed, as usual in big-M formulations, so an optimum can sit on a split boundary using either neighbor’s model; export.repair_solution moves such a point into the chosen leaf. Continuity across oblique splits needs tied_splits=True, which gives up flexibility (a depth- tree then has hyperplanes instead of ). The fixed full-binary structure caps practical depth at around 10 to 12. A pruned export matches predict(hard=True) only inside the export box.

Docs: surrogates for MILP, limitations. Notebooks: piecewise_linear_milp, pyomo_embedding, multivariate_inverse_design.

jaxsr: symbolic regression with hinge functions

jaxsr fits sparse symbolic models, a weighted sum of terms chosen from a basis library by an information criterion, in the spirit of ALAMO (Cozad et al. 2014). The new capability is a family of piecewise-linear basis terms, most usefully hinges and , which give MARS-style fits (Friedman 1991; Breiman 1993). If every selected term is piecewise linear, the fitted model is an exact MILP, and unlike the other models in this post it is also a short, readable equation.

from jaxsr import BasisLibrary, SymbolicRegressor, milp_incompatible_terms

library = (
    BasisLibrary(n_features=2, feature_names=["T", "P"], feature_bounds=[(0, 4), (0, 4)])
    .add_constant()
    .add_linear()
    .add_hinges(X=X, n_knots=7)
    .add_transcendental(["abs"])
)
model = SymbolicRegressor(basis_library=library, max_terms=6, information_criterion="bic")
model.fit(X, cost)
print(model.expression_)
print(milp_incompatible_terms(model))   # [] means a pure MILP

The MILP-representable terms are constants and linear terms (written directly), hinges and abs (one binary each, big-M), categorical indicators (one-hot binaries), and categorical-continuous interactions (an exact McCormick product). The model then goes to either backend with one call, linked to your own variables:

model.to_pyomo(m.sr, inputs={"T": m.T, "P": m.P}, output=m.cost)   # Pyomo block

emb = model.to_discopt(dm_model)                                    # discopt
dm_model.subject_to(emb.inputs["T"] + emb.inputs["P"] >= 5)
dm_model.minimize(emb.output)

Polynomials, interactions, log, exp and the rest are not piecewise linear. You can still embed them with allow_nonlinear=True, which gives an MIQCP or MINLP for discopt, BARON, SCIP or Gurobi.

Caveats. Bounds are required and are enforced on the embedded inputs, on purpose: outside the training range the model is extrapolating, and the right fix is more data, not wider bounds. Knot placement matters more than knot count, since the fit can only bend where a knot exists, so pass known breakpoints (a phase boundary, a saturation point) explicitly with knots=. Parametric and custom basis functions, rational forms and SISSO-style features cannot be embedded. MultiOutputSymbolicRegressor is not supported directly, but each estimators_[i] can be embedded separately. The embedding is built from the fitted coefficients, so rebuild it after a refit.

Guide: Embedding models in MILPs. Example: mip_surrogate_optimization.ipynb, which includes a refine-and-resolve loop and a design problem solved in both backends.

Choosing a model

The packages overlap, but they are good at different things. If you want an interpretable equation, or you know where the response bends, jaxsr’s hinge models are the natural choice, and they stay small. If you want a flexible fit with uncertainty and the option of a robust or exploratory objective, the pycse ReLU networks are the most complete, and the input-convex networks are the cheapest to optimize when convexity is physically justified. Trees are attractive when the response has genuinely different regimes: jax-ldt grows them greedily and exports directly, while jax-difftree trains them end to end, can use derivative data, and needs the hardening step before export.

	pycse ReLU nets	pycse KAN	jax-ldt	jax-difftree	jaxsr hinges
Binaries scale with	hidden units	grid × inputs	leaves	leaves ()	hinge/abs terms
Interpretable	no	partly	partly	partly	yes
Std in the MIP	yes (SOCP)	with LLPR/ensemble	no	no	no
Pyomo	yes	yes	yes	yes (GDP)	yes
discopt	LLPR via ONNX	no	yes	via jax-ldt spec	yes
OMLT	LLPR via ONNX	no	no	no	no

The caveat that applies to all of them

A global optimizer finds your model’s mistakes. Our first run of the pycse benchmark used 150 samples and shorter training. Two of the models came out poorly fitted, and their global optima sat on the edge of the box, where there was little data and the models were extrapolating: one predicted at a point where the true is . A local optimizer started in the middle might never go there, and the MIP always will. The global optimum of the surrogate is only as good as the surrogate is in that region. So validate the optimum against the true model, and then either add data there and refit (jaxsr’s notebook has a refine-and-resolve loop, and our earlier active-learning post covers the data side), penalize the std, or tighten the bounds to the region you trust.

Installing

The MIP export is in pycse 2.13.0 and later. Pyomo and HiGHS come with the mip extra; the ONNX and OMLT exports of LLPRRegressor also need onnx and omlt.

pip install "pycse[mip]"

jaxsr 0.3.0 is on PyPI, but the hinge terms and MILP embedding are newer than that release, so install from GitHub for now. jax-ldt and jax-difftree are not on PyPI. (The difftree package on PyPI is an unrelated project, so install jax-difftree from GitHub as shown.)

pip install "jaxsr[mip] @ git+https://github.com/jkitchin/jaxsr.git"
pip install "jax-ldt[pyomo] @ git+https://github.com/jkitchin/jax-ldt.git"
pip install "difftree[pyomo] @ git+https://github.com/jkitchin/jax-difftree.git"
pip install discopt omlt onnx

References

Why differentiable models?

If there is one nearly unifying principle in optimization, it is that derivatives play a central role in much of it (I know not all of it; integers are not differentiable, and you often have to estimate derivatives, etc.). Optimization means many things as illustrated above. We can use it to fit parameters, simulate, reconcile data, plan, control, design experiments and more! These all rely on the central model, and different combinations of what know, what you want, and how you get it. What we aim for in our ecosystem shown above is for a single model to be reusable across many tasks.

The graphic above is interactive, and you can see how the task is implemented in many of the tasks through notebook examples. We have not fully integrated everything seamlessly yet, but we are working on it and making good progress. If you find bugs or have suggestions, please let us know by opening an issue on GitHub!

The big pivot into optimization

Over the past year I have been making a big pivot in research into optimization. I have always learned by doing, and this post documents some of that journey. This transition has been happening for a while, really starting about a decade ago when I started using machine learning to build surrogate models for DFT. That work led to this perspective on differentiable programming in scientific programming. That has led to this year’s work in differentiable optimization. My goal is to build an end-to-end differentiable optimization stack that integrates differentiable programming, differentiable solvers, and differentiable surrogates.

Why do we need new solvers at all?

There are a plethora of options, very good commercial ones, and open-source ones. I work in higher education, and I think it is important that free, open-source solvers exist for students and researchers. I got into computational catalysis as a student because there was a free code I could use, read, modify and learn from. It is often not possible to do this with closed codes. Even if my codes aren’t as good as other codes, if they open the door for others to learn then a part of the mission is accomplished.

New starts mean new things are possible. pounce is more comprehensive than Ipopt in interior point methods, with integrated sensitivity and other great features that are 1) pip-installable, 2) capable of running in your browser, and with interfaces to use in other interfaces. discopt led to new integrations of ideas, and eventually to the development of jax-go which bridges the gap between program and equation-based optimization. difflow is a new way to think about optimization, and the differentiable surrogates are a new way to think about optimization with uncertainty quantification.

Agentic optimization is a new thing with these solvers. The tight integration of agentic coding with differentiable programming and differentiable solvers is a new paradigm that is more possible with these new solvers because they were designed with this in mind. We have integrated agentic debugging, and agentic optimization.

What is next?

I have laid out an ambitious vision for the end-to-end differentiable optimization stack, and I think we are making good progress on it. It is a lot, and we don’t use all of them every day. Some of these tools are stabilizing. Feral is pretty stable now. I probably work on pounce once a week or so. discopt and difflow are still changing fast. It would probably be a lie to say there won’t be new packages coming. I still have many private projects that haven’t seen the light of day yet, but will eventually.

We (the Kitchin group) are beginning to enter a new era of applications. Inspired by the algebraic modeling language we made discopt-mkm for microkinetic modeling, and discopt-calphad for alloy phase behavior. discopt-doe is a new direction in design of experiments. We have projects in process modeling, alloy design, rare earth separation, and more.

It is always dangerous to predict the future, but I think 5 years from now we will have a much more integrated landscape of differentiable optimization tools. Right now programmatic automatic differentiation is mostly only available as addons like jax, pytorch in Python, and something like that in Julia. AD is coming to Rust as a native feature in a few years, and predict this will be a game changer for optimization. The pace of development I have demonstrated this year means it will probably only take a year or so to transition from a Python or Julia focused solution space to Rust if we decide to. These changes come with 20/20 hindsight and lessons learned from everything we know now, so they happen very quickly. I think the next 5 years will be very exciting for differentiable optimization.

I still think we are not thinking big enough as a community. I am grateful to a few people who made substantial contributions to these codes: Devin Griffith for major contributions to sensitivity in pounce, Germán Heim for integrating pounce into his modeling language oximo. Milan Rother forked feral into RSLAB and was the inspiration for pounce in the browser. Victor Alves for using pounce before anyone else. David Bernal for major contributions in global optimization in discopt, and ideas linking it to pounce. All this work was done by a very small number of people, and I think we can do better as a community.

It is an open challenge to figure out how to sustain these efforts. Pyomo and IDAES were built over two decades, with generous federal funding. This is a challenge today as that funding becomes more scarce. We need new models to support this kind of work that balances keeping open-access to the code, and generating revenue to support the people who build it.

Along this journey I have come to appreciate that 1) I still have a lot to learn in this space, and 2) there is not one tool to rule in optimization; there are many ways to solve problems, and some ways are better than others for certain problems. That means you have to have a landscape of pathways to choose, and historically I have chosen the roads less traveled. I have learned a lot along the way, and I hope this post helps others to learn from my journey.