AI Agents for Insurance

When a first notice of loss arrives, by email, web portal submission, SMS, or phone transcript, the agent extracts the structured FNOL data: policy number, claimant details, date and description of loss, loss location, involved parties, and any supporting documents attached. Extraction runs against the raw inbound content using an LLM with structured output validation, mapping to your ACORD-aligned intake schema or your system's native field structure.

The agent validates the extracted policy number against your policy administration system via API, confirms the policy is in force, and checks whether the reported loss date falls within the coverage period. If validation passes, it creates the claim record in your claims management system with the structured FNOL data pre-populated and attaches the source documents to the claim file. If validation fails, unrecognised policy number, expired policy, or loss date outside the coverage period, the agent flags the exception with the specific reason and routes it to a handler queue for manual review, along with the full inbound content so the handler has everything they need without hunting for it.

Claim routing uses configurable rules: claim type, estimated loss value, line of business, and any triage criteria your operations team defines. The right adjuster queue or team receives the new claim with a structured summary, not a raw email forwarded from an inbox. The full extraction and routing logic is built as a LangGraph directed workflow with explicit state transitions, so every step is logged and the audit trail shows exactly what the agent extracted, what it validated, and what routing decision it made, per your compliance and audit requirements.

Underwriting a new submission requires data from sources that don't send it proactively: CLUE property and auto loss history reports, MVR driving records, credit and financial stability data, property characteristics from geocoded databases, and for commercial lines, D&B or similar company data. Retrieving all of it for a single submission takes time that slows your underwriting queue, especially when the volume of new submissions is high.

The agent accepts a new submission and kicks off parallel data retrieval: CLUE report request via your existing bureau connection or an ACORD-standard API integration, MVR request per driver listed on the submission, credit data pull, and property database query for the risk address. Each retrieval runs asynchronously. Results come back on different timescales, MVRs typically return within seconds to minutes, CLUE within minutes, credit within seconds. The agent collects each result as it arrives and assembles the complete data package.

When all retrievals are complete (or when a configurable timeout is reached for any source that is slow to respond), the agent produces a structured underwriting data package: CLUE loss summary with dates, perils, and reserve amounts; MVR violations and licence status per driver; property characteristics including construction type, year built, and prior loss indicators; and a normalised credit or financial data summary. It attaches this package to the submission record in your underwriting workbench or policy admin system and notifies the assigned underwriter that the data is ready for review. The underwriter starts their assessment with all third-party data already assembled, not waiting for it, not retrieving it manually, not reconciling data from separate exports.

The data retrieval workflow is stateful via LangGraph: each bureau integration is a node, partial failures are handled gracefully (if CLUE returns an error the agent logs it and flags it for manual follow-up rather than stalling), and the full retrieval history is available for audit. MRC-aligned structured output means the data package can be consumed by downstream rating or pricing tools without reformatting.

Between the FNOL and claim resolution, policyholders want to know what is happening with their claim. This is one of the highest-volume, lowest-value contact types in claims operations, the adjuster knows the status but has to stop what they are doing to communicate it. A claims status agent handles this interaction end-to-end.

The agent connects to your claims management system via API and retrieves current claim status on demand: current stage in the workflow, last activity recorded, any outstanding document requests, estimated payment timelines where available, and assigned adjuster contact information for escalation. It surfaces this through whatever contact channel the policyholder uses, a web portal widget, SMS, email reply, or voice IVR integration depending on your channel mix.

For inbound status enquiries (email or message saying "what is the status of my claim?"), the agent extracts the claim reference or policy number from the inbound message, queries the claims system, and sends a structured status response: what stage the claim is at, what happened most recently, what, if anything, is needed from the policyholder, and when the next update is expected. The response uses plain language generated by the LLM from the structured claims data, not a template that reads like an automated message.

For proactive updates, the agent monitors the claims workflow for defined trigger events, adjuster assignment, document received, inspection scheduled, payment authorised, payment sent, and sends a proactive notification to the policyholder at each trigger without requiring adjuster action. The agent escalates to a human only when the policyholder's inbound message indicates they are dissatisfied with the status or when they explicitly ask to speak to someone, routing those contacts to the right queue with the full conversation history attached.

Policy renewals that are not actively managed lapse, the policyholder either forgets to renew, doesn't receive a clear renewal prompt, or gets a renewal pack they don't understand and doesn't act on. A renewal reminder agent drives renewal contact across the pre-renewal window without requiring manual outreach scheduling.

The agent queries your policy administration system for policies approaching renewal within a configurable window (typically 60, 30, and 14 days before expiry). For each policy in the renewal window, it retrieves the current premium, any mid-term changes, renewal terms offered, and the policyholder's preferred contact channel. It generates personalised renewal communications, structured around the specific policy, current coverage, renewal premium, and any changes, using the LLM with a prompt template your marketing and compliance team approves before deployment. Generated content passes through a structured output validation step confirming required regulatory disclosure elements are present before any message is sent.

Outreach runs across channels in preference order: email, SMS, and portal notification. Response tracking monitors whether the policyholder has opened the renewal pack, clicked through to the renewal portal, or completed the renewal. Non-responders move to the next outreach step at the configured interval. Policyholders who request changes to coverage or raise a question about their renewal terms are flagged to a broker or account manager with the full conversation thread, rather than the agent attempting to handle coverage change requests itself, that decision stays with a human.

Policies that lapse despite outreach are flagged with the full outreach history: what was sent, when, which channel, and what response (if any) was received. This gives your operations team the audit trail they need for compliance and the context they need for any reinstatement conversation with the policyholder.

Claims fraud costs UK insurers over £1 billion annually in detected fraud alone, and SIU teams are already stretched reviewing the volume of claims they receive. A fraud signal flagging agent surfaces anomaly signals on new claims so SIU reviewers spend their time on the claims most likely to warrant investigation, not on random sampling.

The agent runs on each new claim as it is created. It checks a configurable set of fraud indicators against the claim data: policy age relative to first claim (new policy, high-value claim shortly after inception), reported loss timing patterns (claim filed on weekend or late evening, loss occurring just before renewal), claimant history from CLUE (prior claims frequency and types), third-party corroboration gaps (no police report for a reported theft, no repair estimate for a vehicle claim above a set threshold), and for property claims, catastrophe event correlation (loss reported during a declared event but outside the affected geography).

Each signal check produces a binary flag and a signal description. The agent aggregates the flags into a risk score using configurable weighting per signal type, producing a low / medium / high risk classification. High-risk claims are routed directly to the SIU queue with the full signal summary attached. Medium-risk claims are flagged in the adjuster's claim view with the signal list so the adjuster can apply judgment without the claim being pulled from their queue. Low-risk claims proceed normally. The SIU team reviews only the cases the agent has flagged, not every claim in the portfolio.

The signal logic is transparent: the agent explains why a claim is flagged (specific signals, not a black-box score), which means the SIU reviewer starts their investigation knowing exactly what to look for. The workflow is built as a LangGraph directed graph with the signal checks as parallel nodes, so new signal types can be added without restructuring the workflow. Human escalation checkpoints are mandatory, the agent flags, it does not decide.

Subrogation recovery is money that insurers are entitled to but frequently leave on the table because identifying which closed or settling claims have a viable subrogation right requires reviewing loss circumstances, third-party involvement, and liability indicators that aren't always captured in a way that surfaces the opportunity. A subrogation identification agent reviews claims at defined points in the lifecycle and flags cases with recovery potential.

The agent reviews the claim file at two trigger points: when liability indicators suggest a third party may be responsible (reported at FNOL or during adjustment), and when a claim reaches settlement or payment authorisation. At each trigger, the agent assesses the claim data: loss description and cause, third-party information captured in the FNOL or during adjustment, police or incident reports attached to the file, property damage assessments with causation noted, and any recorded statements. Using the LLM to analyse the unstructured narrative alongside the structured claim fields, it identifies whether the facts of loss indicate a third party's negligence or liability contributed to the loss.

Claims where the analysis supports a potential subrogation right are flagged with a structured summary: the basis for the subrogation claim (the specific facts of loss and liability indicators), the applicable third party identified, any documentation already in the file that supports recovery, and documentation gaps that the adjuster should pursue before closing the claim. The flag routes to your subrogation unit or the handling adjuster, depending on your workflow configuration.

The agent does not determine that subrogation exists, that is a legal and factual determination that a qualified professional makes. It identifies which claims in your portfolio warrant that professional review, so your subrogation unit focuses on the cases most likely to produce recovery rather than reviewing closed files manually or relying on adjuster initiative to flag opportunities.