Skip to content
Faidhi Fahmi.Contact
All selected works
AITechnicalData

Customer 360: an LLM knowledge base that is allowed to act

Organisation
iLyF · Easy, Instant Insurances
Role
Co-founder & Chief Product Officer · Knowledge base architect
Period
Malaysia

LLM summarisation and retrieval over a unified customer view, plus the part that mattered more: the deterministic policy gate that decides whether the system may act on what it found.

At a glance

Situation
Customer data lived across policy records, behavioural analytics, WhatsApp history, vehicles and orders. Every department worked from a partial view and believed it was the whole one.
Stakes
Support was slow, marketing could not target, and automating on top of badly joined data means confidently messaging the wrong people at scale.
My role
Co-founder and Chief Product Officer. Architected the unified knowledge base, identity resolution and automation governance.
Constraints
Messy real-world identity (one phone number owning several vehicles, plates changing hands), regulated customer communications, and years of accumulated data to clean.
What changed
  • Support response time dropped 40–50% because context was assembled before the agent opened the ticket
  • Lifecycle automation reached 10K–15K users monthly and cut manual outreach by ~90%
Read this if
You want AI acting on customer data without it becoming a liability someone has to babysit.
faster support response time
40–50%faster support response time
users in lifecycle automation monthly
10K–15Kusers in lifecycle automation monthly
reduction in manual outreach
~90%reduction in manual outreach
product events tracked end to end
50+product events tracked end to end

How the system actually worked

A deterministic policy gate between the model and the customerA five-stage pipeline. Ingest: fragmented sources, meaning policy records, CRM fields, order history and WhatsApp threads. Resolve: identity resolution on a three-point match, then data cleansing. Understand: a knowledge base built with language-model summarisation and retrieval-augmented generation. Decide: a goal is classified, then a deterministic policy gate either allows, escalates to human approval, or blocks. The model does not make this decision. Act: an idempotent outbox that fires exactly once into WhatsApp, email and push. Every path through the gate writes an audit package.INGESTFragmented sourcesPolicy records, CRM,order history,WhatsApp threadsRESOLVEIdentity resolutionphone, registration, ownerData cleansing1UNDERSTANDKnowledge baseLLM summarisation,retrieval-augmented2DECIDE: DETERMINISTIC, NOT MODEL-DRIVENGoal classifiedobjective, spec,affected countPolicy gate3Human approvalescalateBlockedblockACTIdempotent outboxfires exactly onceWhatsApp, email, pushallowed, or approvedAudit package on every decision: risk tier, affected count, action diff4

Scroll the figure sideways to read it, or turn your phone.

  1. Identity resolution was where the value actually was. A three-point match on phone, registration and owner ID is what turned four fragmented sources into one customer.
  2. The language model summarises and retrieves. It does not decide who gets messaged; it sits upstream of the gate, not inside it.
  3. The gate is deterministic. Same inputs, same decision, every time, and it is the only thing that can allow a message out.
  4. Every decision writes an audit package covering risk tier, affected count and action diff, whether it was allowed, escalated or blocked.
Ingest, resolve, understand, decide, act. The model summarises and retrieves. It does not decide who gets messaged. That branch is deterministic, and every path through it writes an audit package.

Stack & practices

  • LLM + RAG
  • Vector retrieval
  • MySQL
  • Python
  • Drizzle
  • WhatsApp
  • Mixpanel

Got a problem shaped like this one?

A short conversation is usually enough to see if there's a fit.

Email meRead another case study