Home Use Cases Work Insights About Contact
Back to Our Work

How a Growth-Stage Insurance Company Built an Inquiries Agent That Answers from the Policy Clause

Operations1
Open the walkthrough

Six-Step AI Workflow with Human Oversight

Each step shows the workspace, what the AI completed, and what still needs human review.

Steps 4 and 6 need a person. Step 4 is waiting for approval right now. Click it to open the full walkthrough.

Estimates are directional and based on stated assumptions. All names, organizations, and identifying details have been anonymized in accordance with our confidentiality agreements.

The Transformation

How a Growth-Stage Insurance Company Built an Inquiries Agent That Answers from the Policy Clause

Before
A person used to read every message and look the customer up by hand.
A person used to read each message and decide which pile it went in.
A person used to write every reply by hand, between calls.
A person used to write up every ticket after the conversation ended.
After
every message tied to its customer before anything answers it
every question named, and the angry ones already on their way to a person
the reply drafted with a source on every sentence, or declined
the short queue only your team can answer, briefed
the conversation closed only when it settled, and the record filed
Executive Summary

Answers the customer questions that used to queue for a person, at any hour, and never sends a sentence it cannot point to a policy clause or a record for. Written for an org where the promise is the point: every reply carries its sources, every handoff arrives briefed, and the only thing left for your team is the customer no document can settle. Six stations, run as a loop: what station 6 learns from this month's handoffs is what station 3 answers with next month.

What Was Broken

A person used to read every message and look the customer up by hand
A person used to read each message and decide which pile it went in
A person used to write every reply by hand, between calls
The real cost
A person used to write up every ticket after the conversation ended.

What We Built

Six stations and 13 subagents. Each subagent carries its own tasks and its own refusal.

A4
Channel Watch
Watch the chat widget, the support mailbox and the SMS line around the clock
A3
Identity Match
Match the sender to a policy record by policy number, email or phone
A3
Intent Reading
Classify each message as claim status, billing, coverage question, policy change or cancellation
A3
Tone Screen
Read the tone of every open conversation across all of its turns
A4
Knowledge Search
Search the policy wordings, the help articles and past settled tickets for each question
A2
Reply Writing
Draft the reply from the retrieved passages and nothing else
A3
Answer Check
Check every sentence of the draft against the passage it cites
A3
Handoff Routing
Route each handoff to the rep who owns that kind of question: claims, billing or retention
A2
Handoff Brief
Summarize the conversation in one line a rep can decide from
A3
Resolution Check
Ask each customer whether the answer settled it, on the channel they wrote in
A4
Record Writing
Write the ticket record: channels, turns, the answer sent, and the sources behind it
A2
Gap Finding
Group the month's handoffs by what actually caused them
A3
Quality Watch
Sample sent replies and check each sentence still reaches the source it cited

How It Runs

1

Message Intake

Nobody is asked anything here

Agents watch every channel a customer can write on, tie each sender to their policy record, and fold a customer writing on two channels into one conversation. Nothing waits on a person here. A sender nobody can match reaches somebody through station 4, with everything that is known attached.

2

Question Triage

Nobody is asked anything here

Agents name what each message wants, carry the earlier turns so a follow-up reads as one conversation, and send a cancellation or a run of falling patience straight to a person. A person is not asked anything here. What needs one is already on its way to station 4 before anybody could have spotted it.

3

Answer Drafting

Nobody is asked anything here

Agents pull the clause and the customer's own numbers, draft the reply with a source on every sentence, and check the draft against the record before it sends. Nobody reviews the replies that pass. A person sees only the questions no document answers, and those arrive at station 4 already declined.

4

Person Handoff

A person answers here

Agents assemble everything the bot declined or triage routed into a short queue, each item one line, with the whole conversation, the policy record and two or three drafted replies attached. This is where your team works. Every other station exists to keep this queue short and this brief complete.

5

Conversation Closing

Nobody is asked anything here

Agents confirm the answer landed, reopen the conversations where it did not, and file a ticket record that carries every channel, every turn, the answer sent and the sources behind it. Nobody signs a closing. A customer who writes back unhappy goes back through triage by themselves, with their history attached.

6

Service Review

A person answers here

Agents group the month's handoffs by cause, draft new knowledge base articles from the replies the reps actually sent, and sample the sent replies against the sources they cited. A person approves every new article before the bot answers with it, and signs the review. Those are the two acts that stay human, because the bot must not teach itself an answer nobody checked.

Where a Person Decides

Step 4, Person Handoff. Read one line and send or edit a drafted reply. Open the full history only when the line is not enough. the customer is waiting on a person now.
Step 6, Service Review. Read the two drafted articles, then approve, edit or reject them. Decide whether the Portuguese gap earns a template, or stays a handoff. an unapproved answer never teaches the bot.

Operating Model

This changes how work flows through the team.

Role
Responsibility
Person Handoff owner
Read one line and send or edit a drafted reply. Open the full history only when the line is not enough. the customer is waiting on a person now.
Service Review owner
Read the two drafted articles, then approve, edit or reject them. Decide whether the Portuguese gap earns a template, or stays a handoff. an unapproved answer never teaches the bot.

What Transfers, What Must Be True

What transfers
A person is in the loop wherever a customer gets a promise no document backs, or the bot learns a new answer. Two of the six stations refuse to proceed on their own, Person Handoff and Service Review, and those are the two your team carries. Everywhere else the agents run at volume, around the clock, and reach you only with what they declined to guess.
Person Handoff stops for a person, and the customer is waiting on a person now.
Service Review stops for a person, and an unapproved answer never teaches the bot.
Every subagent says what it will not do. 13 of them do.
What must be true in your environment
The agent can read the systems your records already live in. This one reads 16.
Somebody owns Person Handoff and has time for it.
Somebody owns Service Review and has time for it.

Failure Modes

What breaks this pattern:

✗ Wrong customer, right answer

When the bot guesses which account a stranger belongs to, it answers with someone else's order history, billing terms, or contract. One good guess in ten is still a data leak nine times.

✗ Confident answers with no source

When no passage covers the question, the bot can still write a fluent reply from nearby material. The customer acts on it, and nobody in the company ever said it or can defend it.

✗ Handoffs that belong to nobody

A handoff dropped in a shared queue with no name on it waits for whoever feels responsible, which is nobody. The customer's hardest question is the one that sits longest.

✗ Closed on the customer's question

If the bot can close a thread whose last message is an unanswered question, your resolution numbers rise while your customers stop asking. The dashboard says solved, the customer says ignored.

Directional Outcomes

What the agent counts, and the station that counts it.

These counts are the tallies from one monitored run of the agents. They are not monthly or annual totals.

Senders tied to their policy record
Counted at Message Intake
2,412
Tied to the wrong customer
Counted at Message Intake
0
Held unmatched for a person
Counted at Message Intake
9
Questions classified
Counted at Question Triage
2,412
Sent down the wrong path
Counted at Question Triage
0
Routed straight to a person on tone, cancellation or language
Counted at Question Triage
34
Replies sent with a source on every sentence
Counted at Answer Drafting
2,284
Replies that said something no document says
Counted at Answer Drafting
0
Questions declined and sent to a person
Counted at Answer Drafting
85
Conversations closed with the full record
Counted at Conversation Closing
2,371
Closed over a customer still waiting for an answer
Counted at Conversation Closing
0
Reopened and sent back through
Counted at Conversation Closing
41
Our measurement policy: We do not publish precise ROI without baseline methodology. Every figure above carries its basis.

What Runs Where

Every step names the subagent that does the work, the record it writes, the thing that raises a question for a person, and what it is allowed to touch. This is drawn from the source, not from a diagram somebody kept in sync by hand.

1Message Intake
subagentchannel-watch
writesqueue/open/<conv-id>.json
raiseshold-unmatched-sender
may touchqueue/**, customers/** read-only
2Question Triage
subagenttriage-intent
writesqueue/triaged/<conv-id>.json
raisesroute-on-tone
may touchqueue/**, policies/** read-only
3Answer Drafting
subagentanswer-draft
writesqueue/replies/<conv-id>.json
raisesno-source-for-answer
may touchqueue/**, kb/** read-only, policies/** read-only
4Person Handoff
GATE
subagenthandoff-brief
writesqueue/handoff/<conv-id>.json
raisesawait-rep-answer
may touchqueue/handoff/**, everything else read-only
5Conversation Closing
subagentclose-record
writestickets/closed/<conv-id>.json
raisesreopen-on-reply
may touchtickets/**, queue/** read-only
6Service Review
GATE
subagentservice-review
writeskb/proposed/<article-id>.md, reports/review-<period>.json
raisesapprove-article
may touchkb/**, reports/**, tickets/** read-only

Stack

Every system this agent reads or writes.

System
Read at
Stations
the SMS line
Message Intake
1 of 6
the claims system
Question Triage
2 of 6
the conversation archive
Conversation Closing
1 of 6
the conversation history
Person Handoff
1 of 6
the conversation queue
Question Triage
1 of 6
the follow-up survey
Conversation Closing
1 of 6
the knowledge base
Answer Drafting
2 of 6
the policy admin system
Message Intake
4 of 6
the policy wordings library
Answer Drafting
1 of 6
the reps' ticket queue
Person Handoff
1 of 6
the review report
Service Review
1 of 6
the support mailbox
Message Intake
1 of 6
the team directory
Person Handoff
1 of 6
the ticketing system
Conversation Closing
1 of 6
the ticketing system's month of records
Service Review
1 of 6
the web chat widget
Message Intake
1 of 6
Next Step

Want to see if this pattern fits your customer support bots?

No build commitment·Real samples, not a demo·Estimate in writing