Inside the Intake Triage Agent: Six P&C Scenarios Showing the First Decision InsightUW Makes on Every Inbound

Every inbound to a commercial P&C carrier — broker email, portal POST, API call, bot upload — has to be classified before anything else can happen. Is it a new submission? A renewal? A follow-up on something already in flight? A question, an OOO bounce, a marketing email, spam? Get this wrong and the rest of the cascade does the wrong work on the wrong record. The Intake Triage Agent is the first agent every inbound touches, and it makes that decision in seconds — with six possible verdicts and a confidence score on each.

The architecture in one picture

The Intake Triage Agent runs as a five-band pipeline. Inbound channels at the top are every way a submission can enter the platform. Ingress guards + dedup reject spoofed senders, scan for viruses, and collapse re-receipts of the same Message-ID instead of spawning duplicate submissions. Three parallel classification passes — LLM, deterministic rules, thread / submission matching — produce independent signals that merge into a single verdict. The decision band at the bottom picks one of six paths, and every path writes an audit event so downstream agents (and auditors) can reconstruct what happened.

Reading the five bands

The six verdicts in one paragraph each

NEW SUBMISSION — intent is "submission," confidence ≥ 0.7, no existing thread match. A UWSubmissionQueue row is created (status=pending_extraction), a UW is assigned via FIFO or skills-based routing, and the cascade proceeds to document extraction → clearance → ... About 50–60% of inbound on most commercial books.

RENEWAL — intent is "renewal" and a prior policy is found via broker + insured + LOB lookup. The prior_policy_guid is linked and the Renewal Pull-Forward Agent is invoked to clone SOV / endorsements / T&Cs. Cascade proceeds with the renewal flag set. About 25–35% of inbound on a mature book.

FOLLOW-UP — thread match found via In-Reply-To header, References chain, or fuzzy subject + sender against open submissions. The email is attached to the existing UWSubmissionQueue row, the assigned UW is notified, and any closed tasks linked to that submission auto-reopen. No new cascade. About 10–15% of inbound.

UA REVIEW — confidence is below 0.7 OR the LLM and deterministic passes disagree. Routed to the UA queue with the per-pass reasoning surfaced ("LLM said submission 0.62; deterministic mailbox hint was property; thread match found nothing"). Cascade halts; the UA confirms intent (with optional LOB override) and the cascade resumes from the corrected verdict. ~3–8% of inbound.

SPAM — spam confidence ≥ 90% (deterministic denylist hit, or LLM spam classifier ≥ 0.90). Quarantined into the compliance review bucket. No submission row created. No downstream agents invoked. The audit event still fires so the volume can be reported. ~2–5% of inbound.

DROP — non-submission email that isn't spam. Out-of-office auto-replies, marketing pitches from aggregators, vendor sales emails, delivery-receipt bounces. Logged with the reason but no submission record, no cascade. Distinct from spam because these are legitimate emails that simply aren't underwriting work. ~5–10% of inbound.

Six P&C scenarios

Each scenario below exercises one of the six verdict paths with a representative P&C line and a representative trigger. The "What the UW sees" line is the actual outcome surfaced on the InsightUW Live Console and the workbench.

How the three classification passes combine

The merge precedence is explicit — it's not "average the scores." Each pass has a different role and a different way of winning:

1. Thread match wins over LLM intent. If the email is in a reply chain to an existing submission (In-Reply-To header, References chain, or fuzzy subject + sender match), it's a follow-up — even if the LLM thinks the subject reads like a new submission. Brokers occasionally reply with edited subjects that look like new submissions but are really updates.
2. Deterministic spam wins over LLM. If the sender domain is denylisted or DKIM fails or the subject matches a known marketing template, the LLM doesn't get a chance to overrule. This also short-circuits cost — no LLM tokens burned on obvious spam.
3. Otherwise, LLM intent + LOB are used. Deterministic mailbox→LOB hint is a tiebreaker when the LLM's LOB confidence is below 0.5.
4. Confidence below 0.7 routes to UA regardless of intent. The agent refuses to commit when the model isn't sure — a false NEW SUBMISSION wastes downstream cycles, a false FOLLOW-UP attaches to the wrong record.

What the agent reads — and what it doesn't

The Intake Triage Agent has a deliberately narrow scope. Its job is classify and route — nothing more. Specifically:

Every additional responsibility added to intake would slow it down and make retries harder. Keeping it narrow lets the rest of the pipeline run unblocked, and it makes intake the most reliable agent in the cascade — failure modes are well understood and recovery is fast.

Per-LOB rush detection at intake

The agent decides rush vs normal at intake — before extraction runs. This is what makes the rush SLA timer start at the right minute, not three steps later when someone notices.

A rush hit sets UWSubmissionQueue.is_rush = true and overrides the FIFO queue position. The workbench surfaces it with a red rush pill at the top of the list, and the SLA clock starts ticking at the moment the email landed — not when someone happened to open it.

Tunables a carrier owns

Everything the agent uses to decide is admin-configurable per tenant and per LOB. Engineering doesn't touch a thing when classification thresholds shift or new mailboxes are added:

• Spam confidence threshold (default 0.90) — higher means fewer false-positive spam classifications
• Low-confidence threshold (default 0.70) — below this, routes to UA regardless of intent
• Dedup window (default 30 days) — re-receipt of same Message-ID collapses to existing email
• Rush keyword list per LOB — triggers is_rush=true and overrides FIFO; admin-managed per tenant
• Mailbox → LOB mapping per mailbox
• Sender allowlist / denylist per tenant — hard pass or fail before LLM runs
• Subject regex catalog per tenant — hard signals for NEW / RENEWAL / QUOTE / DECLINE prefixes
• FIFO vs skills-based UW assignment per team
• LLM model + region per tenant — Bedrock Claude default; Azure OpenAI failover
• LLM cost cap per inbound (default $0.05) — hard ceiling; classification falls back to deterministic-only beyond

Why this matters for P&C

Manual triage on a commercial P&C inbox takes 5–15 minutes per email and is the single most boring part of an Ops analyst's day. Multiply by 200–800 inbound per day per team and you have one full-time role that's just sorting email. Done by humans, this work is uneven (spam misses, follow-ups attached to the wrong record, wrong-LOB routing), slow (rush submissions sit for hours before someone notices), and invisible to the audit trail (the decision lives in someone's head).

What's Next

This post covered the Intake Triage Agent end-to-end. Subsequent posts will go deeper on:

• The Document Extraction Agent — the multi-step pipeline that runs after intake: classify each attachment, extract per-doc-type with state and LOB overlays, cross-validate fields across attachments + email body
• The Routing Service — how the broker + insured prior-bind match works, why the 90-day window matters, and how it powers BOR conflict detection downstream
• The Follow-up Communication Agent — how cadence reminders pause on broker OOO detection and resume when the broker is back

Want to see the Intake Triage Agent classify a real broker email end-to-end — including a UA REVIEW with the LLM-vs-deterministic disagreement surfaced — in a 45-minute working session against your inbound? Request a demo.