The AI-First P&C Insurance Stack: Submission to FNOL to Analytics on One Platform

The problem: three desks, three systems, AI bolted onto each

Follow one commercial account through a typical carrier and you cross at least four systems that never see each other's work.

The submission arrives as a broker email with an ACORD form, a loss run and a schedule of values. Someone rekeys it into a clearance tool, then into a rater, then into the policy admin system. The underwriter researches the insured in a browser, writes up a referral in an email, and waits.

Eight months later the insured has a loss. The claims system knows the policy number but not the conversation that shaped the terms. Did the underwriter exclude that location? Was a sublimit negotiated? The adjuster finds out by reading PDFs.

The paid loss reaches ceded reinsurance at quarter end, when somebody exports a bordereau. Nobody tells the renewal underwriter that this account's loss ratio just tripled. They find out from a dashboard, if they look.

The last five years added AI to each of those desks separately: an extraction tool in intake, a triage score in claims, a chatbot over the data warehouse. Each made its own desk faster. None of them closed the gaps between desks, and most added a new one, a model output nobody can trace. Ask the model risk team which version of which prompt produced the reserve recommendation on claim 4471. Ask what the model was allowed to do and who approved what it suggested. In most carriers the honest answer is that nobody knows.

The stack at a glance

The products fall into four layers. The workbenches are where the work happens. The shared platform is the set of packages every workbench is built on, so a reserve approval in claims and a referral in underwriting behave the same way. The data and intelligence layer answers questions and supplies signals. The AI operations layer governs the models.

Seven design rules that make it AI-first, not AI-added

"AI-first" is easy to claim. These are the rules the products actually hold to, and they are what the use cases below depend on.

1. Agents reason, the record decides what is true

Each agent gathers facts from the record and asks the model to reason over them. It answers in a fixed shape that cites its facts by id. The model is on by default in every workbench. When no model is configured, the deterministic rule-based finding still stands on its own, so the desk keeps working.

flowchart TB
    A["Gather facts
each with its source"] --> B["Reason with the model
fixed answer shape"]
    B --> C{"Every number
in the facts?"}
    C -- yes --> D["Prepared decision
with citations"]
    C -- no --> E["Model answer rejected
rule finding stands"]
    E --> D
    

2. Numbers come from engines, never from the model

The cession engine computes what a layer owes. Reserves, recoveries and premiums come from their own engines and ledgers. The model explains a figure and may propose one, but a number in its answer that is not in the facts it was given fails the check, and the answer is thrown away. The rule is simple to state and it is the one that matters most to an actuary.

3. Autonomy is a dial, set per agent, action and line

There are four levels. At L1 the agent drafts and a person does the work. At L2 it asks first: it prepares the decision and a person accepts it. At L3 it acts and tells, with a window to pull the action back. At L4 it acts on its own.

A tenant ceiling, L2 by default, caps every agent whatever its record. Promotion is recommended when people agree with an agent at least 90% of the time over 50 answers, and a manager has to accept it. Demotion below 70% is immediate. A kill switch drops an agent to Draft everywhere at once.

4. Authority belongs to the product, not the agent

Agents act through the same APIs as people, and the product decides what is allowed. An agent that wants to settle above a limit does not decide that it may. The workbench refuses and raises an approval to someone who holds the authority. That makes the control structural rather than a matter of hoping the prompt holds.

5. Every decision is a record

Whether a person or an agent made it, a decision records the subject, the money at stake, the evidence with its sources, the recommendation and what accepting it does. When a message is involved, the record holds the message too. The answer (accept, change, reject or ask) is evidence about the agent, and it feeds the agreement rate the dial reads.

6. Nothing leaves unseen

Broker emails, panel notices, cash calls, claimant letters and regulator reports are written held. They leave only when a person releases them, or an agent does at L3 or above, inside its window. Outside production every send is a dry run.

7. One thread of evidence

Each run records the identity it ran as, the level it held and what capped it, the prompt version, the model, tokens, cost and trace. InsightLense joins that to the business event it caused through correlation and causation ids. "Which run, under which prompt version, moved this reserve?" becomes one query.

The shared platform underneath

The workbenches look and behave alike because they are built from the same packages, not because a style guide asked them to:

• People, teams and authority. One model of members, teams, personas, books of business and authority grants. "My book" means the same thing in underwriting and claims, and an authority limit is checked the same way everywhere.
• Rules Studio. One rule engine. A rule is published, tested against a real submission or claim to see what it would change, and rolled back if needed. Appetite, knockouts, referral triggers, payment holds and recovery spotting are all rules you can read.
• The agent runtime. Plan, gather, reason and prepare steps, with model budgets, retries and circuit breakers, PII redaction before a prompt leaves the boundary, idempotency, a grounding check, and a registry the agent catalogue pages read from.
• The copilot. A tool-calling assistant that reads the record and cites each answer. If it cannot find something it says "not in the record" rather than guessing, and its suggested actions are links into the workspace, never side effects.
• The home. Every workbench opens on the same five slots: What needs me, What agents did, My book, Insights and Signals. Each is filled for the persona looking at it.

Use case A: a commercial submission, from broker email to bound policy

The first walk-through is new business on a specialty commercial account: a directors-and-officers renewal-style submission that lands in a monitored underwriting mailbox with an application, financial statements and a loss run. Figures in this section are illustrative.

flowchart TB
    subgraph T["Today"]
        direction TB
        t1["Rekey ACORD
and loss run"] --> t2["Clearance in
another tool"]
        t2 --> t3["Research in
a browser"] --> t4["Rater
spreadsheet"]
        t4 --> t5["Referral by email,
wait days"] --> t6["Reinsurance learns
at the bordereau"]
    end
    subgraph N["With the stack"]
        direction TB
        n1["Xtract: fields
with confidence"] --> n2["Analyze: clear, appetite,
enrich, brief, price"]
        n2 --> n3{"Within
authority?"}
        n3 -- no --> n5["Referral prepared
for the manager"]
        n3 -- yes --> n4["Underwriter accepts
or changes"]
        n5 --> n4
        n4 --> n6["Quote, bind,
PAS via contract"] --> n7["policy.bound
to InsightCede"]
    end
    

The walk-through

1. Intake and extraction. The mailbox monitor attaches the email to a new or existing submission. InsightXtract turns the ACORD application, the loss run and the schedule into fields, each with a confidence score and the page it came from. A reviewer approves or corrects low-confidence fields; nothing is guessed silently. Missing items (no audited financials, say) become a tracked checklist, and the follow-up agent drafts the chaser to the broker in the underwriter's own writing style, held for review.
2. Clearance and conflicts. The clearance step checks sanctions across the insured, broker and principals, capacity and territory rules. The broker-of-record agent looks for an active policy, a recent submission or an open BOR on the same insured. A high-severity conflict holds the submission before anyone spends time on it.
3. Appetite and research. Studio rules score appetite and run knock-outs. Enrichment pulls the insured's signals from InsightPulse: news, leadership changes, capital events, ratings. It adds claims-driven signals from the carrier's own book: open severity, frequency anomalies, litigation, loss ratio. Each signal carries its source, and the brief agent writes the risk summary from those facts.
4. Price. The line's published rating model produces an indicated premium. The pricing agent explains it against the loss history and peer benchmarks, and the indicated figure comes from the model, not from the language model.
5. Decide and gate. The pipeline lands at a decision: the rules recommend referring, quoting or declining, with the checks that passed and those that need attention. If the premium or limit exceeds the underwriter's authority, the gate parks the submission and prepares the referral. The question for the manager is written out ("approve the referral, or decline it?") with the recommendation and what the agents already did.
6. The person decides. The underwriter or the manager accepts, changes the price (an authority-checked override), rejects or asks. The answer becomes part of the decision record and part of the agent's agreement rate.
7. Quote, bind, issue. The quote is drafted from the decided price, with forms and subjectivities. Bind blockers are aggregated: an open referral blocks a bind, and that is enforced, not displayed. The policy admin message goes out through an integration contract. Guidewire and Duck Creek adapters are stand-ins until connected to a carrier's instance.
8. Tell reinsurance. The bind writes a policy.bound event in the same database transaction as the policy. InsightCede picks it up idempotently and cedes it against the programme in force.

sequenceDiagram
    autonumber
    participant B as Broker
    participant U as UW agents
    participant X as Xtract
    participant P as Pulse
    participant W as Underwriter
    participant M as Manager
    participant C as Cede
    B->>U: Email and documents
    U->>X: Extract
    X-->>U: Fields, confidence
    U->>U: Clear, appetite
    U->>P: Signals?
    P-->>U: News, ratings
    U->>U: Brief and price
    U->>W: Refer: above authority
    W->>M: Referral prepared
    M-->>U: Accept
    W->>U: Quote and bind
    U->>B: Binder (released)
    U->>C: policy.bound
    

What the person still decides

• Whether to write the risk at all, and on what terms. The agents never quote above an underwriter's authority, and at the default ceiling they never quote without someone accepting.
• Price changes, which are authority-checked overrides with a reason on the record.
• Anything the extraction scored low or the clearance flagged high.
• Every message to the broker, at L2. A carrier can let the broker chase loop act and tell at L3 once the agreement rate earns it.

Edge cases the design handles

• A new document arrives after Analyze ran. The pipeline re-extracts and re-decides, and the gate runs again. A checkpoint answered on stale facts is not silently kept.
• The broker of record changes mid-flight. The BOR lifecycle runs its grace period and notifications, and finalisation is dispatched to the policy system.
• The model is unavailable. Every step still produces its rule-based finding, the decision record says the model was not reached, and the evidence stands on its own.
• Renewals. The same pipeline runs on the renewal horizon at 120, 90, 60 and 30 days. Rate change and exposure change are shown separately, because a premium can rise 50% while the rate rises far more when a limit drops.

Use case B: first notice of loss to resolution

The second walk-through is the claim. Take a commercial property water-damage loss on a policy InsightUW bound. It turns out to be a covered loss with a third party at fault, and it lands in a week when a storm is also generating claims. Figures in this section are illustrative.

flowchart TB
    subgraph T["Today"]
        direction TB
        t1["Notice keyed
by hand"] --> t2["Policy PDFs,
terms guessed"]
        t2 --> t3["Reserve by feel,
stair-steps"] --> t4["Letters from scratch,
clocks in a sheet"]
        t4 --> t5["Subrogation
missed"] --> t6["Reinsurer and renewal
told late or never"]
    end
    subgraph N["With the stack"]
        direction TB
        n1["Xtract and
intake agent"] --> n2["Coverage at
the loss date"]
        n2 --> n3["Reserve by
component"] --> n4{"Within
authority?"}
        n4 -- no --> n5["Supervisor
approval"]
        n4 -- yes --> n6["Letters, clocks,
payments with holds"]
        n5 --> n6
        n6 --> n7["Recovery spotted,
events to Cede, UW, Pulse"]
    end
    

The walk-through

1. Notice to claim. The notice and its documents are read by InsightXtract, and the intake agent checks completeness, looks for a duplicate and matches the policy. Converting the notice to a claim is a person's click. From then on the agents run on their own whenever something changes (a document, a reserve, a payment request, a suit), debounced so a burst of changes produces one run.
2. Coverage at the loss date. The coverage agent asks InsightUW for the policy as it stood on the date of loss: forms, limits, deductibles, endorsements. It takes a position per coverage and drafts the reservation-of-rights or denial letter when the facts call for one. If the forms are not on the feed, it says so and the position stays open, rather than inventing terms.
3. Reserve with a basis. The reserving agent recommends a reserve by component (indemnity, expense) from the claim's facts, the line's closed claims and the settlement evaluation. It flags stair-stepping, where a reserve keeps creeping up in small moves that hide the true exposure. Above the adjuster's authority, the change becomes a supervisor approval with the history attached.
4. Fraud and SIU. The fraud agent explains each indicator: late reporting, a pattern of prior similar claims, inconsistent statements. It prepares the SIU referral, and it never files one. An investigator accepts the case and works the plan.
5. Letters and clocks. The correspondence agent tracks what is due under which state's rules (acknowledge, decide, pay) and drafts the letters, held. The clock is on the screen, not in a spreadsheet.
6. Payments that stop when they should. A payment request is checked against authority and against the payment-control rules. A 1099-reportable payee with no W-9 on file is held, and the hold names its rule and who may release it. When a release must exist before a settlement payment, the payment waits for the release.
7. Recovery. Recovery rules spot subrogation, salvage and deductible recoveries from the claim's facts, such as a collision with an identified adverse party or a vendor at fault. The subrogation agent works out the statute deadline and prepares the demand. The demand is prepared in the workbench; sending it to the other carrier is a person's decision.
8. Catastrophe tagging. When a storm is declared, its claims are tagged to the event and adjusters can be surged. The event's aggregate position is recorded for reinsurance as one cat.event_loss event, carrying the catastrophe code that the treaty's event definition joins on.
9. Reinsurance and renewal hear about it. Every reserve movement, payment, recovery, closure and large-loss flag is written as a claim event in the same transaction as the money. InsightCede cedes it, InsightUW folds it into the insured's loss history and renewal signals, and InsightPulse updates the claim and insured 360s. Each amount is the claim's cumulative position, never a delta, so a missed or replayed event cannot double-count.
10. Close. The closure agent works the checklist: reserves released to zero, features closed, no approval or payment pending, diaries cleared. It drafts the closing letter. A claim cannot close carrying live reserve.

sequenceDiagram
    autonumber
    participant I as Insured
    participant CW as CW agents
    participant UW as UW
    participant A as Adjuster
    participant S as Supervisor
    participant CE as Cede
    I->>CW: Notice and documents
    A->>CW: Convert to claim
    CW->>UW: Policy at loss date?
    UW-->>CW: Forms, limits
    CW->>A: Coverage, reserve prepared
    A->>CW: Accept, change reserve
    CW->>S: Approval: above authority
    S-->>CW: Approve
    CW-->>CE: reserve_movement
    CW-->>UW: loss history
    A->>CW: Request payment
    CW->>A: Held: no W-9
    A->>CW: W-9 in, release
    CW-->>CE: payment_issued
    CW->>A: Subrogation demand prepared
    

What the person still decides

• The coverage position and every letter that states it.
• Reserve changes, at the default ceiling, and always above the adjuster's authority.
• Whether to refer to SIU, and the investigation itself.
• Settlement offers. The evaluation is recorded before the offer, and agreement is re-checked against authority.
• Releasing held payments, and sending any demand, filing or report outside the carrier.

Edge cases the design handles

• Late notice. The intake agent flags the reporting lag, the coverage agent considers prejudice, and the fraud indicator is explained rather than scored silently.
• Policy forms missing from the feed. The coverage position stays open with the question stated. The agent's confidence is shown, and nothing is presumed covered or excluded.
• A storm surge. Claims tagged to the event roll up to one event loss for reinsurance, and the event's IA coverage and incurred by state are on one page.
• A void or a reopen. Because events carry cumulative positions, a voided payment or a reopened claim corrects the reinsurance and renewal views without manual reconciliation.
• A recovery received. It is recorded once in claims and flows to reinsurance as a recovery, so net is computed in one place: InsightCede.

On the reinsurance side

InsightCede receives the policy and claim events and its engine computes what each contract owes. When a large loss erodes a layer, its agents draft the notice to the panel, the cash call and the reinstatement premium notice. All of them are held until a person releases them. At period close they strike the bordereaux and draft statements, and later they chase recoverables by age. InsightCede never writes back into underwriting or claims. Net is derived there and published as a read, because the moment two systems both own "net", they disagree.

Use case C: analytics across underwriting, claims and reinsurance

The third walk-through is the question a chief underwriting officer or claims executive actually asks on a Monday. For example: "Which segments drove our loss ratio up this year, how much of it is retained net of reinsurance, and which brokers placed those accounts?" That question crosses three systems of record. Here is how the stack answers it without a week of spreadsheet work.

flowchart TB
    Q["Question in plain English"] --> G["Glossary and agreed metrics
applied: loss ratio, net, segment"]
    G --> S["SQL written, validated against
the catalog, run read-only"]
    S --> R["Narrative written from the rows"]
    R --> V{"Every figure matched
to a row?"}
    V -- yes --> P["Answer with SQL, rows, sources
publishable as insight or data API"]
    V -- no --> F["Misses listed, publish
must be insisted on"]
    P --> H["Homes, dashboards,
agents and copilots read it"]
    

How the pieces divide the work

• InsightCompose holds the governed definitions: your glossary aligned to the schema, and agreed metrics such as loss ratio with their grain, default filters and the traps they are computed wrong by. Its insight agent plans the query steps, runs them and writes the narrative. A checker that uses no model then matches every figure against the rows the sentence names. The page shows the count, and the misses are listed. A published insight becomes an address (/v1/insights/<slug>/results) that answers at whatever scope the caller is entitled to: the whole book, one broker, one region.
• InsightAsk answers across what the carrier keeps beyond the warehouse, such as underwriting guidelines, claim files, treaty wordings and SharePoint folders. A fact question goes to typed tables with templated SQL. A document question goes to quote-verified passages. If neither has the answer, it refuses. InsightAsk SQL brings the same discipline to a lakehouse: it validates every table and column against the catalog, builds filters only from values that exist, takes join paths from a profiled relationship graph, and runs a review pass for fan-out before it runs anything.
• InsightPulse adds the outside-in view: insured and broker 360s, ratings, news and market signals, joined to the carrier's own claims.
• The workbenches publish their own portfolio and metrics pages: underwriting hit ratio and days to quote, claims cycle time and reserve adequacy, ceded loss ratio and recoverables. The figures are computed by their engines, so analytics never recomputes "net" or "incurred" in a different way.

sequenceDiagram
    autonumber
    participant E as Executive
    participant CO as Compose
    participant WH as Warehouse
    participant AK as Ask
    participant LE as Lense
    E->>CO: What drove loss ratio, net?
    CO->>CO: Glossary, agreed metric
    CO->>WH: Validated read-only SQL
    WH-->>CO: Rows
    CO->>CO: Check figures vs rows
    CO-->>E: Answer, SQL, rows
    E->>AK: What do guidelines say?
    AK-->>E: Quoted passages
    E->>CO: Publish to Monday pack
    CO-->>LE: Run, prompt version, cost
    

Questions this answers, and what each answer cites

Homes: analytics that finds the person

Most analytics waits to be opened. The persona home turns it around. A claims executive's home opens with what needs them, what the agents did overnight, their book's tiles, the insights ranked by how much each is worth to them, and signals from InsightPulse. An underwriter's home leads with their referrals and renewals. Host applications ask InsightCompose for a home with the persona, the person and an optional focus, and the API key's grant decides which collections and scopes come back.

Governance and model risk: Prompts and Lense

An insurer's model risk team asks the same questions about every AI system. What did it do? Under which version? Was it allowed to? Who approved it? Did it get better or worse? The stack answers with two products and a clear boundary between them: InsightPrompts owns intent, InsightLense owns what occurred.

flowchart LR
    P["InsightPrompts
draft, review, approved,
certified version"] -- "used by" --> R["Agent run
prompt id and version
on every trace"]
    R --> L["InsightLense
run trace, authority
decision, business event"]
    L -. "performance split
by version" .-> P
    

• Prompts are versioned assets. Every prompt an agent uses lives in InsightPrompts, with its lifecycle, approvals, a test bench, LLM-judge scoring against a rubric you wrote, and champion–challenger experiments. A new version is promoted only after it beats the incumbent.
• Every run is traced with its prompt version. InsightLense keeps the run (each step, with tokens, latency and cost), the authority decision (allowed, refused, escalated or downgraded, and who it went to), and the business event (old value, new value, and whether an agent, a person or a system made the change). Performance is reported split by prompt version, never pooled across versions, because a pooled average cannot tell you whether the version you promoted did better.
• One thread across products. A correlation id minted when an account first exists follows it through underwriting, claims and reinsurance. A causation id links each ledger entry to the run that produced it. "Everything that happened to this account, in order, by machines and people" is one query.
• Cost is attributed to the work. Model spend is recorded per business object, such as a submission, a claim or a statement, not only per month, because an agent decides for itself how many calls a task takes. Each agent also has a budget, and a circuit breaker stops it when the model misbehaves.
• PII stays in. Personal data is redacted before a prompt leaves the boundary. Models run in the carrier's own cloud account, for example Claude on Amazon Bedrock, and the products run in the carrier's environment.
• Tests never call a real model. The test suites guard against it, so a CI run cannot leak data to a model or run up a bill.

Deployment and integration

• Your cloud, your data. The products deploy into the carrier's AWS account as containers (ECS templates ship with the code) on PostgreSQL, one schema per product. Models are reached through the carrier's own model account, with Amazon Bedrock as the default for Claude. Nothing is copied to a vendor's environment.
• Sign-in and roles. A shared identity layer covers the carrier's single sign-on, server-derived roles and per-tenant isolation. Agents carry their own signed identity and act on behalf of the person who started the run, so the audit trail separates the two.
• Contracts, not shared tables. Products integrate through versioned contracts. The claim event contract, for example, names the event types each consumer receives, and the same contract file is tested in the producer and in every consumer, so a change that breaks a consumer fails a build rather than a bordereau. Events are written through an outbox in the same transaction as the business change, published with retries, signed, and received idempotently.
• The policy admin system. Quote, bind, endorsement and note messages to the PAS go through an integration contract with a message log. The shipped Guidewire and Duck Creek adapters are stand-ins until a carrier connects its instance. Data APIs from InsightCompose give downstream systems governed reads without a model in the path.
• Documents. InsightXtract pipelines for ACORD forms, loss runs, schedules and broker emails sit inside the same perimeter and hand fields to the workbenches with their confidence and page references.

An adoption path: one workbench, then connect

Nobody replaces underwriting, claims and reinsurance at once, and the stack does not ask you to. Each workbench stands alone against your existing systems. The connections add value as each one arrives.

flowchart TB
    S1["Land one workbench
agents at L1 Draft, dry-run sends"] --> S2["Measure agreement
per agent, action and line"]
    S2 --> S3["Move proven actions to L2
people accept, the record learns"]
    S3 --> S4["Connect the second workbench
events through the outbox"]
    S4 --> S5["Add Cede and analytics
net, homes, governed insights"]
    S5 --> S6["Promote to L3 where
evidence supports it"]
    

1. Start where the pain is. For many specialty carriers that is submission intake and triage (InsightUW with InsightXtract). For others it is claims leakage and cycle time (InsightCW). For reinsurance-heavy books it is the ceded desk (InsightCede).
2. Run at L1 first. Agents draft and people work as they do today, with the drafts beside them. Every send is a dry run. Within weeks you have the agreement rate per agent, per action and per line, which is the evidence the rest depends on.
3. Move to L2 where agreement is high. People accept prepared decisions instead of doing the work from a blank page. The dial and the kill switch stay with the carrier's managers.
4. Connect. Turning on the event contracts between two workbenches is configuration and secrets, not a project. Policy at the loss date flows to claims, claim events flow to renewal and reinsurance.
5. Add the analytics and governance layers once there is a shared record worth asking about. Prompts and Lense are usually wanted by model risk from day one.

FAQ

The products

The bottom line

The value of AI in a carrier does not come from any single model output. It comes from three things together. Work is prepared before a person reaches it. The person decides inside authority the system enforces. And the facts flow onward to the next desk without anyone rekeying them. Build those three into the platform once and each new agent inherits them, and each workbench makes the next one more useful.

Bolt AI onto each desk separately and you get faster islands, with the gaps between them untouched and no way to prove what the models did.