← Showcase
Rethinking insurance · Polly

Your cover, explained in plain English.

Polly is an AI assistant for insurance cover. Ask "am I covered for…" the way a real customer would: she finds the clause, answers in plain language, and shows you exactly where it came from.

Domain  Insurance Pattern  Retrieval-augmented (RAG) Built  End-to-end, full-stack
P
PollyPolicy assistant
grounded
Try a question →
The problem

People have simple questions.
The answers are buried.

When someone wants to know whether they're covered, they have two options today. Read the policy: dense, jargon-heavy PDFs where the answer is one clause among forty pages. Or call support: wait on hold, explain the situation, hope the person on the line reads the same wording the same way.

Both are slow, and neither reliably gives the clarity people actually want. Meanwhile contact centres field the same "am I covered for…" questions thousands of times a month.

Trawling the PDF

The cover exists, but finding and interpreting the right clause takes time and confidence most customers don't have.

Waiting on support

A queue, a callback, and an answer whose quality depends on who picks up.

Repeat load on the team

High-volume, low-complexity questions consume the people you'd rather have on the hard cases.

What we built

A direct line to the policy, 24/7, in everyday language.

Polly reads the relevant policy documents, finds the clauses that apply, and returns a clear answer, with the source wording attached so anyone can check it. She handles the actual situation, not just the keyword.

She never guesses. She references.

How it works

Retrieval first, then a grounded answer.

Polly is a retrieval-augmented system. Rather than letting a model answer from memory, where it can confidently invent cover that doesn't exist, every answer is built from the customer's actual policy wording, retrieved at the moment of asking.

→ 01
Understand

A fast, small model reads intent and expands the question into the terms a policy actually uses.

→ 02
Retrieve

Hybrid search ranks the most relevant clauses from the indexed policy set.

→ 03
Ground

Those clauses, and only those, are handed to the answering model with strict instructions.

→ 04
Answer

A structured response: answer, interpretation, sources, confidence, disclaimer.

Document pipeline  ·  PDFMarkdown (models read text far better than raw PDFs) → JSONL for structured facts → embedded & indexed for retrieval.

Small models do the cheap work; a stronger model writes the answer. Routing, query expansion and safety checks run on lightweight models; the final, customer-facing response uses a more capable one. The right model for each task: for accuracy where it matters and cost-efficiency everywhere else.

Built to be trusted

In a regulated context, the guardrails are the product.

01

Strict grounding

Every factual claim must map to a retrieved clause. No supporting wording, no claim: Polly triggers a disclaimer instead of filling the gap.

02

Cited, every time

Title, section, the wording itself, and her interpretation of it. Transparency builds trust faster than a slick answer.

03

Injection resistance

Attempts to change her identity or pull her off-topic are refused by design. Her role is fixed.

04

Handled with care

Sensitive scenarios get extra compassion in the prompt, and a clear line that this is general information, not advice.

Governance isn't a layer we added at the end. Input handling, identity locks, grounding rules and a visible "not financial or legal advice" boundary were part of the build, the same discipline we put around every assistant we put live.

The build choice

We chose to build it end-to-end.

Low-code assistant platforms are the right answer for plenty of jobs, and we use them where they fit. For this one (high volume, document-heavy, citations non-negotiable, reliability under load), we built full-stack instead.

Why it mattered here: complete visibility of cost and performance, control over exactly how documents are processed and retrieved, structured outputs we could validate, and no per-tenant rate ceilings to design around. When the answer has to be grounded and defensible, owning the pipeline is worth it.

It's the same judgement we bring to every engagement: match the tool to the real problem, never a fixed stack.

The art of the possible

One architecture.
Many assistants.

Polly was built modular on purpose. The same skeleton (retrieval, grounding, guardrails, structured answers) powers a different assistant the moment you swap the knowledge source and the prompt. We've already reused it across other domains.

Customer-facing

Claims navigator

"What happens now, and what do I need?" Grounded in your claims process and product wording.

Internal

Staff helpdesk

Answers from your own technical and process docs, so the team stops hunting through the intranet.

Advice-adjacent

Benefits explainer

"Explain this to me in normal language" over any dense document set where clarity adds value.

Let's talk

Got a document-heavy workflow that feels ripe for this?

This is the kind of thing an AI Workflow Pilot is built to prove: one to three genuinely useful, grounded workflows, tested on your real work, with the governance to put them live. It starts with a conversation, not a commitment.