Main site

Insurance AI agent · Subrogation

Subrogation-Identification AI Agent

Read the claim file for recovery potential, name the responsible third party, check the bars and date the limitation period — a recovery handler decides whether to pursue, and the agent demands nothing.

Typical delivery
4–6 weeks
Deployment
Your stack
Pursuit
Handler only
After launch
Agent Care

What this agent does

Finds the recovery, never makes the demand

In

  1. 01

    Take the claim as it stands — loss detail, policy, payments made, documents, parties and dates.

  2. 02

    Read the wordings, contracts and statutes that decide whether recovery is available at all.

Reason

  1. 03

    Name the third party the loss points to, and the liability the file itself supports.

  2. 04

    Date the limitation period from the insured's cause of action, by jurisdiction and claim type.

  3. 05

    Check the bars — waiver of subrogation, anti-subrogation, made-whole and statutory prohibitions.

Decide

  1. 06

    Where nothing in the file points to a third party, the claim carries on down its normal path.

  2. 07

    Everything else goes to a recovery handler, including files where a bar appears to apply.

Out

  1. 08

    Assemble the demand pack — payments, the insured's excess, evidence and the governing terms.

  2. 09

    Retain what was read, the dates relied on, the bars checked and the handler's own decision.

Product statement

The agent identifies recovery potential and assembles the file. Whether to pursue belongs to a recovery handler, and no demand, no arbitration filing, no negotiation and no settlement is made by the agent — on any tier and in any configuration.

Example workflow

One claim file, end to end

  1. 1Claim file readA claim at payment, at closure or on a periodic sweep, with the payments, documents and parties on it
  2. 2Governing terms pinnedThe policy wording, the contracts behind the loss and the statute for that jurisdiction and claim type, with the date read
  3. 3Responsible party identifiedThe third party the file points to, and the liability the evidence in the file actually supports, cited to source
  4. 4Bars and limitation checkedWaiver, anti-subrogation, made-whole and line-specific bars run, and the limitation date computed with the days left on it

No human action required

Stages 1 to 4 run without a person in the loop — the reading, the bar checks and the limitation date are finished before a handler opens the file. Nothing has been demanded.

5DecisionSplits on whether anything in the file points to a recovery
No recovery indicated

Carries on down its normal claim path.

A recovery, or a bar, appears

Goes to a recovery handler, unpursued.

Recovery handler

Reads the file themselves, decides whether to pursue, and chooses the forum and the wording of any demand.

Pursue · Decline · Send back

Declined — handed back

  1. 6Handler outcome recordedPursue, decline or send back, in the handler's own words, under their name, with the limitation date attached
  2. 7Outcome evaluatedRecall against recoveries handlers found unaided, flag timeliness, false referrals, bar detection and pack completeness, by line and jurisdiction

Handler outcomes

Every file a handler declines, and every recovery they found without it, is counted.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Issuing a subrogation demand to anyone.
    • Filing inter-carrier arbitration or court proceedings.
    • Negotiating, compromising or settling a recovery.
    • Waiving, releasing or abandoning a recovery right.

  • Automation boundary

    Agent acts unaided

    • ✓Pin the wording, the contracts and the statute that govern the loss.
    • ✓Name the third party the file points to, and cite what supports it.
    • ✓Date the limitation period and count the days left on it.
    • ✓Assemble the demand pack from records the file already holds.

    Write actions run only inside the approval boundaries agreed during implementation. A demand is not one of them — a recovery handler issues it under their own authority, and the limitation date is theirs to diary.

    • Concluding that a bar or waiver applies.
    • Closing a claim file to recovery.
    • Dropping the insured's excess from a demand.
  • Changing the recovery-scoring rules or thresholds.

Example output

One claim file, annotated

Everything the agent marks is attached to the record and the clause it was read from.

Subrogation output · single claim file

Illustrative example
Claim
Commercial property, paid
Contracts
Two, dated
Third party
Contractor on site
Limitation
Dated, not expired
Confidence
87%
Demand
None — handler's

As received

The file as it stands and the contracts behind the work, read at their own dates rather than the loss notes.

Evidence used

  • Payment ledger and excess
  • Signed works contract
  • Cause-of-loss report

Why it stays open

The works contract waives subrogation, but only so far as the property policy pays.

What the score decides

How hard the handler should look for a bar the agent missed, not whether to pursue.

Action

PursueDeclineSend back

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every paid claim

From claims, payments and closure

03Bars & limitation

Read the terms that decide it

The policy wording, the lease, works contract or service terms behind the loss, and the statute for that jurisdiction and claim type — read at their own dates and stamped.

01Approved path

Catch it while there is time

The limitation date is computed when the claim is paid, from the insured's own cause of action — not when someone reaches the file.

02Human review

Put the bar in front of a person

A waiver in the contract, an anti-subrogation problem or a made-whole question is handed over as something to decide — never used by the agent to close a file quietly.

04

Build an evidence trail

Retain the wordings and contracts read, the limitation date and its basis, the bars checked, the handler's own decision and what came back — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Claims & policy admin

    • Guidewire ClaimCenter
    • Duck Creek
    • Sapiens
    • payment and closure APIs

  • Recovery case management

    • Subrogation case systems
    • queues
    • Limitation diaries
    • finance ledger

  • Inter-carrier arbitration

    • Arbitration Forums
    • signatory lists
    • Loss-transfer filings
    • deferments

Agent

Subrogation identification

  • Reads the file
  • Checks the bars
  • Hands to recovery

  • Evidence & legal panel

    • Contracts and leases
    • repair estimates
    • Police and fire reports
    • panel referral

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and a demand

Each control wraps the one inside it. A recovery view clears every layer before a handler opens it, and the demand itself sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReturn screening to staff if recall or flag timeliness degrades.Roll back
L5TraceabilityRecord the sources read, the dates relied on, the decision and the outcome.Record
L4Handler gateA recovery handler decides to pursue, and issues any demand themselves.Gate
L3Bar disclosureEvery bar found is shown to a handler, never applied by the agent.Disclose
L2Limitation guardNo file leaves without a dated period and the days left on it.Date
L1Terms versioningWordings, contracts and statutes pinned at the dates they applied.Pin
Model coreRecovery view — the third party, the liability the file supports, the bars checked and the limitation date
L1 – L2
Decide whether the finding may stand
L3
Keeps a bar out of the agent's hands
L4
Puts the demand with a recovery handler
L5 – L6
Keep the trail and pull automation back

How Nestack evaluates it

Evaluate the recoveries it found — and the ones it did not.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the recovery view a handler opens

  1. E1Final-output evaluationDid it find the recoveries a handler later found without it?
  2. E2Step-level evaluationWas the limitation date right for that jurisdiction and claim type?
  3. E3Tool evaluationDid it read the correct claim, policy, contract and payment ledger?
  4. E4Bar detectionWere waivers, anti-subrogation and made-whole issues found before referral?
  5. E5Slice evaluationHow does performance change across lines, jurisdictions and claim sizes?
  6. E6Business outcomeFalse referrals, and how much time was left when the flag arrived.

Floor — the recovery that could still be pursued in time

Failure modes

Where each failure originates in the agent

Seven failure modes plotted against the five stages of the agent lifecycle.

Agent lifecycle

Direction of processing →

  1. 01 · File sweep

    1 mode

    • SB-01

      Found after the period ran

      The file is screened once the limitation date has passed.

    Stage gathers

    The claims, the payments, the documents and the parties

  2. 02 · Terms lookup

    1 mode

    • SB-02

      Waiver of subrogation missed

      The contract behind the loss gave the right away.

    Stage pins

    The wording, the contracts and the statute in force

  3. 03 · Liability & bars

    2 modes

    • SB-03

      Made-whole or anti-subrogation bar

      A barred file referred as a live recovery.

    • SB-04

      Liability read off the report

      A fault code taken as evidence the file lacks.

    Stage tests

    The theory the file supports and every bar against it

  4. 04 · Pack / handover

    2 modes

    • SB-05

      The insured's excess dropped

      The pack claims the carrier's outlay alone.

    • SB-06

      Referred to the wrong forum

      Court where the agreement compels arbitration.

    Stage hands over

    The recovery view a handler actually opens and works

  5. 05 · Drift / Version

    1 mode

    • SB-07

      A scoring change drops a category

      A whole recovery type stops being surfaced, silently.

    Stage tracks

    Scoring changes, recovery patterns and outcomes

  • Sev-1 · a recovery is lost, or never existed
  • Sev-2 · the pack misstates what can be recovered
  • Sev-3 · time is lost, the handler re-routes it
See the complete Insurance failure-mode catalogue

Affected slices

The misses cluster where the clock is shortest

A score that learns to skip small or uninsured third parties is a proxy for whose excess comes back, and a few jurisdictions carry most of the recoveries never surfaced. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Short-limitation jurisdictions6.3%3.3×Review
Public-entity and government losses5.0%2.6×Review
Contract-governed property losses3.7%1.9×Watch
Routine motor, carrier at fault1.3%0.7×Normal

Bar: missed-recovery lift vs. routine motor baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

A recovery a handler found unaided is a miss

Recall is measured against the recoveries your handlers found without the agent, and against the categories the scoring quietly stopped surfacing.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Recall, flag timeliness or false-referral rate moves in a slice.

  2. 02

    Diagnose

    Traced to the sweep, the terms read, a bar test or the score.

  3. 03

    Improve

    The rule, source or threshold is changed, re-approved by the recovery lead and version-linked.

  4. 04

    Verify

    Re-run against held-out files, including every recovery a handler found unaided.

  5. 05

    Learn

    The missed file becomes a regression case with its limitation date marked.

  6. Learn → Detect

    The return edge. Every scoring change is re-run against the categories it could drop — a cohort that goes quiet stops the change from shipping.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, rule and jurisdiction mapping, limitation logic and bar tests, evaluation, handler workflow, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Workflow discovery and automation-boundary definition.Week 1
  2. 02Recovery-rule and jurisdiction mapping.Week 1, Week 2
  3. 03Claims, policy and payment-ledger integration.Week 1, Week 2
  4. 04Limitation logic by jurisdiction and claim type.Week 2
  5. 05Contract and wording retrieval scoping.Week 2, Week 3
  6. 06Waiver, anti-subrogation and made-whole tests.Week 3
  7. 07Demand-pack format sign-off with handlers.Week 3, Week 4
  8. 08Excess completeness and finance reconciliation.Week 4
  9. 09Forum and arbitration routing rules.Week 4
  10. 10Recall, timeliness and cohort-slice evaluation.Week 4, Week 5
  11. 11Case management and legal-panel handover.Week 5, Week 6
  12. 12Observability, deployment and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne line, one jurisdictionProductionProduction recovery integrationAdvancedMulti-line / multi-jurisdiction
Introduced at Pilot
Recovery screening and scoring✓✓✓
Limitation dating and flagging✓✓✓
Waiver and bar checks✓✓✓
Demand pack for handlers✓✓✓
Handler pursuit gate✓✓✓
Baseline and cohort-recall evaluation✓✓✓
Introduced at Production
Claims and recovery case integration—✓✓
Excess completeness reporting—✓✓
Observability and audit trail—✓✓
Introduced at Advanced
Forum routing and arbitration support——✓
Multi-jurisdiction and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the lines and jurisdictions in scope, the wording and contract sources read, claims and recovery-system integrations, claim volume, handler workflow controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01The lines, jurisdictions and claim types in scope

    Workflow discovery and automation-boundary definition

    Week 1

  2. 02Your recovery rules and the bars you already apply

    Recovery-rule and jurisdiction mapping, and the limitation logic

    Week 2

  3. 03Access to claims, policy admin and the payment ledger

    Guidewire or Duck Creek, and your recovery case system

    Week 2

  4. 04The contracts, leases and wordings behind your losses

    Contract retrieval scoping and the waiver and bar tests

    Week 3

  5. 05Real files, including recoveries your handlers found late

    Evaluation suite, regression cases and failure-mode testing

    Week 4

  6. 06Named recovery handlers and a recovery lead

    Handler workflow, pack format and recall tracking

    Week 4

  7. 07Your policy on excess recovery and who may issue a demand

    Excess completeness checks, the handler gate and the audit trail

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases are drawn over the weeks they actually occupy. Nothing is demanded in any of them; week 5 measures recall against the recoveries your handlers found.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Lines and jurisdictions in scope; who may issue a demand

W2Limitation logic, claims, policy and payment-ledger integration

W3Contract retrieval, the bar tests and the demand-pack format

W4Handler workflow, evaluation suite, cohort slices and failure-mode testing

W5First live packs, recall measured against handler-found recoveries

W6Handlers work live files from agent packs, then handover

Reading the band
Recall in week 5 is measured against files your handlers worked in the same period, not a retrospective sample. Each bar covers its own weeks only.
At the end of W6
Handlers have worked live files from agent packs, and every demand in that period was issued by a handler under their own authority.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Insurance AI agent

Build a subrogation agent around the recovery team you already have.

Show us how a paid claim gets looked at for recovery today, the jurisdictions and claim types you work across, and who may issue a demand. We'll date the limitation period on a week of your own closed files and show you every recovery that was already out of time.

Typical delivery
4–6 weeks
Deployment
Your claims and recovery stack
Pursuit
A recovery handler, always
After launch
Agent Care available

Nestack Agents · Subrogation identification & referral

AGT-INS-09 · Agent Care available after launch

Build a subrogation agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.