Sanoo InsurTech · 2026 · Pilot
OTTO
A car insurance platform for the WAEMU zone, from the WhatsApp agent to the broker dashboard. The full quote, mobile money payment, certificate, cancellation and refund loop is validated end to end in test conditions, ahead of a pilot.
- Architecture decisions
- 22
- documented ADRs
- LLM providers
- 6
- behind one interface, with failover
- Test files
- ≈ 650
- back end, front end and end-to-end flows
- Role
- Sole developer, from architecture to the dashboard
- Duration
- Since April 2026
- Stack
- FastAPI · PostgreSQL (pgvector) · Redis · React · Multi-provider LLMs (DeepSeek, Qwen3) · Google Vision · WhatsApp Business · Docker Compose
Confidential project: figures are relative or omitted, never made up.
OTTO · WhatsApp
- Customer :
I want to insure my car, plate number AA-123-BC.
- OTTO :
Very well, I’m calculating your third-party liability quote.
- Customer :
Yes, I confirm the policy for my vehicle and I want to pay now.
- OTTO :
Perfect, your policy is registered. Pay the amount through this Wave payment link: checkout.wave.com/… Your certificate will be sent as soon as the payment is received.
Context
Sanoo InsurTech wants to sell and renew car insurance in Senegal, then across the WAEMU zone, where customers already are: on WhatsApp and at insurance brokerages. The April 2026 specification describes a conversational agent able to complete a policy purchase, and a dashboard for brokers to follow their customers and sales.
The problem
Buying insurance is not an open-ended chat. It takes an exact quote, readable supporting documents, a confirmed mobile money payment, a certificate issued by the partner insurer, and the ability to cancel and refund. Every step depends on an outside system, and none of them can tolerate an answer the model made up.
On top of that come the constraints of a shared platform: several brokerages whose data must never mix, language model costs to keep under control, and a service that has to keep working when a provider goes down.
My approach
A modular monolith rather than microservices. The FastAPI back end is split by domain, with a separate service orchestrating the agents. Twenty-two architecture decisions are recorded as ADRs, so every choice stays defensible.
Isolating brokerages in the database. Each brokerage is a tenant, separated by PostgreSQL row-level security: a bug in application code is not enough to expose another brokerage’s data.
A language engine tied to no provider. The specification called for a single model. I built one interface over several providers: DeepSeek first, Qwen3-32B through OpenRouter being validated, a local model as a fallback. Failover is automatic, every call is logged with its cost, and an alert fires before the monthly budget is exceeded.
Agents configured, not coded. An agent is described as data: its role, its tools, its sources. Answers about coverage rely on hybrid search (keywords and multilingual embeddings) over the insurer’s documents. Supporting documents go through Google Vision OCR, then get structured by the model.
Operations designed in from the start. The WhatsApp provider is swappable (Meta, Twilio, Whapi). The platform runs on Docker Compose on a VPS, with centralized metrics and logs. Tests cover the API, the dashboard and full flows, including a nightly run against real models.
For the pilot, sales go through the web and the dashboard first; the WhatsApp agent is paused.
What changed
On October 10, 2026, the full loop (quote, payment, certificate, cancellation, refund) was validated in test conditions, with payment and the insurer in sandbox environments. The pilot with brokerages has been approved.
What I took away
An AI agent is only as good as what surrounds it: in an insurance purchase, the conversation is the visible part, but trust is built on the exact quote, the confirmed payment and the certificate.