Best practices for agentic underwriting and claims data: a field guide for underwriting and claims data teams
How underwriting and claims data teams move their data back office to agents, practice by practice: the state of the space, the old world and the new, what the agents do step by step, how to set autonomy, who owns what, and how to start.
Delegated authority and enrichment have multiplied insurance data sources.
Mapping and tying them out is repeatable work agents should run.
The state of the space
Teams that own policy, quote, exposure, bordereaux and claims data and the products built on it: rating inputs, portfolio views, claims analytics and reinsurance submissions. Titles include Lead PM for MGA Data, Product Manager (Data), Claims Data Lead and Head of Underwriting Data.
Insurers now take more business through delegated authority and enrich more decisions with third-party, geospatial and catastrophe data. Each partner and vendor adds a format, and every month-end depends on mapping them correctly. Agents can make that mapping, tying out and enrichment continuous, so underwriting and claims teams get data on day one.
The old world
A bordereau changes shape; premium loads short; actuarial finds it on day 8; the pack goes out late.
It is rarely one failure. Three patterns repeat:
- •The bordereau that changed shape. A coverholder reorders columns; written premium loads short.
- •Exposure enrichment for cat modeling. Geocodes and hazard scores arrive late before a renewal season.
- •One claims number. Claims and finance report different incurred.
The new world
The layout change was mapped on arrival, premium tied to control totals and the refresh approved by mid-morning on day 5.
Here is that new world as a chain of hand-offs between agents:
These are the impact metrics we move:
- •Bordereau change mapped: from about 4 days to 15-30 min
- •Premium tied to controls: from about 2 days to 8-15 min
- •Enrichment rerun: from about a day to ~1 h
The rest of this report walks through the 5 practices that make that possible. At a glance:
The practices, one by one
1. Tie every partner file to control totals
Partner files are the top source of month-end surprises.
Why it is harder than it looks. Each coverholder interprets the bordereau template differently.
The old world. Found in the pack.
The new world. run_quality_check against control totals.
What the agents do, step by step:
- 1.The Data Ingestion agent calls
get_connector_statusand lands each bordereau. - 2.The Quality Monitoring agent calls
run_quality_checkand ties to control totals. - 3.The Autonomous Data-Conductor calls
request_governance_reviewand holds actuarial refreshes.
In practice. Shortfall caught on day 5.
What to measure. Partner files tied on arrival.
2. Map layouts automatically
Layouts change monthly.
Why it is harder than it looks. Layouts drift a little every month.
The old world. Manual mapping.
The new world. Schema Evolution maps changes.
What the agents do, step by step:
- 1.The Schema Evolution agent calls
detect_schema_changeand spots moved and renamed fields. - 2.The Schema Evolution agent calls
generate_migrationand writes the mapping. - 3.The Pipeline Building agent calls
sandbox_testand tests it.
In practice. Reordered columns mapped in minutes.
What to measure. Hours of mapping per month.
Practices like these compound. Across the routine work they cover:
3. Keep enrichment on an SLA
Cat models need complete exposure.
Why it is harder than it looks. Enrichment vendors deliver on their schedule, not renewal season's.
The old world. Late batches.
The new world. set_sla and reruns.
What the agents do, step by step:
- 1.The Quality Monitoring agent calls
set_slaand sets freshness. - 2.The Incident Debugging agent calls
execute_backfilland reruns gaps. - 3.The Quality Monitoring agent calls
get_quality_scoreand reports coverage.
In practice. Complete exposure before renewals.
What to measure. Enrichment SLA met.
4. Govern claims definitions
Incurred means different things.
Why it is harder than it looks. Claims and finance cut the same claims at different moments.
The old world. Two numbers.
The new world. Context Wizard governs definitions.
What the agents do, step by step:
- 1.The Data Context & Catalog agent calls
define_business_ruleand defines incurred and paid. - 2.The Quality Monitoring agent calls
run_quality_checkand ties daily. - 3.The Incident Debugging agent calls
get_root_causeand explains gaps.
In practice. One incurred.
What to measure. Claims discrepancies.
Autonomy where work is reversible, a named approver where it matters:
5. Hold pricing and reserves for people
These carry accountability.
Why it is harder than it looks. Reserves and pricing carry regulatory accountability.
The old world. Mixed.
The new world. L2 with named approvers.
What the agents do, step by step:
- 1.The Data Context & Catalog agent calls
blast_radius_analysisand flags reserve inputs. - 2.The Autonomous Data-Conductor calls
request_governance_reviewand holds at L2. - 3.The Data Access & Governance agent calls
generate_audit_reportand records it.
In practice. Every change approved.
What to measure. Changes with approver.
Designing the autonomy ladder
Autonomy is set per task class, not per tool. This is where we would set each class for a mature deployment, and why:
| Task class | Closed autonomously | Escalated | Handled by a person | Where we set it | Why |
|---|---|---|---|---|---|
| Catalog upkeep | 88% | 8% | 4% | L4 once the receipts are clean | The work is reversible and repeatable |
| Bordereaux mapping | 70% | 20% | 10% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Enrichment freshness | 80% | 14% | 6% | L4 once the receipts are clean | The work is reversible and repeatable |
| Quality rules | 60% | 28% | 12% | L3: acts and keeps a rollback point | Most cases are routine; the rest escalate with evidence |
| Pricing and reserve inputs | 0% | 86% | 14% | L2: always proposed to a named approver | The number carries accountability outside the data team |
The operating model: who owns what
Agents change who does the work, not who is accountable for it:
| Role | Owns | What the agents take off their plate |
|---|---|---|
| Head of Underwriting and Claims Data | Standards, autonomy levels per domain and which domain goes next | Assembling status, chasing owners, keeping the catalog current |
| Domain owners and approvers | Pricing inputs, reserves and financial numbers | Preparing the diff, blast radius and rollback plan for every proposal |
| Data engineers | Reviewing agent proposals and building new data products | Every bordereau is mapped and tied to control totals on arrival; exposure enrichment runs on freshness SLAs |
The swarm behind the practices
| Agent | What it does for you | Tools it calls |
|---|---|---|
| Data Ingestion | Bordereaux and partner files, profiled on arrival | get_connector_status, trigger_airflow_dag, register_kafka_schema |
| Schema Evolution | Maps partner layouts | detect_schema_change, validate_schema_compatibility, generate_migration, rollback_migration |
| Quality Monitoring | Ties premium and claims to control totals | set_sla, run_quality_check, get_anomalies, create_quality_tests_for_pipeline |
| Pipeline Building | Rating factors and enrichment pipelines | generate_pipeline, validate_pipeline, sandbox_test, deploy_pipeline |
| Data Context & Catalog | Governed premium, exposure and claims definitions | trace_cross_platform_lineage, blast_radius_analysis, define_business_rule, generate_documentation |
| Data Access & Governance | Partner and analyst access | provision_access, check_policy, request_governance_review, generate_audit_report |
Data Context Wizard keeps one governed graph of definitions, lineage and owners that every agent and person answers from. Autonomous Data-Conductor runs each job from detection to a verified result. Spellbook Data Catalog is where your team approves, audits and rolls back, and asks questions in plain English.
What disappears
- •Month-end bordereaux scrambles.
- •Short premium in the pack.
- •Late enrichment before renewals.
- •Two claims numbers.
- •Quarter-long rating projects.
The magic is not any single agent. It is that the back office keeps running: bad data is caught where it enters, every new table gets quality rules and documentation without anyone writing them, access follows policy, fixes are verified before anyone opens a dashboard, and every action leaves a signed receipt.
A product manager's scorecard
| Metric | How to read it |
|---|---|
| Partner files tied on arrival | Baseline it in the first week of the pilot; review it monthly. |
| Mapping hours per month | Baseline it in the first week of the pilot; review it monthly. |
| Enrichment SLA | Baseline it in the first week of the pilot; review it monthly. |
| Claims discrepancies | Baseline it in the first week of the pilot; review it monthly. |
| Weeks to a new rating factor | Baseline it in the first week of the pilot; review it monthly. |
Where this goes next
Carriers will treat every partner feed as a contract enforced on arrival, close the month on schedule every month and test new rating factors in weeks. Underwriting data teams will spend their time on pricing and portfolio insight.
The climb: from assisted to autonomous to agentic
Our thesis is that the data platform climbs the way analytics did, in stages, and that the hard part of data work was never knowing what to do but doing it. For underwriting and claims data teams, the climb looks like this:
- •Assisted. Agents work alongside your team. They read the whole stack, show what needs doing and propose every fix with a receipt; pricing inputs, reserves and financial numbers always go to a named approver.
- •Autonomous, under your governance. Routine work runs on its own: every bordereau is mapped and tied to control totals on arrival, exposure enrichment runs on freshness SLAs, and claims are tied between claims and finance daily. Your team governs the agents instead of doing the upkeep.
- •The agentic enterprise. Carriers will treat every partner feed as a contract enforced on arrival, close the month on schedule every month and test new rating factors in weeks. Underwriting data teams will spend their time on pricing and portfolio insight.
You choose the altitude, every step is visible and reversible, and the pilot below is the first rung.
The pilot: how underwriting and claims data teams start
The pilot is how your team proves the value on its own data before committing.
- •What we connect. Snowflake, Databricks or BigQuery; policy admin and claims systems (Guidewire, Duck Creek); partner portals and SFTP; geospatial and cat vendors; dbt; Airflow, over MCP, inside your infrastructure. Nothing migrates.
- •Scope. Bordereaux tie-out for 10 coverholders at L2.
- •First week. Agents run at L1 across the scoped domain. They map every pipeline, definition and lineage path and show the fixes they would have made, with receipts, so your team sees the value before anything changes.
- •By week two. Every bordereau is mapped and tied to control totals on arrival and exposure enrichment runs on freshness SLAs start running on reversible work. Pricing inputs, reserves and financial numbers stay at L2 with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Bordereau change mapped: from about 4 days to 15-30 min
- •Premium tied to controls: from about 2 days to 8-15 min
- •Enrichment rerun: from about a day to ~1 h
- •the share of catalog upkeep closed autonomously, targeting 88% as the deployment matures
- •What you decide. Whether to expand to the next domain. The pilot fee is credited in full against the first year.
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
The pilot is the start of a longer curve:
Read the full playbook: Data Workers for underwriting and claims data teams