Teach While Selling — Agentic RAG and the Death of the FAQ Page

For twenty years, education and conversion lived in different places: the landing page persuaded, the FAQ explained, the docs detailed, the legal PDF disclosed — and the application form converted, alone. A conversational agent collapses all of them into one channel. This article is about the “how”: answering a customer’s fears at the exact moment they appear, inside the flow, without derailing it — and the two-memory, human-reviewed architecture that keeps those answers trustworthy.

Watch a customer abandon a loan application and you’ll almost never see them fail at the form. They fail at a question the form can’t answer: “wait — what does French amortization actually mean for what I pay?”, “is 24 months better for me than 36?”, “what happens if I want to pay early?”

The old web’s answer was spatial: put the explanation somewhere else. A Q&A page. A glossary. A “Learn about loans” hub. A 40-page terms PDF. Every one of those is a context switch, and every context switch is an exit — the customer leaves the flow to resolve their uncertainty, and a meaningful fraction never comes back. The conversion funnel and the education content were two different products, built by two different teams, meeting only in analytics dashboards.

A conversational agent dissolves that separation, and this is genuinely new:

The same turn that collects the loan amount can teach what an amortization schedule is — personalized to this customer’s product, numbers, and moment of doubt — and then continue the sale exactly where it paused.

Selling and teaching stop being two flows. The guided-selling literature has been circling this for years — consultative bots that “educate customers on why a product fits” are the digitization of the good in-store salesperson — and it matters most precisely in high-consideration purchases like credit, where research friction kills conversion. But doing it safely in a regulated domain raises the question this article actually answers: when the agent teaches, where do its answers come from, and why should anyone trust them?

That’s the whole idea in one loop: a stuck customer, a layered answer, a resolution — scrubbed of everything personal, templated so no number is frozen in time, signed off by a human UX writer, and then served to the next person who hits the same wall, rendered with today’s product values.

The “how”, part 1 — detect the teaching moment at the point of friction

The channel-merge is only valuable if the agent notices when to switch modes. This system’s loan flow is a deterministic slot-filler (amount, term, product) — and every failed parse of a customer reply is routed through an intent classifier first:

• “50000” → a value. Fill the slot, move on. Selling.
• “what’s the maximum I can ask for?” → a question about the slot. Teaching moment.
• “how does French amortization work?” → a conceptual question. Deeper teaching moment.

This is the capillarity the channel gives you: the old web could only educate at page granularity — a FAQ entry someone must find. The agent educates at slot granularity: it knows the customer is stuck on term_months, for this product, having already said this amount. The teaching moment arrives pre-contextualized, at the narrowest possible point of friction. No FAQ page can know where you stopped typing.

The “how”, part 2 — teaching must never derail the sale

Here’s the design rule that makes mixing the flows safe rather than chaotic:

The help resolver owns no transition logic — it returns only the help TEXT. The state machine still advances only on a validly-parsed, in-policy value.

Answering “what’s the maximum?” does not fill the slot, skip a step, or advance the journey. The flow holds its place; the answer arrives; the question is re-asked with the customer’s context intact. Education is a detour that isn’t a detour — the sale is exactly where it was, one uncertainty lighter. This is what lets the two previously-separate flows coexist in one channel without corrupting each other: the teaching layer is architecturally incapable of touching the selling layer’s state. (And below both sits the orchestrator’s XState guardrail, which would refuse an illegal transition anyway.)

The second half of the rule is customization: the teaching is rendered from the customer’s actual situation. Deterministic per-slot guidance is built from the real product’s min/max/installments; the LLM helper gets those constraints injected as facts it may rephrase but not invent; disclosure summaries are deterministic template renders of the customer’s exact numbers — deliberately not retrieval, because a paraphrased disclosure is one a lawyer can’t sign. A FAQ page speaks to everyone; this speaks to you.

The “how”, part 3 — two memories, because trust is not one thing

Now the question you should ask of any system that “answers customer questions while selling credit”: says who?

This stack’s answer is architectural: two physically separate knowledge stores with different trust contracts, different write paths, and different reasons to change — plus a strict precedence between them, and a human review gate on everything the system taught itself. The full machinery — the cascade, the two collections, and the write → review → read learning loop:

Store 1 — knowledge_docs: the curated corpus. Authored explainers (French amortization, repayment basics, terms and conditions), chunked by heading, ingested idempotently by content hash. This is assumed-verified content: written, refined, reviewed — the same editorial standard as the old docs site, now retrievable mid-conversation. It changes only when a human changes a document.

Store 2 — slot_help_kb: the learned memory. Question→solution pairs harvested from the agent’s own resolved conversations — the self-information injection loop. It changes every time a customer gets unstuck. Cheap, self-scaling, and unreviewed at capture — which is exactly why a freshly-learned answer is a candidate, and candidates are never served. Between capture and reuse sits a human.

The cascade encodes the trust ordering — curated answers first, approved learned memory second, fresh generation last — and the write path always lands in the review queue:

explanation = await _knowledge_answer(slot, text)       # 1. curated corpus first → 📗 marker
if explanation:
    return explanation

key = generalize(text)                                  # 2. APPROVED learned memory second
hit = await rag_store.retrieve(key, slot)               #    (status='approved' only)
if hit and hit.get("solution"):
    # Stored solutions are TEMPLATES ({min_amount}, {terms}, ...) so no number is ever frozen
    # at capture time; render fills the CURRENT product's values. A template this context
    # cannot fill (render -> None) is treated as a miss — generate fresh, don't serve holes.
    rendered = help_templates.render(str(hit["solution"]), product=product, products=products)
    if rendered:
        return f"{_MARK_LEARNED}\n\n{rendered}"          #    → 💬 marker

solution, source = await _generate(slot, text, messages, product, products)
# Stored PARAMETERIZED (concrete values -> placeholders) as a status='candidate' row: it enters
# the UX-writer review queue and is never served until approved.
if hit is None:
    template = help_templates.parameterize(solution, product=product, products=products)
    await rag_store.remember(key, template, slot, source)  # 3. generate — then queue for review
return solution

And crucially, the learned store never writes into the curated one. The code states the boundary as a decomposition principle: the two collections have “a different reason to change: authored knowledge vs learned conversation memory,” sharing only the embeddings module and the Postgres server.

Is the two-store split actually right? What the outside world says

I went looking for external evidence, and the pattern holds up from three independent directions:

• The support industry already formalized it. The KCS (Knowledge-Centered Service) methodology — the dominant knowledge-management practice in support organizations — captures knowledge from live interactions as draft/candidate articles, formally distinct from validated ones, and treats “confidence visible to the user” as a core requirement. Constraining AI retrieval to validated content is explicitly cited as a hallucination control. Our knowledge_docs vs slot_help_kb is precisely KCS’s validated-vs-candidate split, expressed as two vector collections.
• Commercial AI-support platforms enforce the same tiering. Intercom’s Fin, for instance, answers only from explicitly approved content sources, with separately-managed curated “snippets” — source control is the product’s trust story.
• The research literature warns about exactly the failure the split prevents. Work on RAG “self-citation” and knowledge-base poisoning shows that indexing an assistant’s own outputs into the authoritative corpus creates feedback loops — “generate-evaluate-reinject” cycles that amplify bias and quietly degrade truth. The mitigation the literature converges on is the one this architecture hard-codes: keep generated content out of the authoritative corpus, stamp provenance, and gate reuse.

So yes — the two-store design isn’t a quirk; it’s the intersection of a support-industry methodology, commercial best practice, and the published failure modes of self-learning RAG.

What the implementation does to earn that trust

Checking the code against that external bar, the trust seams that matter are present:

• Separation and precedence — learned content can never shadow curated content, because the curated corpus is consulted first and the stores never mix.
• A draft→validated lifecycle, with humans in it. Every learned answer lands as status='candidate' — and candidates are never served. A dedicated curation dashboard (its own service, Keycloak-gated on a ux-writer realm role, fail closed) is where UX writers approve, edit, or reject; the agent retrieves only status='approved' rows, and every decision records who reviewed it and when. This is exactly the KCS candidate/validated split, with the dashboard as the “content health” loop.
• Templates, not frozen numbers. Before storage, concrete values are parameterized into placeholders — You can borrow between {min_amount} and {max_amount} — and re-rendered with the current product’s values at serve time. Change the product’s limits tomorrow and yesterday’s approved answer says the new numbers. A template the current context can’t fill isn’t served with holes; the system falls back to generating fresh. (This extends the disclosures’ template discipline to the learned tier — dynamic data always comes from live context, never from capture time.)
• Provenance the customer can see. Curated-corpus answers are marked “📗 From our loan guides”; approved learned answers “💬 A reviewed answer to a similar question”; fresh generation carries no marker. The trust tiering reaches the user, not just the architecture — KCS’s “make confidence visible,” in one line of markdown.
• Provenance on every learned row — a source column (llm vs deterministic) plus an embedding signature (provider, model, dim) that every query filters on, so a provider switch starts a fresh logical KB instead of silently comparing incompatible vector spaces. Reviewing edits text and status only — an approval never moves a row in vector space.
• Sanitization before storage — every learned key passes pii.redact (SSNs, Luhn-validated cards, accounts, passwords, PINs) and then collapses all numerics to <num>, so the KB stores shapes of problems, never people or amounts. “Can I borrow <num> for <num>” is one lesson regardless of whose money it was.
• Confidence gating — reuse requires cosine similarity above a provider-aware threshold (auto: 0.35 for the offline hash embeddings, 0.83 for real models); below it, the system generates fresh rather than serving a weak match.
• Bounded blast radius — the worst a bad learned answer can do is be unhelpful text. It cannot move the state machine, and everything fails soft to the deterministic guidance layer if pgvector is down.

One decomposition note on the dashboard, because it’s easy to get wrong: it shares no code with the agent — the slot_help_kb table and the placeholder vocabulary are the entire contract. Deliberately so: the agent’s store is fail-soft (a broken KB must never break a customer turn), while a review tool must fail loud (an Approve that silently does nothing is worse than an error page). Opposite failure semantics are a different reason to change, hence a different module.

The full trust gradient

Zooming out, the teaching channel actually runs on four tiers, strictest first — and the tier is chosen by what the content is, not by what’s convenient:

That table is the answer to “how do you teach while selling in a regulated domain”: match each kind of teaching to the strictest source that can produce it, and let none of them touch the sale’s state.

Conclusion

The channel-merge is the prize: one conversation that persuades, explains, discloses, and converts — with the explanation arriving at slot-level granularity, personalized to the customer’s own numbers, at the exact moment doubt appears. That’s something no arrangement of landing pages, FAQs, and PDFs could ever do, and it’s why this communication channel is worth the engineering.

But the merge is only safe because the knowledge behind it is tiered: curated docs you stand behind, learned lessons you scrub, template, and put a human signature on before anyone sees them, generation you sandbox — and legal text you never let a model touch. Keep the two memories separate, keep the precedence strict, keep help powerless over state, and put a UX writer between what the agent learns and what it repeats — then the same chat can be your best salesperson and your best teacher at once, without ever being your compliance department’s worst day.

Sources (two-store validation and channel thesis): KCS Article State — Consortium for Service Innovation · KCS in the Age of AI · What is Knowledge-Centered Service · When RAG Starts Citing Itself · Bias Amplification in RAG: Poisoning Knowledge Retrieval (arXiv) · Curated retrieval vs open web search: a coverage–trust trade-off (arXiv) · Intercom Fin — content sources · Intercom Fin — snippets · Guided Selling in the Age of Conversational Commerce (commercetools) · AI Chatbots in E-Commerce: From FAQ Bot to Digital Sales Consultant