2 ready-to-build workflows

AI agent workflows for Insurance broking

Chase renewals, collect policy docs, take first-notice claims and answer coverage questions — with every recommendation and coverage position gated to a licensed broker.

Each recipe below is expressed only in VegaDūta's real workflow building blocks — Trigger, Agent, Knowledge, Condition, Approval, Output, Tool (MCP), Voice, Device, Loop, Code and Parallel — so it maps 1:1 to something you can assemble in the Workflow designer. Consequential actions always pass a human Approval step.

1. Renewal reminders + quote-comparison intake

Policies lapse because nobody had time to flag the renewal, then a broker manually emails the client for updated details, re-keys the requirement, and rebuilds a quote comparison by hand for the tenth time this month.

Trigger: Webhook (scheduled, renewal run)

How the workflow runs

  1. Trigger

    Renewal run. A scheduled Webhook trigger evaluates policies nearing expiry each morning (the book is fed from your broking / policy-admin system via Webhook — no first-party connector).

  2. Loop

    Per client due for renewal. A Loop node iterates the due list so each client gets a personal, timely reminder rather than a batch blast.

  3. Output

    Remind + request updated details. An Output node reaches the client on WhatsApp/Email with the renewal date and asks for the updated details and policy documents needed to requote.

  4. Agent

    Build the quote-comparison intake. An Agent node structures the client's updated requirement and the collected documents, and assembles the insurer quotes into a clean side-by-side comparison — as information, not a recommendation.

  5. Condition

    Completeness gate before quoting. A Condition node won't proceed to a comparison until every mandatory detail and document is present, so quotes aren't built on gaps.

  6. Approval

    Broker signs off before it reaches the client. An Approval node routes the comparison and any recommendation to a licensed broker — advice and any bound quote are never sent by the agent. This is the non-negotiable control.

Channels & connectors

  • Webhook
  • Loop
  • WhatsApp
  • Email
  • Knowledge base
  • Approval / HITL

Outcome

Every renewal is flagged and chased on time with the requote intake assembled automatically; brokers spend their time on the advice and the comparison, not on reminders and re-keying — and no recommendation goes out unreviewed.

Why it helps

Removes the manual renewal chase and the copy-paste rebuild of comparisons, while the advice and any bound quote stay a licensed-broker decision.

Build spec

1 agent — 1 intake/comparison agent; the reminder loop is a workflow node and the advice decision is the broker's Approval step.

System prompt (paste-ready)

You are an insurance-broking assistant. For a client due for renewal, collect the updated requirement and documents, and assemble the insurer quotes you are given into a neutral side-by-side comparison as strict JSON {client_ref, requirement, quotes[{insurer, premium, sum_insured, key_terms}], missing[]}. Present facts only — do NOT recommend an insurer, rank 'best value', or state anything is the right cover; that is the broker's decision. Copy premiums and terms exactly from the quotes provided; never estimate a premium. If a mandatory detail is missing, list it in missing[] and do not proceed.

MCP connectors

  • Broking / policy-admin system — inbound via Webhook trigger (no first-party connector)
  • Insurer quote data — via a Tool (MCP) node where an API exists, otherwise entered by the broker

Built-in tools

  • knowledge_search (product rules + client policy record)
  • document parsing (policy schedules/proposals)

Guardrails

  • No advice from the agent — it assembles a neutral comparison; recommending, ranking or binding a quote is blocked and routed to the broker Approval node
  • Completeness gate — the Condition node prevents a comparison being built on missing details or documents
  • Exact premiums only — the agent copies quoted figures and never estimates or 'adjusts' a premium

Output & delivery

Renewal run → Loop reminds each due client and collects the requirement + docs → the agent builds a neutral quote comparison → Condition enforces the completeness gate → the licensed broker reviews and adds the recommendation at the Approval node before anything reaches the client.

2. Claim first-notice hand-off + coverage Q&A

A client messages to report a loss and to ask 'am I even covered for this?'; today a broker captures the notice by hand, reads the policy wording to answer, then emails the insurer to open the claim — slow, and coverage answers vary by whoever picks it up.

Trigger: WhatsApp / Call / Webhook (loss reported)

How the workflow runs

  1. Trigger

    Loss reported. A WhatsApp, Call or Webhook trigger opens the claim in the client's own words and language.

  2. Agent

    Capture the structured first-notice. An Agent node collects policy no., date and time of loss, description, third parties and severity into a clean, consistent first-notice-of-loss record.

  3. Knowledge

    Coverage Q&A from the policy wording. A Knowledge node answers 'is this covered?' strictly from the client's policy wording — with citations, framed as indicative only, never a confirmed coverage position.

  4. Condition

    Completeness gate. A Condition node won't advance the notice until the mandatory details and any required photos/documents are captured and legible.

  5. Approval

    Broker confirms the coverage position. An Approval node hands the complete notice and the indicative coverage read to a licensed broker to confirm before hand-off — a coverage position is never asserted by the agent. This is the control.

  6. Tool (MCP)

    Hand off to the insurer. On approval, a Tool (MCP) node lodges the first-notice into the insurer's portal/claims system — reached via MCP or an outbound Webhook, not a native connector.

Channels & connectors

  • WhatsApp
  • Voice / Call
  • Sarvam (multilingual)
  • Knowledge base
  • Approval / HITL
  • Tool (MCP → insurer portal)

Outcome

Losses are captured complete and consistent the moment they're reported, clients get an instant indicative coverage read, and the notice reaches the insurer fast — while the coverage position stays a licensed-broker decision.

Why it helps

Removes the manual capture and the days before a claim is lodged, and makes coverage answers consistent and cited, without letting the agent make the coverage call.

Build spec

1 agent — 1 FNOL-capture agent; the coverage read is Knowledge-grounded and the coverage position is the broker's Approval step.

System prompt (paste-ready)

You are an insurance first-notice-of-loss assistant. Capture the loss into strict JSON {policy_no, loss_datetime, description, third_parties[], severity, documents[]}. Then answer any coverage question ONLY from the client's policy wording in Knowledge, cite the clause, and state clearly that this is indicative and subject to broker/insurer confirmation. Never confirm that a loss is covered or will be paid, never quote a settlement figure, and never advise the client to admit or deny liability. If the wording is silent or unclear, say so and route to the broker.

MCP connectors

  • Insurer portal / claims system — via a Tool (MCP) node or outbound Webhook (no first-party connector)
  • Policy wordings — held in the Knowledge base

Built-in tools

  • knowledge_search (policy wording + schedule)
  • document parsing (photos / loss evidence)

Guardrails

  • Indicative-only coverage — the agent answers from the cited policy wording and explicitly flags it as not a confirmed position; a confirmed coverage position requires the broker Approval node
  • Completeness gate — the Condition node blocks hand-off until mandatory details and evidence are captured and legible
  • No liability or settlement statements — the agent never confirms payment, quotes a figure, or advises admitting/denying liability; those route to the broker

Output & delivery

Loss reported in-channel → the agent captures a structured FNOL and gives a cited, indicative coverage read → Condition enforces the completeness gate → the licensed broker confirms the coverage position at the Approval node → a Tool node lodges the notice into the insurer's portal via MCP, with the transcript and evidence attached.

Related industries

Build one of these in minutes

The sandbox gives you a live agent workspace — no account, no card. Or head back to the full catalogue and compare patterns across every industry.

Try this in the sandbox — no signupBrowse all industries
See how VegaDūta compares to n8n, Dify and BotpressWhy VegaDūta's architectureEstimate your WhatsApp API costs