Main site

Insurance AI agent · Underwriting

Underwriting Data-Gathering AI Agent

Pull the third-party and internal data an underwriting file needs, reconcile what the sources disagree about, and show every field's origin — the underwriter decides, on evidence that can be cited.

Typical delivery
4–6 weeks
Deployment
Your stack
Risk decision
Underwriter
After launch
Agent Care

What this agent does

Assembles the file, decides nothing in it

In

  1. 01

    Take the submission as it arrives — named insured, entity, address, vehicle or property, and the broker's description.

  2. 02

    Order the reports and internal records the guideline calls for: loss history, prior policies, inspections, exposure data.

Reason

  1. 03

    Resolve every record to the entity, address, VIN or location the submission names, and hold back the ones that do not.

  2. 04

    Normalise units, dates, classifications and addresses, so a figure from one source can be compared with another at all.

  3. 05

    Set the sources side by side, keep the disagreements visible, and stamp each field with its source and its as-of date.

Decide

  1. 06

    Where the records match, the sources agree and every field is cited, the file reaches the underwriter complete.

  2. 07

    Conflicts, stale records and weak matches are named in the file and put in front of an underwriter as open items.

Out

  1. 08

    Hand over one file — each field with the source it came from, its date, and any source that reads differently.

  2. 09

    Retain the sources ordered, the versions read, the matches made and the fields the underwriter later corrected.

Product statement

The agent gathers, reconciles and shows its sources. The risk decision is the underwriter's — and nothing adverse to an applicant may rest on a source the file cannot cite.

Example workflow

One submission, end to end

  1. 1Submission receivedA new or renewal submission with the named insured, entity, location and the broker's own description
  2. 2Sources orderedThe third-party reports, bureau and property or vehicle data, and internal loss, policy and inspection history the guideline calls for
  3. 3Records matched to the riskEach record resolved to the entity, address, VIN or location the submission actually names — or held back
  4. 4Fields reconciledUnits, dates and classifications aligned; where sources disagree, both readings are kept with their dates

No human action required

Stages 1 to 4 run without a person in the loop — ordering, matching and reconciliation are finished before an underwriter opens the file. Nothing has been assessed.

5DecisionSplits on whether the file is matched, current and free of unresolved conflict
Matched, current, no conflict

Reaches the underwriter as a complete file.

Conflict, gap or weak match

Reaches the underwriter with the open items named.

Underwriter or underwriting technician

Sees the disagreement, the sources behind it and their dates, and decides which record stands — or orders the source again.

Accept · Correct · Order again

Resolved — handed back

  1. 6File handed to underwritingRecorded with each field's source and as-of date, and the open items named rather than closed
  2. 7Outcome evaluatedMatch precision, source currency, conflicts surfaced, provenance completeness and underwriter rework, by cohort

Source corrections

Every field an underwriter changes is counted against the source that supplied it.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Rating, pricing or quoting the risk.
    • Declining, non-renewing or refusing to quote.
    • Deciding which of two conflicting sources is right.
    • Adding a data source or a variable to underwriting.

  • Automation boundary

    Agent acts unaided

    • ✓Order the sources the underwriting guideline calls for.
    • ✓Resolve records to the entity, address or VIN named.
    • ✓Normalise units, dates and classifications, and cite every field.
    • ✓Name each conflict, stale record and weak match as an open item.

    Write actions run only inside the approval boundaries agreed during implementation. Rating, pricing and any decision adverse to an applicant are not among them, on any tier, in any configuration.

    • Dropping a record the applicant disputes.
    • Ordering reports outside the permitted purpose.
    • Writing the reason given in an adverse notice.
  • Changing match thresholds, source priority or approval rules.

Example output

One submission file, annotated

Every field the agent puts in the file is attached to the source and the date it came from.

Underwriting file output · single submission

Illustrative example
Submission
Commercial property renewal
Risk
One named location
Sources read
Nine, all dated
Conflicts open
Two, both shown
Confidence
93%
Risk decision
None — underwriter's

As received

The submission as the broker sent it, and the sources the underwriting guideline calls for on that class.

Sources cited

  • Prior-carrier loss runs
  • Property survey, dated
  • Public construction record

Why two are open

Two sources give a different roof age. Neither is picked, and neither is dropped.

What the score decides

How much of the file the underwriter checks back at source. Never a reason on a notice.

Action

AcceptCorrectOrder again

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 submission

From the broker, portal or renewal queue

03Provenance

Keep the sources apart, and dated

Every field carries the source it came from and the date that source was current, so a later question about the file has an answer in the file.

01Approved path

Cut the ordering and re-keying

Reports are ordered, records matched and fields normalised before an underwriter opens the submission, so the file starts assembled rather than empty.

02Human review

Show conflicts as conflicts

Where two sources disagree, both readings stay in the file with their dates and go to an underwriter — never settled silently by rule, recency or source rank.

04

Build an evidence trail

Retain the sources ordered, the versions read, the matches made, the conflicts shown and the underwriter's own decision — on both paths.

Integrations

Typical integrations

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

  • Policy admin & workbench

    • Guidewire
    • Duck Creek
    • Sapiens
    • Majesco
    • underwriting workbench

  • Data vendors & bureaus

    • LexisNexis
    • Verisk
    • TransUnion
    • ISO ClaimSearch
    • MVR and CLUE orders

  • Property & vehicle data

    • Property attributes
    • aerial imagery
    • VIN and build data
    • peril scores

Agent

Underwriting data gathering

  • Orders sources
  • Matches and reconciles
  • Cites every field

  • Inspection & documents

    • Loss-control surveys
    • inspections
    • Document management
    • submission files

  • 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 a source and the file

Each control wraps the one inside it. A field clears every layer before it appears in the file, and the risk decision sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReturn assembly to staff if match precision or cohort coverage degrades.Roll back
L5Provenance recordField, source, version and date kept to the standard a notice needs.Record
L4Permitted sourcesOnly sources the guideline and the permitted purpose allow are ordered.Restrict
L3Conflict surfacingSources that disagree are both shown, never reconciled silently.Surface
L2Source currencyEvery field carries an as-of date, and superseded sources are marked.Date
L1Entity-match gateNo record enters the file unless it resolves to the named risk.Match
Model coreFile assembled — every field with the source it came from, its as-of date and any source that reads differently
L1 – L2
Decide whether a record may enter
L3
Keeps a disagreement in front of a person
L4
Holds the file to permitted sources
L5 – L6
Keep the trail and pull automation back

How Nestack evaluates it

Evaluate the file — and what the underwriter had to redo.

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

Surface — the file an underwriter opens

  1. E1Final-output evaluationIs every field in the file attached to the right entity and address?
  2. E2Step-level evaluationWas each source current when it was read, and stamped with that date?
  3. E3Tool evaluationDid it order the right report, on the right risk, under a permitted purpose?
  4. E4Conflict handlingWhere sources disagreed, did the file say so instead of choosing one?
  5. E5Slice evaluationHow do match quality and data coverage change across applicant cohorts?
  6. E6Business outcomeHow much of the file did the underwriter have to gather or correct again?

Floor — a reason that can still be cited if the decision goes against the applicant

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 · Source ordering

    1 mode

    • UW-01

      Proxy variable admitted

      A field that stands in for a protected class enters the file.

    Stage orders

    The reports and records the guideline calls for

  2. 02 · Entity matching

    1 mode

    • UW-02

      Record on the wrong risk

      A loss or violation attached to a similar name or address.

    Stage matches

    Each record to the entity, address or location named

  3. 03 · Reconciliation

    2 modes

    • UW-03

      Conflict settled silently

      Two sources disagree; one is kept, the other never shown.

    • UW-04

      Unit or basis mismatch

      Square feet read as square metres, replacement cost as market value.

    Stage aligns

    Units, dates and classifications across sources

  4. 04 · File / handover

    2 modes

    • UW-05

      Stale record read as current

      A superseded report carried into the file undated.

    • UW-06

      Provenance lost

      The field survives the handover; the source behind it does not.

    Stage hands over

    The assembled file an underwriter works from

  5. 05 · Drift / Version

    1 mode

    • UW-07

      Coverage thins by cohort

      Vendor data is sparser for some applicants than for others.

    Stage tracks

    Sources, vendor models and coverage by cohort

  • Sev-1 · an underwriting decision could rest on it
  • Sev-2 · the file misstates how current it is
  • Sev-3 · a figure is wrong, review catches it
See the complete Insurance failure-mode catalogue

Affected slices

The thin files belong to the same applicants every time

A cohort whose file is reliably thinner is not a data problem alone — it is how a disparity reaches an underwriting decision without anyone choosing it. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Recently moved applicants4.9%3.6×Review
Common and shared surnames3.3%2.4×Review
Rural and unaddressed locations2.5%1.9×Watch
Repeat renewals, unchanged risk1.1%0.8×Normal

Bar: wrong-or-missing-field lift vs. repeat-renewal baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Corrections travel back to the source that sent them

When an underwriter changes a field, the question is which source supplied it and whether the file admitted the doubt. That belongs in the evaluation.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    One cohort's matches get looser, or its files come back thinner than the rest.

  2. 02

    Diagnose

    Which source, which match rule, which reconciliation step, which handover.

  3. 03

    Improve

    Underwriting approves the source, rule or format change, and the version is pinned.

  4. 04

    Verify

    The change is re-asked of held-back submissions and of every corrected field.

  5. 05

    Learn

    The corrected field joins the regression set, and the error goes back to the vendor.

  6. Learn → Detect

    The return edge. Every cycle re-reads coverage by cohort — a file that is reliably thinner for one group of applicants stops the release.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, source and matching work, provenance and testing, evaluation, then production validation and handover.

Workstream

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

  1. 01Workflow discovery and automation-boundary definition.Week 1
  2. 02Source inventory and permitted purpose.Week 1, Week 2
  3. 03Policy-admin and vendor API assessment.Week 1, Week 2
  4. 04Entity and address resolution rules.Week 2, Week 3
  5. 05Unit, date and classification alignment.Week 2, Week 3
  6. 06Conflict surfacing and source-priority rules.Week 3
  7. 07Provenance capture to notice standard.Week 3, Week 4
  8. 08Proxy and disparity testing.Week 4, Week 5
  9. 09Underwriter review workflow and file-format sign-off.Week 4
  10. 10Match, currency and coverage evaluation.Week 4, Week 5
  11. 11Vendor oversight and error feedback.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 source setProductionProduction underwriting integrationAdvancedMulti-line / multi-jurisdiction
Introduced at Pilot
Source ordering and ingestion✓✓✓
Entity and address matching✓✓✓
Field-level provenance✓✓✓
Conflict surfacing✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Normalisation across sources—✓✓
Provenance to adverse-notice standard—✓✓
Cohort-coverage and disparity slices—✓✓
Observability and audit trail—✓✓
Introduced at Advanced
Third-party vendor oversight and audit rights——✓
Multi-line and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the lines and territories in scope, the data sources and vendor contracts in play, policy-admin and workbench integrations, submission volume, provenance requirements 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, classes and territories in scope

    Workflow discovery and automation-boundary definition

    Week 1

  2. 02Your underwriting guideline and the sources it calls for

    Source inventory, permitted purpose and ordering rules

    Week 1

  3. 03Access to policy admin, the workbench and vendor APIs

    Policy-admin, workbench and vendor API integration

    Week 2

  4. 04Vendor contracts, audit rights and data-use terms

    Vendor oversight, audit rights and the error-feedback route

    Week 2

  5. 05Your written rule on what an adverse notice must cite

    Provenance capture to adverse-notice standard

    Week 3

  6. 06Real submissions, including files matched to the wrong risk

    Evaluation suite, regression cases and failure-mode testing

    Week 4

  7. 07Named underwriters and an underwriting technician

    Review workflow, file format and correction tracking

    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. No file reaches an underwriter before week 5, and every correction they make is counted.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Lines in scope, the guideline's sources and permitted purpose

W2Policy-admin, workbench and vendor API integration

W3Entity matching, normalisation and conflict surfacing

W4Provenance capture, evaluation suite and cohort-coverage slices

W5First live files, underwriter corrections and targeted fixes

W6Production validation, vendor error feedback and handover

Reading the band
Underwriter corrections in week 5 are counted on live submissions, not a retrospective sample. Each bar covers its own weeks only.
At the end of W6
Underwriters are working from assembled files, and every field in them can name the source and the date it came from.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Insurance AI agent

Assemble the file before you decide the risk.

Show us the sources your guideline calls for, where they sit, and what an adverse notice has to be able to cite. We'll assemble one submission the way an underwriter would want it, and agree what the file may never decide.

Typical delivery
4–6 weeks
Deployment
Your underwriting stack
Risk decision
An underwriter, always
After launch
Agent Care available

Nestack Agents · Underwriting data gathering

AGT-INS-02 · Agent Care available after launch

Build an underwriting data 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.