Skip to content
Faidhi Fahmi.
All selected works
AITechnicalData

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

Organisation
iLyF — Easy, Instant Insurances
Role
Architect of the knowledge base and the automation governance around it
Period
Malaysia

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

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 — policy records, CRM fields, order history, 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 — risk tier, affected count, 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.

Context

Customer data lived in several places at once: policy records in one database, behavioural analytics in another, WhatsApp support history in a third, vehicle and order records in a fourth. Every department worked from a partial view and assumed it was the whole one.

What was actually needed

Two very different complaints shared one root cause. Support agents were spending real time hunting for a policy detail before they could answer a question. Marketing could not build a targeted campaign because they could not see a customer’s journey. Both needed the same thing: one resolved view of a customer, and the ability to act on it without a human assembling it first.

How I used AI here

The LLM does three jobs and no others: it summarises long support and policy histories into something an agent can read in seconds, it powers retrieval over a knowledge base so the right context surfaces without a search query, and it drafts outbound copy. It does not classify risk, it does not pick audiences, and it does not decide to send. Keeping the model inside those three jobs is what made the rest of the system safe to automate.

What I did technically

Identity resolution is a three-point match across phone number, vehicle registration and owner ID — because in a market where one phone number owns several vehicles and one plate changes hands, matching on any single field silently merges strangers. On top of the resolved view sits a governed automation layer: a business goal is classified, checked against a deterministic policy gate that allows it, escalates it for approval, or blocks it, and only then queued to an idempotent outbox that sends exactly once. The unglamorous majority of the build was data cleaning — normalising Malaysian phone numbers, deduplicating vehicles, reconciling orders against the right owner.

Decisions that mattered

Making the policy gate deterministic rather than model-driven. That decision runs through explicit rules, writes an audit package recording the verdict, the affected count and the action diff, and requires human approval above a risk threshold. It is the difference between automation a business can operate and automation someone has to babysit.

What changed

Support response time dropped by roughly half because the context was already assembled when the agent opened the ticket. Lifecycle automation reached the low tens of thousands of users a month and cut manual outreach by around 90%. The database stopped being somewhere we looked things up and became something that initiated work.

The insight I kept

Everyone wants to talk about the model. The value was in identity resolution and the approval gate — the two least interesting parts of the system. An LLM pointed at badly joined data produces confident, well-written nonsense, at scale, in your customers’ inboxes.

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.