AI Agents for Insurance: Claims, Underwriting & Governance

AI agents for insurance are autonomous systems that read documents, validate them against policy rules, update core systems, and escalate the edge cases to a human. A claims-intake agent reads a first notice of loss, pulls the policy, checks coverage, opens the claim, and routes anything ambiguous to an adjuster. Unlike a chatbot that answers a question and stops, an agent runs a multi-step workflow across the systems a carrier already operates. In a regulated industry, the point is bounded autonomy: deterministic rule enforcement, human escalation, and an audit trail that holds up in an exam.

Why insurance is at the front of the AI agent wave

Insurance runs on documents and legacy systems. A claim arrives as a PDF or an email, gets keyed into a policy and claims platform that may be decades old, and moves through a process where every step has to be defensible. Loss ratios are under pressure, intake queues are deep, and the manual work is exactly the kind an agent handles well. The catch is that regulators now expect to see how an automated decision was made. The NAIC's 2024 Model Bulletin on the use of AI asks carriers to govern AI systems with documented programs and oversight, and the EU AI Act classifies AI used in life and health insurance underwriting and pricing as high-risk, with the heavier obligations that label carries. Note the scope: that high-risk classification targets life and health underwriting, not property and casualty across the board. The takeaway for a carrier is plain. The workflows worth automating are the rule-heavy, high-volume ones, and they only work if the agent runs the same way every time and logs what it did.

Key takeaways: • Insurance agents work best with bounded autonomy: they act within defined rules and escalate the rest. • Deterministic execution is the requirement. The same input has to produce the same decision path every run. • Governance comes first. Scoped credentials, human-in-the-loop gates, and an immutable audit log are not optional in a regulated carrier. • Start with one high-volume, rule-heavy workflow like FNOL intake, not a customer-facing chatbot.

The top AI agent use cases for insurance

How do AI agents work in insurance?

Every one of these runs the same loop. The agent ingests unstructured input, extracts and structures it, validates it against the policy rules, takes a bounded action, and logs the result to an audit trail. The autonomy is capped on purpose. Anything ambiguous, high-value, or low-confidence routes to a person.

Claims-intake agent

Ingests a first notice of loss from email or PDF, extracts the entities, validates them against policy rules, updates the claims database, and escalates exceptions to an adjuster. Connected to the inbox, a document parser, the policy database, and a claims system like Guidewire or Duck Creek through its API, with adjuster alerts in Slack or Teams. Outcome: faster claim cycle time and less manual keying.

Submission-triage agent

Reads broker submissions, compares them against the underwriting appetite, enriches the risk data, and routes the submission to the right underwriter. Connected to email, the CRM, a risk-data service, and the underwriter workbench. Outcome: less time spent sorting submissions that fall outside appetite.

Policy-QA agent

Answers coverage questions with clause-level citations and refuses to speculate when the policy does not say. Connected to a document store such as SharePoint or Google Drive, the policy admin system, and a chat front end. The refusal to guess is the point in a regulated setting, where a confidently wrong coverage answer is a liability.

Fraud-flag agent

Cross-references a claim against prior history and external signals and flags anomalies for investigation. Connected to the claims database, the SIU system, and third-party data. It flags for a human investigator. It does not decide fraud.

Underwriting-prep agent

Gathers application data, fills the gaps, runs compliance checks, and drafts a quote summary for the underwriter. Connected to the CRM, the underwriting guidelines database, and the rating engine. The underwriter still owns the decision.

What are the benefits?

The wins are cycle-time reduction, consistency, and auditability, and more adjuster and underwriter leverage on the work that needs judgment. The benefit that matters most in a regulated carrier is the audit trail. A deterministic workflow produces the same decision path every time, which is what an exam asks to see.

The reason these need to be built carefully shows up when you compare the architecture options.

• Handles actions
• • Pure chatbot: No
  • RAG-only agent: Limited
  • Deterministic agentic app: Yes
• Repeatability on rerun
• • Pure chatbot: No
  • RAG-only agent: No
  • Deterministic agentic app: Yes
• Audit log
• • Pure chatbot: No
  • RAG-only agent: Partial
  • Deterministic agentic app: Yes, at the point of action
• State persistence
• • Pure chatbot: No
  • RAG-only agent: No
  • Deterministic agentic app: Yes, in a managed database
• Human escalation
• • Pure chatbot: Manual
  • RAG-only agent: Ad hoc
  • Deterministic agentic app: Built into the workflow
• Legacy integration
• • Pure chatbot: No
  • RAG-only agent: Limited
  • Deterministic agentic app: Yes, via scoped connectors

Where to start

If you are running your first insurance agent, pick one high-volume, rule-heavy workflow. FNOL intake is the ideal first target. Define the escalation rules before you automate anything, because the escalations are where the agent earns trust: what confidence is too low, what dollar amount needs an adjuster, what coverage situations always go to a person. Run it as a deterministic pilot and measure two things, cycle time and exception rate. Do not start with a customer-facing chatbot that can invent coverage answers, because an agent that hallucinates a coverage position is a regulatory problem, not a productivity gain. Vendors like Stack AI, Salesforce Agentforce, and Sutherland are building in this space, and their published numbers are worth reading as claims to verify rather than as benchmarks.

Build this in Major

Here is the FNOL workflow as a concrete build: the FNOL-Intake Agent for Commercial Property in Major.

The reason to build it as a Major app is that the model designs the workflow once, and the app runs deterministically from then on. The agent does not re-interpret the policy on every loss report. It executes the validated rule set, writes state to a managed database, and emits an immutable log, so internal audit and a regulator see the same decision path every time. In a regulated vertical, an agent that re-reasons every run is a compliance liability, not a feature. For the fundamentals, what an AI agent actually is and build an AI agent cover the basics.

The agent reads from the FNOL inbox through a Gmail or Outlook connector and the policy administration database through a Postgres or Snowflake connector, and it writes to the claims system through a REST API. Its permissions are narrow by design: read-only on the policy database, write access only to the claims database and the dedicated inbox, and no broad retention of data for model training.

1. Ingest. A scheduled poll or webhook picks up a new email in the dedicated FNOL inbox.
2. Extract. A document-parser step pulls the date, location, policy number, loss description, and attached photos.
3. Validate. The agent queries the policy administration database to confirm an active policy, the coverage type, and the deductible, then runs the deterministic rules, for example that water damage in a flood zone requires an adjuster assignment.
4. Act and route. It creates the claim record, sets a reserve flag for adjuster review, sends an acknowledgment email, and posts a summary to the adjuster Slack channel. If extraction confidence is below 0.85, the policy is not found, coverage is ambiguous, or the claim exceeds the $25,000 threshold, it routes to a senior adjuster with full context and blocks auto-advance.
5. Audit. Every parse, validation result, rule fired, and escalation is logged with the system or user identity to an audit log table.

Governance is built into that flow rather than bolted on. The credential proxy enforces scoped secrets per connector, a human-in-the-loop gate sits on every escalation, and the observability and audit logs plus scoped credentials and runtime security make each run reconstructable. The agent does not adjudicate a complex or litigated claim, it does not set the reserve amount, and it is never the final authority on a coverage dispute. It opens, validates, and routes. A licensed adjuster decides.

A governance checklist before you ship

Before an insurance agent runs in production, the governance work has to be in place. The NAIC Model Bulletin points carriers at a written program and documented oversight, and a practical checklist looks like this.

• A written AI Systems Program that defines how agents are built, tested, and monitored.
• Board or senior-management oversight of that program.
• Human-in-the-loop triggers for low-confidence, high-value, and ambiguous cases.
• Third-party and vendor management for any model or data provider in the loop.
• Documentation ready for a market-conduct exam, showing the decision path for any claim.

This is the enterprise AI governance thread that turns an agent from a pilot into something that passes audit.

If your FNOL queue is still keyed in by hand and your audit trail lives in screenshots, the first agent to build is the one that reads each loss report, checks the policy, opens the claim, and routes the exceptions to an adjuster. Describe the rules and the escalation thresholds, and Major builds the FNOL-Intake app that runs them deterministically, scoped to your claims system, with an immutable log on every action. Get started on Major and build your claims-intake agent.

Related articles

• AI Customer Service Agents: Use Cases and How to Build One
• AI Agents for Marketing: Use Cases, Reporting, and Campaign Ops
• AI Agents for HR: 7 Use Cases That Actually Ship