Underwriting Assist: A Multi-Agent System

Somya Rai, EXL33:27 · Sept 2025 · 198 views
Thumbnail for Underwriting Assist: A Multi-Agent System Watch on YouTube
TL;DR
  1. 1

    Underwriting Assist uses specialised agents to turn insurance submissions into risk evaluations and quotes, reducing the process from weeks to two days.

  2. 2

    The system uses human review, schema-controlled handoffs, session state, and evidence capture because underwriting decisions require compliance and audit trails.

  3. 3

    Splitting agents by task and using Ray for distributed document extraction helps control hallucinations, runtime, and compute cost.

Summary

Somya Rai describes Underwriting Assist, a multi-agent system for commercial insurance submissions. It reads emails and attachments, extracts information from documents and images, checks for missing details, requests clarification from brokers, evaluates sanctions and location risks, and compares cases with historical underwriting data. Human reviewers remain involved throughout the workflow. Rai says the system reduced underwriting from weeks to two days for a process handling roughly 250 new cases a day and thousands of emails each month. The discussion also covers agent boundaries, memory, and integration. The team split validation and checking after finding that one agent with too many tools produced poor results and hallucinations. LangGraph manages state and sessions, while an NVIDIA configuration exposes agents through REST APIs, MCP servers, and websockets. Maria Zhang explains short-term and persistent memory for restaurant agents. Both speakers discuss cost, provider flexibility, Triton, and Ray-based parallel extraction.

Key ideas
02:34

Underwriting Assist turns a manual insurance process into a supervised agent workflow

Somya Rai explains that commercial underwriting begins with submissions sent by email, often with multi-page documents, images, coordinates, and missing details. Agents parse the material, identify gaps, and send questions back to the broker. Other agents check sanctions, classify the organisation, assess location risks, and compare the case with historical underwriting data. Human reviewers check the information before the system reaches a decision and prepares a quote. Rai says the process moved from weeks to two days.

06:42

Vertical systems need agents with industry-specific tasks and interfaces

Maria Zhang argues that agent systems need to be built around the details of an industry. Restaurant agents must connect to the surrounding restaurant ecosystem, while insurance agents need different domain knowledge and workflows. Within an industry, she prefers agents organised around functions rather than communication channels. An order agent can handle calls, text, web widgets, WhatsApp, and Instagram. A separate agent may handle a different purpose or modality. The platform should account for channel differences without creating one agent for every channel.

09:39

The difficult scale problem is often integration rather than request volume

Rai says underwriting is not operating at an extreme request rate, but the team still processes about 7,000 to 8,000 emails per month. The harder problem was how people used the application and how many tools were assigned to one agent. The team initially combined validation and checking, then found that adding more tools created failure points and led to hallucinated results. They split the work into separate agents. Rai also describes the need to expose the same system through REST APIs, websockets, and other interfaces for reuse across insurers.

11:31

State management lets human reviewers and agents resume interrupted work

Rai says the team built the system in LangGraph because it manages memory, state, and sessions. A reviewer may be unavailable or a session may time out, but the workflow should resume where it stopped instead of starting again. The team later packaged the system on an NVIDIA platform, where a configuration file can expose multiple agents and make them available through REST APIs, MCP servers, or websockets. This separates the agents' work from the way clients connect to them.

15:41

Short-term and persistent memory should have different scopes

Zhang separates current conversational context from persistent memory. A temporary detail may matter in the current conversation without belonging in long-term storage. A food allergy should persist because it is likely to matter months later. She says long-term memory can be shared across agents, while short-term memory should not be shared broadly because the same detail can mean something different in another context. A memory service decides what to retain and what to bring back into a new conversation.

20:16

Compliance requires explicit state, schemas, and evidence

Rai describes two memory levels for underwriting. Working memory holds recent context, while persistent storage records the session ID, inputs, outputs, user responses, and the stage reached in the workflow. Agent-to-agent communication uses event-based, schema-managed messages so information is validated at each handoff. Human feedback can mark an outcome or reasoning path as correct for a given situation. The final negotiation agent prepares the complete file with the evidence behind an acceptance or rejection, which supports audit and compliance requirements.

24:13

Cost control depends on architecture and workload, not only model pricing

Zhang separates the cost of serving a system from the wider cost of selling and operating it. She recommends looking at the full cost rather than focusing only on inference. She also advises against building a private data centre or renting GPUs directly for this kind of system, and recommends architectures that can switch between model and hosting providers. Rai says some fixed costs, such as third-party data access, cannot be removed. The team reduces variable compute cost with Triton and Ray-based distributed extraction.

29:09

Ray reduces document-processing runtime through parallel extraction

Rai says the system uses Ray to parallelise extraction from many incoming emails instead of processing them one at a time. The workload behaves like a distributed, multi-threaded extraction system. Once the documents are extracted, individual agents validate them, check sanctions, and look for risks or red flags. Reducing runtime also reduces GPU hours. Rai says this is not yet the main cost issue at the current scale, but it matters as the same system is used across more insurers.

"We still want to have it much of a deterministic flow considering that there are a lot of compliance and audits happening."22:46
Who should watch
  • You are building an agent workflow for insurance, finance, healthcare, or another regulated process where people must review decisions and retain evidence.
  • Your agent system has too many tools in one place, produces unreliable results, or needs to resume after a human or session drops out.
  • You need to process documents in parallel and keep model, hosting, and interface choices flexible as usage grows.