Most agentic AI demos in insurance are a chatbot with a policy document behind them. We wanted to know what happens when agents actually run the functions — so we built a specialty property and casualty carrier and staffed it with them.
It is called Vsure. It has 240 insureds, $243M of written premium, 775 claims and a live reinsurance programme with real treaty layers and a panel behind them. Every carrier function has been run end to end by AI employees working through the same APIs a human employee uses.
We did not build it to sell insurance. We built it as a conformance harness for our own products — a way to find out where they break when something autonomous is pushing on them from the outside.
The staff
The agents are not personas in a prompt. Each is a record: a code, a role, a manager, a book of work, and a set of authority levels per capability.
| Function | What the agent does | Typical authority |
|---|---|---|
| Broker | Finds prospects, assembles submission packs, sends to market | L1 draft, L2 to open an account |
| Underwriter | Assesses appetite, rates, quotes, binds, endorses, audits premium | L2 bound by limit, L3 for endorsements |
| Adjuster | Takes FNOL, sets reserves, settles, closes | L2 to $50k, escalates above |
| Reinsurance analyst | Cedes losses to treaty layers, tracks capacity | L3, capacity-bounded |
| Supervisor | Approves escalations, sets limits | L3 / L4 |
The important design choice: the agents have no privileged access. They call the same REST endpoints an employee's browser calls, authenticate as themselves, and are subject to the same permission checks. There is no back door, no direct database write, no "agent mode" that skips validation. If a human could not do it through the UI, the agent cannot do it through the API.
This is what makes the exercise worth anything. An agent with special access tests nothing.
How a piece of work actually flows
flowchart LR
P["Public and private
data sources"] --> BR["Broker agent
finds a prospect"]
BR --> PK["Assembles pack
6 documents"]
PK --> S3[("Document store")]
PK --> UW["Underwriting
intake"]
UW --> AP{"Appetite
check"}
AP -->|"outside appetite"| REF["Refused
agent retries
another account"]
AP -->|"in appetite"| Q["Queue item
assigned"]
Q --> QT["Quote"] --> BD["Bind"] --> POL[("Policy")]
POL --> CLM["Claim / FNOL"] --> RS["Reserve"] --> ST["Settle"] --> CL["Close"]
RS --> CED["Cede to treaty"]
style REF fill:#fbede3,stroke:#b4531b
style AP fill:#efecfe,stroke:#4b34e0
style POL fill:#e2f5f9,stroke:#0e97b0
style S3 fill:#e2f5f9,stroke:#0e97b0
What we were actually testing
Three hypotheses, in order of how much we cared.
1. Do the controls hold when something tireless pushes on them?
A human underwriter tests a limit occasionally, by accident. An agent will test it hundreds of times, systematically, and will find the phrasing or the argument shape that gets through if one exists.
The headline result: zero unauthorised writes across the whole book. The adjuster escalated on 11 of his 17 runs rather than finding a way around his $50,000 limit. That is the number we set out to produce and the one that matters most.
2. Does the audit trail survive contact with a real workflow?
Less good, initially. This is where the conformance harness earned its keep, and where most of what we have written on this blog comes from. We found:
- A trace schema silently dropping fields it did not declare — five times, in five places. Written up here.
- A renewal control that computed a rate change correctly and enforced nothing. Written up here.
- Reserve leakage on closure, a settlement that was never written, a release issued before payment, and a duplicate payment. Written up here.
- An attachments parameter forwarded as an empty list, so submission documents arrived referenced but not stored.
Every one of those was a bug in our own products, found because an agent did the work end to end and the resulting ledger had a hole in it.
3. Do the economics work?
Cheaper than expected, and the interesting part is the denominator. Per cleared submission the model spend is $0.31; per reserved claim, $0.18. Those are numbers you can put next to a loaded hourly rate and have a real conversation. See deriving cost per business outcome for how they are computed.
The book
The data is synthetic but not arbitrary. Exposures are drawn from real public filings, so employee counts, payrolls and class codes are plausible and internally consistent; a manufacturer's payroll matches its headcount, and its loss experience matches its exposure. Loss ratios sit in a believable band rather than being sampled uniformly. This matters because an agent reasoning over incoherent data produces incoherent behaviour, and you learn nothing about your controls from that.
Every carrier function has been run end to end — that is true, specific and checkable in the ledger. The carrier does not run itself on a schedule; there is no cron behind it. We are careful about this distinction because it is the kind of thing a prospect tests on the first call, and one overstated line would put every other number in this post in doubt.
What we would tell someone attempting this
Four things we would do differently, or do again deliberately.
Give the agents no special access, from day one. The temptation to add a fast path is constant and it invalidates the whole exercise. Every shortcut you grant is a control you are no longer testing.
Make the synthetic data cohere. Random values produce random behaviour and teach you nothing. Time spent making exposures, payrolls and losses consistent is the highest-leverage work in the setup.
Build the ledger before the agents. We did it the other way and spent weeks reconstructing what had happened. The observability layer is not the thing you add to watch the experiment — it is the thing that makes the experiment legible at all.
Expect the bugs to be in the plumbing. Almost nothing we found was a model failure. The agents reasoned reasonably. What broke was the software between the agent and the system of record: dropped fields, unenforced checks, events emitted before commit. That is where to look.
What InsightLense did in all this
The carrier is the harness. InsightLense is what made it legible — and building it second was our biggest mistake, because for the first few weeks we were reconstructing what had happened from logs and memory.
| Layer | Volume | What it answered | Defects surfaced |
|---|---|---|---|
| Runs and steps | 41,208 | where a run stalled, what it cost | 2 |
| Authority decisions | 8,116 | what was refused and by whom | 1 |
| Business events | 12,940 | what changed, old and new value | 6 |
| Scores | 3,204 | where judges and underwriters differ | 1 |
That distribution is the argument for the whole product. The run traces are genuinely useful and they found two bugs. The layer that found six is the one most observability tools do not have, because it needs entities, values, actors and authority — and those are schema decisions you cannot retrofit onto eighteen months of history.
Why this is the argument
We could have written a page claiming our products are robust. Instead we can point at a book of business, a set of defects we found in ourselves and fixed, and a ledger where every one of those claims is checkable.
The uncomfortable version of the same sentence: if you are buying agent infrastructure from someone who has never run agents against their own systems of record at volume, you are the harness.
Where do your agents already act on real records?
Tell us that, and what you would need to prove about those actions to an auditor. We will set up a hands-on walkthrough within two weeks.
Request a demo →