Tesora Workbench: the agent harness behind actuarial work

We rebuilt actuarial work around the models.

The decisions stay with your actuaries. We pointed the models at the busy work around them, and then built what that takes: the ingestion, the citations, the method library, the review agents.

Introducing the Tesora Workbench

The agentic OS for actuarial work

The same tools, inside Claude.

An actuary who already works in Claude does not have to leave it. The rating models, the documents and the review queue are tools Claude can use directly, under the same governance as the screen.

We read filings and build raters at a volume that turns rare failures into weekly ones. So we know where these things stop working, because we watch it happen on real work rather than on a benchmark.

A better model lands inside a system that already knows what a reserve review is and what it may not do. So it arrives as work you can sign rather than as a project, which is what makes a frontier release somebody else’s good news.

Established software has the opinions of people who understood actuarial work, wired into something that cannot take an instruction. The models are the opposite: they will do anything you ask and know nothing about what a reserve review is for.

We built the part in between: which methods a study may use, the provenance under every figure, the review before anybody sees it. An agent that demos well is not hard to build. One you can point at work somebody has to sign is.

What you are choosing between, and what each one costs you.

Still working out which category your problem is in? We sorted the market into four, and we are only in one of them.

A number that cannot be traced does not reach you.

Two things make that true, and you can check both of them.

What people push back on.

Try to catch it out.

Send us an analysis with a mistake still in it and see which review agent finds it. We rather enjoy this one.

The spreadsheet and the filing PDF. Nobody chose this; it accumulated.

Good at the shape of work it was drawn for. The constraint arrives at the edges.

Two engineers and a year. It usually ships, and then somebody has to keep it.

You ask for the change against the rater you already filed, and it comes back tested.

We already have Claude or Copilot. Why Tesora?

Those are models, and we route to them too. The model is the engine rather than the product. What an actuary needs around it is everything on this page: the data wired in once, the method held to, and the record kept. A chat window starts empty every morning.

Which model are we paying for?

Whichever one gets each step right for the least spend, and the routing is our problem. A model vendor will never tell you to buy less of what it sells. We are paid for the result, so keeping that bill down is work we do for ourselves.

What do we get back?

The layer that gets a number from where it lives to where it has to go, and keeps the trail. Hire a consultant and you get the deliverable. Here you also get to produce it again next quarter yourself, in your own format.

How does this sit with our current stack?

Excel shop, Python and R shop, some of both: it works either way, and nothing has to be migrated first. Onboarding is mostly the system learning how your team presents work, so a report comes back on your own precedents with only your judgment left to add.

MCP server

35 actuary-native tools, hosted. Five of them hand the whole job to an agent.

A skill

The order an actuary works in, written down, so Claude follows it.

A subagent

Its own context, for a job too long to hold in a conversation.

We built our own evals and benchmarks

Nobody had a way to measure whether a model is any good at actuarial work, so we wrote one: evals graded against what a reviewer would accept. We post-train on the workflows we see and nobody else does.

We are paid for the result, not for the tokens

So each step goes to the cheapest model that gets it right, and keeping that bill down is work we do for ourselves. A model vendor has no reason to do either.

We are who you call when the build stalls

The in-house version usually gets built, comes in expensive, and then fails the IT review because the governance around it was never there. We have had that conversation enough times to know how it goes.