A P&C carrier, component by component: where the agents sit and who watches them

A property and casualty carrier is not one system. It is nine or ten distinct functions, each with its own queue, its own authority, its own regulator and its own definition of a bad day. When you put AI agents into that operating model, the question is not "where does the AI go" — it is which seat does it occupy, what is it allowed to do from that seat, and who is watching.

This is the reference architecture we run at Vsure: the components of the carrier, the agent workstations that sit on them, and which InsightLense view each team actually opens. It is the post to forward to the colleague who asks "yes, but how would this work here".

The components

Every carrier has these, whether or not they are separate systems. The names differ; the responsibilities do not.

Notice that every failure mode in the right-hand column is a money or contract failure, not a software failure. That is the whole reason agent observability in this industry cannot stop at the model call: nobody at a carrier has ever been asked to explain a token count.

The workstation

The unit that makes this tractable is not "an agent". It is a workstation — a named seat in the operating model, which a human or an agent occupies.

This framing matters more than it sounds, for three reasons.

It is how carriers already think. Desks, seats, books of business, referral authority — the vocabulary already exists and it already has an authority model attached. You are populating an existing structure, not inventing one.

It makes agent and human interchangeable at the boundary. The same seat can be staffed by a person on Monday and an agent on Tuesday without any permission change, because the authority belongs to the seat.

It gives observability a stable subject. "What did CL-DOKAFOR do" is a question about an actor who may be replaced. "What happened at the adjuster workstation this quarter" survives staff changes, model upgrades and prompt rewrites — which is what an auditor is actually asking.

Where the workstations sit

flowchart TB
    subgraph front["Front office"]
        D["Distribution"] --> CL["Clearance
and intake"]
        CL --> UW["Underwriting"]
        UW --> PA["Policy
administration"]
    end

    subgraph back["Servicing"]
        PA --> BA["Billing and
premium audit"]
        CLM["Claims"] --> REC["Recovery"]
        CLM --> CED["Ceded
reinsurance"]
    end

    subgraph control["Control functions"]
        ACT["Actuarial"]
        FIN["Finance and
compliance"]
    end

    PA --> CLM
    BA --> FIN
    CED --> FIN
    CLM --> ACT

    LENSE["InsightLense — runs, authority decisions, business events, scores
one thread per policy, claim or submission"]

    front -.-> LENSE
    back -.-> LENSE
    control -.-> LENSE

    style LENSE fill:#14162b,stroke:#4b34e0,color:#fff
    style front fill:#efecfe,stroke:#4b34e0
    style back fill:#e2f5f9,stroke:#0e97b0
    style control fill:#fbede3,stroke:#b4531b

Here is the staffing, workstation by workstation. Authority levels are the ones we actually run; yours will differ, and the levels themselves are the interesting conversation.

The last row is the important one. The referral desk is a workstation like any other — it just happens to be staffed by a person, and it appears in the same records as the rest.

One piece of work, crossing five components

A submission becomes a policy becomes a claim becomes a cession. Each hand-off crosses a component boundary, and each boundary is where threading either holds or breaks.

sequenceDiagram
    autonumber
    participant BD as Broker desk
    participant UD as Underwriting desk
    participant RD as Referral desk
(human)
    participant AD as Adjuster desk
    participant CD as Ceded desk

    BD->>UD: submission VS-2027-0832950
    UD->>UD: appetite, rate, quote
    UD->>RD: rate change +31% — refer
    RD-->>UD: approved with note
    UD->>UD: bind → policy POL-2027-4471
    Note over UD,AD: same thread continues
onto the policy
    AD->>AD: FNOL → claim CLM-2027-0418
    AD->>RD: settle $58,000 — above L2
    RD-->>AD: approved
    AD->>CD: loss exceeds retention
    CD->>CD: allocate to treaty layers
    Note over BD,CD: five components, two humans,
one continuous record

Who watches what

This is the part that decides whether an observability layer gets used or becomes a dashboard nobody opens. Different teams want genuinely different things from the same underlying records.

Nine teams, one store. The reason this works is that all nine questions are filters over the same four record types described in the data model post — nobody is running a separate pipeline, and nobody's number disagrees with anybody else's.

What this looks like in InsightLense

Two views, from opposite ends of the building, over identical underlying data.

An underwriting manager reads that top-down. An auditor opens the same data from the other end, filtered to a single policy, and gets a chronology instead:

A worked day: one alert, six roles

Everything above is structure. This is what it looks like when something goes wrong on a Tuesday — one real incident, followed from the first monitor through to the compliance sign-off six weeks later. Each stage shows the view that person actually opens.

08:40 — Pipeline monitoring

The operations lead starts on the pipeline board. Three flows carry essentially all of the carrier's work: submissions in, claims through, renewals out. Each is a queue with a throughput, a cycle time and a referral rate, and the job at 08:40 is to spot which one is not behaving like yesterday.

This is the failure mode that operational dashboards are worst at. Throughput up, cycle time down, error rate flat — every conventional signal says the renewals desk had a good night. The only thing that says otherwise is a control that has stopped producing records.

08:41 — The alert

The rule that fired is not a threshold on a business metric. It is a coverage rule: for a control that is supposed to gate an action, compare the number of actions that should have tripped it against the number of authority records actually written.

A control that stops firing produces no errors, no failures and no latency. The only evidence is an absence, and absences need a rule that is looking for them.

08:52 — Ops triage: business problem or system problem?

The first question is not "what broke". It is whether the rate changes were genuinely above the threshold — because if the rating engine had started producing wrong numbers, that is a completely different incident with a much larger blast radius.

The ops lead opens one affected policy as a thread. This is the moment the three record types earn their keep: the business event says the rate change was +31%, and the authority section is empty.

That settles the triage in about ten minutes. The rating is right, the agent behaved correctly, and the defect is in the software between the two. Ops pauses the renewals desk, writes the exposure into the incident, and hands it to engineering.

09:20 — The developer

Engineering picks it up with the thread already narrowed to one policy and one second. The run view shows what the agent did; the question is what the product did between step 7 and step 8.

From there it is ordinary debugging. The developer pulls the control coverage view, sees that renewal_rate_change is the only control in the book with a coverage gap, and traces it to a refactor: an early return added for a different case moved the enforcement branch into a helper that the renewal path no longer calls. The fix is one branch, plus making the decision a required argument of issue_renewal so a future refactor cannot silently drop it again. That reasoning is set out in full in the control that was computed but never enforced.

Fix ships at 14:10. The coverage alert clears on the next window. Total elapsed: five and a half hours, of which about forty minutes was investigation — the rest was review and deploy.

The hand-off, end to end

flowchart LR
    M["08:40 Ops
pipeline board
renewals anomalous"] --> A["08:41 Alert
control coverage
$4.12M exposure"]
    A --> T["08:52 Ops triage
thread view
rating fine, control missing"]
    T --> D["09:20 Developer
run view
step 7 never invoked"]
    D --> F["14:10 Fix shipped
decision now required"]
    F --> AU["Week 6 Auditor
exception register
enumerate the 14"]
    AU --> C["Week 6 Compliance
filed-rate check
attestation"]

    style M fill:#efecfe,stroke:#4b34e0
    style A fill:#fbede3,stroke:#b4531b
    style T fill:#efecfe,stroke:#4b34e0
    style D fill:#e2f5f9,stroke:#0e97b0
    style F fill:#e2f5f9,stroke:#0e97b0
    style AU fill:#fbede3,stroke:#b4531b
    style C fill:#fbede3,stroke:#b4531b

Week 6 — The auditor

Quarterly control testing. The auditor is not interested in the outage; they are interested in the population. Fourteen policies bound without a required referral is a control exception, and the test is whether the carrier can enumerate the affected population exactly, say what was done about each one, and demonstrate that the control now works.

None of that requires engineering involvement, because the ledger is append-only and the window is bounded by two timestamps.

The auditor's three questions and where each is answered:

Week 6 — Compliance

Compliance asks a question neither ops nor the auditor asked, and it is the one with regulatory teeth: were any of those fourteen policies bound outside filed rates? A missing internal referral is an internal control failure. A policy bound outside the filed rate is a regulatory matter with a reporting obligation attached.

That distinction is worth dwelling on, because it is the kind of question that otherwise takes three weeks and a spreadsheet. Compliance needed to join fourteen policies to their state filings and confirm each bound premium fell inside the filed range. Because the business events carry the premium, the state and the actor kind, and because the population was already defined by the incident, it is a view rather than a project.

The attestation compliance files says four things: the population was fourteen, all fourteen were within filed rates, one was re-rated on internal grounds, and the control has produced 41 correct referrals since remediation. Every one of those is a link into the ledger rather than an assertion.

What each team took from the same records

Six roles, six different views, one set of records. Nobody exported anything for anybody else, nobody wrote a hand-off document, and the auditor six weeks later read the same rows the operations lead read on the Tuesday morning.

The measure of an observability layer is not the incident it helps you fix. It is whether the person who asks about it six weeks later has to ask you.

Rolling this out

Nobody adopts ten workstations at once. The order that worked for us, and the reasoning:

• Instrument before you automate. Put the correlation id and the business ledger on the components you already have, staffed by the people already there. You will find defects immediately — six of the ten we found at Vsure were in code that predated any agent.
• Start at a low-consequence desk. Clearance and FNOL are ideal: high volume, structured, cheap to be wrong, noticed immediately. Not claims settlement, however tempting the savings look.
• Staff the referral desk with a person from day one. An agent workstation without a human above it is not an autonomy design, it is an unguarded write.
• Set limits from cost-of-being-wrong, not model confidence. The autonomy ladder post has the four-quadrant version of this.
• Watch escalation and approval rate together. A desk escalating a lot into a referral desk that approves everything is a limit in the wrong place, and it is the most common misconfiguration we see.

The thing to take away

The interesting question in insurance AI is no longer whether an agent can rate a risk or reserve a claim. It can. The question is whether, eighteen months later, you can sit in front of an examiner and show which seat did it, what that seat was permitted to do, which human signed the exception and what the number was before it changed.

That is not a model capability. It is an architecture decision, and it is made — or lost — at the point where the agent writes to the system of record.