Enterprise Insurer Built an AI Voice Claims Platform

AVOX is an always-on AI voice assistant for insurance customer conversations: policy questions, renewals, claims and payments. It runs on a multi-tenant voice backend built for the latency and noise of a real call centre and the compliance demands of a regulated industry, and is exposed to each insurer as a configurable frontline agent.

Look at where an insurance call centre's time actually goes. It is not the difficult calls. It is the enormous volume of short, routine ones — what is my renewal date, has my claim moved, can I pay now — each of which occupies a trained person for several minutes and requires almost no judgement.

A phone tree was the standard answer and it solves the wrong half of the problem. It can route the call. It cannot resolve the need, so the caller still lands in a queue, having spent ninety seconds pressing numbers to get there.

The obvious upgrade — a voice bot — was unsafe in a specific way that matters in a regulated industry. A general model on a recorded insurance call can sound completely confident while skipping a required disclosure, reasoning from the wrong policy, or taking an action it did not have permission to take. It is not that it is wrong often. It is that when it is wrong, it is wrong on a recording, in a regulated process, and nobody finds out until an audit.

Real calls made the engineering harder in parallel. Customers mix English and Hindi inside one sentence, talk over the agent, and call from noisy places. A naive voice loop meets all of that by dropping turns and producing transcripts nobody can rely on afterwards.

• Resolve routine calls end to end, escalating only what genuinely needs a person

• Hold a sub-second conversation through long, bilingual, noisy calls and interruptions

• Act only through validated operations, with disclosures and consent enforced rather than hoped for

• Leave a structured record of every call, so QA and compliance work from evidence

We built an insurance voice backend and exposed it as a configurable frontline agent. It runs a real-time loop — the caller speaks, the agent detects the turn, transcribes, reasons, acts, replies in voice — and completes that cycle in under a second even on a noisy bilingual call.

The decision that makes it suitable for a regulated setting is that the agent is treated as untrusted. It never acts on an insurance system directly. Every action goes through a typed tool that validates it against insurance rules first, checks permissions, enforces the required disclosure, and logs what happened.

That is what converts the compliance question from an unanswerable one into an answerable one. "Does the model always make the disclosure?" is a question about model behaviour, which nobody can guarantee. "Can this action execute without the disclosure?" is a question about the tool contract, and the answer is no.

The audit trail falls out of the same decision rather than being bolted on. Because every action is a typed, logged tool call, a call is not a recording someone has to listen to — it is a structured record of turns, actions and outcomes that a reviewer can query.

Design decision: speed and strictness were built as separate layers. The conversation loop is tuned for latency; the tool layer is tuned for correctness. Trying to make one component do both is what produces agents that are either slow or unsafe.

The caller speaks normally

No menu, no keywords. English, Hindi, or both in one sentence, from a noisy place, interrupting if they want to.

The agent works out whose call this is

Policy and claim context for that customer is loaded at the start, so the agent is reasoning about the caller's actual policy rather than about insurance in general.

It answers inside a second

Around 900 milliseconds end to end, which is the threshold where a caller stays in the conversation instead of assuming the line has dropped.

Any action runs through a validated tool

Pulling a policy, logging a claim, taking a payment — each is a typed operation with permission checks, required disclosures and escalation rules attached.

Complex cases go to a person, with context

Escalation carries the dialogue and the actions already taken, so the customer does not start again.

What the agent is allowed to do

The voice model never touches insurance systems directly. Policy, claim, payment and endorsement operations run through typed tools carrying schema checks, permission checks, mandatory disclosures and escalation rules. The tool contract is the compliance boundary, which means compliance is something a reviewer can read rather than something they have to observe over many calls.

What runs, in what order

Detect the turn, transcribe, load the applicable policy and claim context, reason, call a validated tool, persist the decision, reply in voice — inside a second, repeatedly, for the length of the call. Voice workers and the API are separate services so the platform scales behind a load balancer as volume rises without the response time drifting.

What you can see afterwards

Each call is a structured record: turns, transcripts, the tools invoked, what they returned, the disclosures made, and the outcome. QA, claim verification and compliance review all read the same record, rather than three teams re-listening to audio and reaching three conclusions.

The system did what the brief asked: it is fast and strict on the same call. Response time came down from two and a half to three seconds to around 900 milliseconds, which is the difference between a caller waiting and a caller hanging up. And because every action is a schema-checked tool call, free-form model output became operations a compliance team can verify after the fact.

It did not reach deployment. The client project concluded at internal stage, so what follows describes a system we built and tested, not queue savings an insurer realised.

• Sub-second responses, around 900ms, down from 2.5–3 seconds, across noisy bilingual calls

• Deterministic, auditable actions, because every tool call is schema-validated and logged

• Every call a structured record of turns, actions and outcomes, reviewable without re-listening to audio

The important qualifier is at the top, not the bottom: this project was built and tested but never deployed. Everything here is demonstrated capability on a system we ran. None of it is a production service level, and none of it is savings an insurer booked.

The 900ms figure is our own internal measurement, and we would want it reproduced before anyone quotes it against their own call profile — latency on a voice agent is a property of the whole path, and yours will differ.

What is directly demonstrable: the sub-second bilingual loop with interruption handling, the typed tool layer with its permission and disclosure enforcement, the insurance data plane, and the per-call structured record.

For your own estimate: eligible call volume × average handling time × loaded agent cost, minus your escalation rate, review effort and infrastructure cost. The escalation rate is the term that decides it, and it is the one you cannot know until you run real calls.