---
path: /workbench
title: "Tesora Workbench: the agent harness behind actuarial work"
description: "A coordinator breaks the request into tracked work, specialist agents own each domain, and read-only review agents check the result before an actuary does. Every value cited, every session reproducible."
section: Product
priority: 0.9
changefreq: monthly
source_file: pages/marketing/WorkbenchPage.tsx
---
# 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 those decisions, and then built what that actually takes: the ingestion, the citations, the method library, the review agents. Nobody had built that layer, so we started there.

## None of it came with the model.

**Everything above the floor is what an actuarial answer needs before anybody will sign it. You had to build all of it yourself, or go without.**

## You cannot bolt a chat box onto software written before the models.

**The model companies are not building for actuarial outcomes, and they are not going to. The actuarial software you can buy is too rigid to get there either: it tells you to arrange your data until it matches the input its form expects, and the chatbot most of them have bolted on the side does not change the shape underneath it.**

**You would have to tear all of it down to build this properly, so that is what we did. The whole stack starts from the models, with the actuarial rules and standards built in as constraints rather than bolted on afterwards, and provenance carried through every step so the answer can be checked. What you get is a system you talk to the way you would talk to a colleague, that runs from the raw files through to the finished deliverable and waits on your judgement rather than on your formatting.**

### How a rate plan gets owned today.

## A number that cannot be traced does not reach you.

Two things make that true rather than a promise.

## How does this work with what we already run?

**Get work done faster.**

Give us an analysis with a mistake still in it and watch which review agent catches it. That is a faster read on this than any demo.

**The spreadsheet and the filing PDF**

It works, one person understands it, and it is the reason a rate change takes a quarter. Nobody chose this; it accumulated.

Change a factor: somebody opens the workbook and hopes the dependency they are about to break is documented.

**A platform built for one shape of work**

Genuinely good at the job it was designed around, and the right purchase for a team whose work is that shape. The constraint arrives at the edges: a line, a state or a program the model was not drawn for.

Change a factor: you change it where the platform expects the change, and re-implement it wherever it does not.

**Something you can redirect**

You ask for the change in plain language, against the rater you already filed. What comes back has been through the test suite, carries a version number, and cites the filing page every constant came from.

Change a factor: you describe it once, and it propagates to every state, line and program the factor applies to, each one tested separately.

**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 rather than yours. 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. Buying hours gets you a deliverable; buying this gets you the ability to produce it again next quarter, in your 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. Most of onboarding is not plumbing, it is the system learning how your team presents work, which tables you like to see and in what order, and what last quarter looked like. After that a reserving report comes back built on your own precedents and the methods you ran last time, and the only thing left to add is your judgement at the end.