Moody's AXIS and FIS Prophet are the platforms life insurers run their core modeling on. Reserves, pricing, cash-flow testing, block appraisals — the work lives in those two systems. They are proprietary. Their objects and how they hang together are not on the public internet. I built a plugin that works inside that world: it reads an existing dataset, writes a new one, and builds the products, funds, assumption tables, and batches a modeler would otherwise click together by hand. An actuary signs it before anything is used. No one assigned this. I built it because the bottleneck is people who can drive the software, not compute.
A new product, a new in-force block, a new assumption set is weeks of a specialist in AXIS or Prophet. They build a dataset: product definitions, fund mappings, mortality and lapse tables, the links that bind them, a validation batch, then a run. The sequence is known. The software is not. House standards live in shared drives and in the heads of the two people who have been on the account for a decade.
Off-the-shelf models are no help. They invent a table type that does not exist in this workspace, a fund that is not on the product, a cell that the platform will not accept. The person who can sit in the UI, see what is missing, and finish the dataset is scarce. Compute is not the constraint. That person is.
The plugin works the way a modeler works. It does not replace AXIS or Prophet. It builds the dataset those platforms already know how to run.
I modeled the objects a dataset actually contains: product, fund, table, link, batch, run, plus the workspace and version metadata that make two datasets incompatible. Writes go through that model. A hallucinated table type never becomes a file.
The tools read and write datasets the way the platforms already do — the same objects a modeler creates in the UI. Then they ask the software to validate: is the product attached to a fund, do the tables exist, will the batch run. If the platform says no, that message is input, not a toast. The graph repairs the object and tries again.
On top of that sits the knowledge the software will not give you: vendor documentation, sample datasets, and the firm's modeling standards, retrieved with citations so a proposed lapse table can point at the standard it claims to implement.
The agent graph — LangGraph, models routed through LiteLLM — plans the dataset, writes the objects, validates in the live workspace, and fixes what the platform rejects: a missing link, a table that is not there, a version that does not match. It stops when the dataset is clean or when it hits something it cannot resolve. That loop is measured against gold datasets in CI, with traces and cost in LangSmith. It is not reverse engineering the vendor. It is building the same dataset a specialist would build, faster, and leaving it for an actuary to accept.
Nothing goes to a production run unattended. The plugin stages the dataset, the validation log, a diff against the last accepted model, and the citations on every assumption table. An actuary reviews it the way they would review a colleague: open the product, walk the funds, check the tables, read the batch. They approve, reject, or send it back. Only then is it used.
The platform can tell you the objects hang together. It cannot tell you the mortality basis is the one the pricing committee signed. That is why the human stays on the step.
On one engagement — a term block, about a $250k modeling project — the same dataset a specialist would have spent four weeks assembling was built overnight. Model spend was about $1,200. The actuary reviewed it the next morning.
That is the hard fact. The same graph can sit on other modeling work — a new product, a reprice, a block we did not build the first time — wherever the job is opening AXIS or Prophet and clicking for weeks.
Python, FastAPI, LangGraph, OpenAI Agents SDK, Pydantic, LiteLLM, LangSmith, AXIS / Prophet dataset read-write, Playwright, pytest.